Use-Case 3.0
Dear Use-Cases, take this path or prepare for the Ragnarök.
Once dominant design technique Use-Cases facing the imminent death of the hands of wicked-problems. This post is one last attempt to avoid doomsday.
Use-case diagrams and descriptions used to be the god of design techniques until late two-thousands. We used to apply use-case descriptions to describe any system behaviour interacting with an actor. When we say any, we meant it. We used them from automated teller machines to enterprise resource planning software, from five-page websites to airline ticketing systems. You name your mother-in-law, and we will probably put her into a use-case description too. As a designer during the era, I, myself, have written thousands of them.
Then came the age of wicked-problems and agent-based systems. Our automated teller machine can no-longer work in a simple sequence of events. Users are not generic anymore. My granny and my daughter both became users with entirely different needs and emotions. For a start, I won’t say who is who, one is scared of the machine while others think its too dumb. The universal flow of events no longer tells the score. At the same time, systems are no-longer flow driven. How can you list the start and endpoint of TikTok, Medium or LinkedIn?
The days of Use-case descriptions or as some call it — narrations, are over. Out of respect to the fellow and his generous contributions to the industry, I don’t want to comment on Ivar Jacobson’s desperate attempt force Use-case into agile by candy-coating it as Use-case 2.0 and Use-Case slicing as an alternative for User-Stories, Statement of Value and Acceptance Criteria. But if you want to know the history, please say hey google! — Note: hey Siri might work, as long as you don’t mind reading a sea of random things from the great-web.
The heydays of use-case descriptions are gone. Yet could we, maybe just for fun, defibrillate the heart. At least, let’s poke it with a stick and see. Let’s admit you love to observe what follows; I trust you chose to read this post for that reason, don’t you?
At its peak, Use-case descriptions used to give a clear narration of the flow of activities of functions such as opening a savings account at your local bank. Those days systems used to be simple, and yet we cared nothing about users. We used to report cold and emotionless flows describing most likely, few alternatives, and exception paths.
It’s obvious; we cannot remodel Use-cases be applicable for Tiktok or Facebook. We have invented better tools for organizing information for those. But what if, we can retain the simplicity and value of use-case descriptions in narrating opening a saving account. It has a simple flow of the event, often regulated by the local authorities or the bank. After all, this is an area use-case used to excel. Yes! Before we start caring about innocent users’ and their experiences.
But is this ‘actor’ person a robot? Don’t they have emotions, what if she is my grandmother? Or my daughter? Or even my next-door shady fellow, Dominic, who I’m pretty sure owns several yellow minions. Can we generalize the flow of events for all of them? one would be shifting from the afraid to the annoyance every other minute, While another would be rollercoaster between excitement to boredom.
I have been using a modification for the use-case descriptions for a while to tackle situations such as above. User Journey Maps inspired me, yet I didn’t want to craft a journey map for a simple event as above. Therefore, drumroll, please.
Use-case 3.0 — The one with emotions
Use-case 3.0 is a cheesy hack. We include the emotional rollercoasters for few personas that describe the actor. Then use the narration and physiological states to get inspired for design options.
Give this a try, and do share whether you think this is the defibrillator for dying use-cases or my sad attempt for fame?
