The design team sits down to share the first round of mockups for a new client’s application. As the team members present their ideas, it becomes clear that everyone has distinctly different ideas about what the app is and how it should function. The meeting quickly turns into more of a discussion about who — rather than what — is right. Everyone is defending their designs, and no one is defending the user. Sound familiar? It’s times like this that we need to implement user stories.
User stories are specific to Agile methodology, and when applied to the UI design process, they provide an essential foundation for the consequent stages of design. A lean version of user stories takes almost no time to implement, yet can do wonders to keep a project on track.
At CanvasFlip, our UI design team implemented user stories during a feature building process, and we found it accomplished three main things.
- User stories keep products user focused.
- User stories promote cooperation between team members.
- User stories help prevent feature creep and design dead-ends.
What is a user story?
A user story describes something that the user wants to accomplish by using the software product. They originated as part of the Agile and Scrum development strategies, but for designers they mainly serve as reminders of user goals and a way to organize and prioritize how each screen is designed.
A user story is a very short story — about one sentence long, in fact. Here’s the template: “As a user I want to … [basic user goal].” Because these stories are so short and specific, it takes many of them to cover every possible use case. In fact, we try to take each story and see how far it can be broken down.
For example, a user story might start out:
“As an user I want to create a new account.”
Stay user focused
As a designer, my mind begins piecing together layouts and colour schemes at the very first meeting with a project’s stakeholders. As I listen to their goals and learned about their end-users, I can envision how the app might look. But it’s essential to not put the cart before the horse — when we identify user stories first, we let them dictate the design rather than the other way around.
After brainstorming all of the user stories for an app, we put it in a collaborative Google spreadsheet where the client can add any stories they feel are missing. Once client and team alike feel that we had covered all our bases, we assign a number to each story. These numbers come in particularly handy later in the project, when we use them as succinct labels to identify what stories are covered in which wireframes.
Promote cooperation
A UI design usually has more than one stakeholder concerned with the outcome. This group can include clients, designers, programmers, and numerous other job titles, depending on the size of the organization. In many ways, it’s a similar situation to being on a rowing team. In order to win a race, every team member must row together in unison–at the same pace and in the same direction. That doesn’t mean everyone will always have the same opinion about everything — it just means that everyone is focused on the same goal and knows how they fit into the team.
User stories also make it easier for teams located in different locations to collaborate. When we were developing a UX feature with a team located in San Francisco, our Bay Area team would occasionally meet with the rest of the team to discuss the requirements for the app. They created the user stories — though they were modified throughout the project — and placed them into our Google Drive. We, the Los Angeles based team, would then refer to the user stories as we created the wireframes and make changes as needed. Had it not been for this process, the project would have taken significantly longer to complete, and would have required long involved explanations to accomplish what our multitude of tiny user stories did in just a few minutes.
Prevent feature heap
“Feature heap” is a term that comes up regularly during UI design. It refers to the tendency to want to keep adding more capabilities and expanding the scope of a project, whether hardware or software.
With user stories in hand it becomes fairly simpler to keep away unnecessary features from the product.
To remember!
Here are a few things to remember when trying user stories on a UI design:
- Identify a full set of user stories before doing any visual design. Resisting the temptation to jump straight into designing may save time and headaches and lots of wasted effort.
- For each user story, see if it can be broken down into smaller, more specific stories. “Epics” are fine for a high-level overview of the needed features, but don’t leave things too broad. Drill down to the specifics early on, and solve usability problems at the outset.
- Never put a design element in an interface that doesn’t have a corresponding user story. Documenting the what and why of each element promotes organization and makes the handoff to the development team much smoother.
What next?
Now that user stories are in place, your efforts for task based testing are halved! Transform these user stories in tasks for the users — [Here’s how I do it.]
Shoot out your tests and wait for the users to interact with your design interfaces. Once that is done, put on your researcher hat and analyse every user behaviour data.
Here are few of the analytics I am very particular about while testing —
- Completion/success rate — For a given task scenario, how many users were to complete the assigned task. We use conversion funnels to understand and visualise these numbers. For most of the usability tests we have performed in CanvasFlip, on the product as well as famous on famous app prototypes, this has been the most important metrics
- Drop-off rate — It is somehow the complementary of completion rate, but it points out the design screens where most users leave the prototype. For this we again use the conversion funnel.
- Error rate — Which errors tripped up users most? These can be divided into two types: critical and noncritical. Critical errors will prevent a user from completing a task, while noncritical errors will simply lower the efficiency with which they complete it.
- Time to completion — How much time did it take the user to complete the task? This can be particularly useful when determining how your product compares with your competitors (if you’re testing one against the other). This is again a parameter that is displayed for each task on the CanvasFlip dashboard.
- Subjective measures — Numerically rank a user’s self-determined satisfaction, ease-of-use, availability of information, etc. This is something that is very difficult to conclude from the insights from a tool. For our remote user tests, we have a survey at the end of the test and for in-person user tests you don’t need any such surveys. First hand experiences are best to rank such parameters.
Final words
User stories are fundamentals of every design process. These fundamentals helps you understand “why” a flow or UI element is more important than others.
Sadly, these are often ignored or pushed back due to business requirements not to mention, HIPPO factors. But if they are enforced and supported with data, these can make significant difference in your workflow and overall outcomes.
Hope this article help you closely following your designs to user stories. If it did, mind share it with your friends & colleagues?
P.S. Say hello to Visual Inspector 3.0
Visual Inspector is popular Chrome extension for designers to make changes to live websites and collaborate feedback with stakeholders.
If you are a web designers, struggling to get feedback on website — try Visual Inspector now to save time and iterate much faster on website.
Siftery brings you lifetime subscription of Visual Inspector for just $49 — https://www.canvasflip.com/visual-inspector/siftery/
