You’re a designer or a UX specialist. Let’s take this scenario – you get assigned to a project, and the conversations with the product manager (or the person briefing you) is similar to below:
“We have no documentation of the project, it’s not in our company culture- everything is verbal as it keeps changing sometimes on a daily basis”
“…it’s x months behind schedule already so we don’t have time for user stories & use cases– let’s just jump into it and get it out asap”
“…the easiest way to solve it is to just add these few elements & functionalities and it’s done! what do you think?”
How often have we heard the above? It’s my opinion that when we hear those type of reasoning we should steadfastly steer the direction of the meeting to nail down User stories & Use cases. Why so? If not, the project will be leading to a high probability of rolling changes rather than solutions, endless clashes of opinions, and uncertainty. It may result in fruitless discussions between team-mates on WHO is right (their proposals) instead of focusing on the base requirements to serve the user. In this context, the team-mates/stake-holders can be designers, coders, product owners etc.) It gets more complex if you happen to inherit a project that had started already weeks/months before you being introduced into it. Similar to a forensic detective coming on to a crime scene, we UX’ers would start with looking for clues– every available design artifacts to piece the puzzle one by one. No matter how pressed for time (as 90% of work we do seems like it is), keeping to the fundamentals will save us from headaches & help us avoid design dead-ends.
Design artifacts, what are they?
Artifacts can include user stories, use cases, user personas, scenarios, user journeys, app maps, experience maps, or past WireFrames etc. They are fundamental in absorbing & understanding the context of the design problems to solve centered around the User(s). They’d not need to be finished/polished pieces of work, they simply need to provide enough clues/information for you to understand User’s motivations & needs–which will lead you to start formulating solutions to the problems.
User stories & Use cases– how are they used and by whom?
User stories come before the Use cases– they’re goal statements of a specific user. They should start with the User identity and followed by his/her need being stated like below:
“As a [type of User], I want to … [basic user goal].”
For example, “ As a standard User, I want to create a bill/invoice.”
Next step is to identify what’s needed in order to create a bill? The user needs to log-in , select the customer, select the corresponding order. Hence this story can be broken down further for each action:
“ As a standard User, I want to log-in.”
“ As a standard User, I want to find & select a customer.”
“ As a standard User, I want to find the corresponding order to the customer selected.”
“ As a standard User, I want to create a bill/invoice to the chosen customer & order.”
Use cases takes each story and outlines the steps which will require the user to take for each action as there can be intricate processes within them. We’ll cover more on use cases in the next blog post but meanwhile we can view User stories are skeletal frames while use cases are the actual muscles in defining the scenario.
Product owners or collaborators closest to the customer (User) should be providing user stories to share with the team– designers, coders, UX specialists. The team rely heavily on the stories as objectives so in the manner of speaking they’re used by the entire team.
Key benefits of user stories
User-centered: The key benefit of stories is that it keep the team focused on the User’s needs and reminds us which User we are serving. The bigger and more complex the product is we can be dealing with multiple user types and it can get confusing very quickly. The story defines/identifies the key info here immediately and straight to the problem at hand (without the fat).
Leads to cooperation: The dialogue which will take place once the stories are shared becomes more important here. Questions & answers between the team-mates keeps the “magic fluid” flowing–communication!
Cuts the fat: an approach someone’s worked on for too long and unwilling to let go or your pet idea born in the shower and willing to argue to death to keep– these are common pitfalls we all have experienced within teams. The user stories keep us straight on the narrow in keeping to the objective and negate any fluff which may be nice-to-haves and is out-of-scope.
Avoiding headaches & design dead-ends
If the above is done right, it takes 15-30 minutes, no more. Compare that with 3 days or 3 weeks of work which led to a dead-end street because of poor communication of the goals or simply jumping into a solution to later realize that it doesn’t fit the requirements. “Let’s define better what’s needed…” after days/weeks on the the task should really not ever happen and it’s demoralizing to get there so late. If any product owner or manager says that time is of essence, then well…need I say anymore? All user stories are essentially simple, user-friendly methodology of communicating what it required– for all to understand because it’s a small learning curve to master. If and when we get side-tracked , have conflicts of opinions, or an all-out confusion on what’s important– coming back to the user story re-centers us to the actual user’s needs definitively. In the popular TV series “CSI- Crime Scene Investigation” the theme is Who are you. In our line of work, the “who” and “why” is key information–ultimately to get to the real motivators for wanting a functionality or feature added. Once we know that, we’re orientated on the right path to make good solid design decisions from then on.
