A lot of focus in UX design is on user research deliverables. Although these undoubtedly have their place, in my experience, it’s very rare to work on a project with the timeframe or budget for such extensive user research.
Of course, it’s important to have knowledge about users in general (although not necessarily the specific user base for your website or application) so you know how people generally use web-based products, but I’ve found it’s more important focus on the activity your application is meant to support and design for that.
In his article, ‘Human-Centered Design Considered Harmful‘ UX guru, Donald Norman mentions that many technologies and products have become great not as a result of a deep understanding of users, but rather because of a ‘deep understanding of the activities that were to be performed.’ He alludes that everything from kitchen utensils to musical instruments are examples of products designed through an understanding of the activities they were meant to support.
User stories
I’ve found a great way to put the above theory into practice is to write user stories to communicate each project requirement (a user’s outcome) and to capture the workflow that will eventually be built into an application to achieve that requirement.
A user story begins with a statement given from the perspective of the user. This is an example of a user story format from Mike Cohn:
As an actor, role, or persona, I want to complete a goal so that I achieve this value.
Example of user stories for a system would be:
As an existing user, I want to be able to sign in so I can view the dashboard.
As a shopper, I want to be able to checkout so I can purchase the items in my shopping cart.
Each user story is then followed up by a list of step-by-step instructions for how an interaction or task may be accomplished. Each step can be kept high level, describing the general situation (for example, User clicks ‘Sign In’ button), or it can include more detailed descriptions of what actually happens on the screen when each operation is performed.
I find this process valuable as it exposes potential problems and brings to light any assumptions I was making about a task prior to writing it. It also ensures that the developers and I are on the same page.
By taking 20 minutes to write an effective user story, a lot of potential pitfalls can be avoided without investing lots of time on design and prototyping. The rest of the work is figuring out how to implement interfaces that support each user activity and the tasks along the way.