Having undertaken initial user research and analyzed your research findings, the next phase of the design process is to apply what you’ve learned by developing a series of designs to test your assumptions. In this article series, I’ll be focusing on the initial phase of the design process at a higher level, from a birds’ eye point of view.
As I explored in my preceding article on research, it’s important to stress that we’re building on the user research undertaken. Having analyzed our research findings, our goal at this phase of the design process is to:
- establish some clear user pathways that satisfy different users’ needs by embracing user stories, scenarios and storyboarding;
- apply some lessons from the world of human computer interaction (HCI) so that we design with first principles in mind; and
- establish a ‘look and feel’ for our designs in a manner that’s device-agnostic that can be applied in both a desktop and mobile context.
In short, this article is intended to act as a bridge between the research phase and the design phase. As I stressed in my last article, the design process – research, design, prototype, build, test – is an iterative one; at this phase in the process we’re focused on developing a series of designs that we can prototype, build and test.
Getting a Skeleton in Place
Before we get down to the details of user interface (UI) design and building interactive prototypes, it’s important to get the high-level flow of the design in place, establishing a skeleton around which we can build our design.
At this point in the process it’s important to use our research findings to inform the development of user stories, identifying different users’ goals. We can use these user stories to create different scenarios. This helps us to identify clear goals – and an underlying intent – that guides the design process. It also enables us to develop flows through what we’re building.
When developing initial flows – using paper prototypes and storyboards – we’re focused on getting a feel for the design in its totality, before drilling down into detail. It’s important to get a skeleton in place and not get lost in the details, which will follow down the line.
In my last article – A Comprehensive Guide To UX Research – I focused on the importance of undertaking user research before you embark upon the design phase of a project. As I put it: “Spend some time with your users, getting to know their needs, and what it is they are trying to achieve, these are their ‘jobs to be done’.” By teasing out our users’ ‘jobs to be done’ we can ensure that what we design is truly user-centred.
Having undertaken some focused user research it’s important to take your findings and use them to inform your design process. Your research should have helped you establish some patterns, needs that the users you’re designing for have in common.
One size rarely fits all, however, and it’s likely that whatever you’re designing will have multiple user types with different needs. Developing ‘user stories’ – that represent the needs of different users – can help you distill down the goals that you’re trying to solve, helping to shape the rest of the process. But what exactly are user stories?
User Stories
User stories are a useful way of establishing a high-level view of different users’ ‘jobs to be done’. Written from the perspective of typical users, they help you to establish the different goals your different users have so that you can design for their different needs accordingly.
The term ‘User Story’ was originated by Alistair Cockburn, one of the initiators of the agile movement in software development, who coined the phrase, “a user story is a promise for a conversation,” during a project for Chrysler in 1998.
User stories shift the emphasis from writing about requirements to talking about them. Whilst subtle, this shift – from writing to talking – can have a significant impact upon the design process.
All too often requirements are delivered in an abstract manner, as a list to be checked off that – if you’re not careful – bears little resemblance to what users need and more resemblance to what a ‘design by committee’ needs. User stories help position users at the heart of the conversation.
so that " class="wp-image-51259 webpexpress-processed" srcset="/ideas/wp-content/uploads/2018/02/image2-4.png 700w, /ideas/wp-content/uploads/2018/02/image2-4-600x338.png 600w" sizes="(max-width: 700px) 100vw, 700px">User stories are a great way of defining different users’ needs by positioning the user at the heart of the design process. User stories help you map roles onto actions and goals.This idea, of a tool to encourage and facilitate conversation, captures user stories’ strength. They are an ideal tool to start mapping out scenarios, ensuring users always remain at the heart of the design and development process.
Short descriptions of goals and features told from the perspective of different users, user stories help you to get an understanding of the underlying goals your users have so that you can see the problem from their perspective. These follow a pattern as follows:
- As a [person in a particular role],
- I want to [perform an action or find something out],
- So that [I can achieve my goal of].
Using the above template we can put ourselves in the shoes of different users and develop different stories to shape our design. Imagine, for example, we’re building a web-based learning resource where lecturers and students can share learning materials. We’re likely to have a number of different users with different needs. A lecturer’s user story might be:
- As a lecturer, I want to share my lecture slides so that I can provide my students with access to resources beyond the classroom.
By developing a short story around this user’s specific needs we can begin to envisage design patterns that satisfy this type of user. Seen from the perspective of a student – a different user with different needs – we might develop the following user story:
- As a student, I want to access lecture slides so that I can refer to them when I’m revising.
These stories – relayed from different perspectives – provide us with useful provocations we can use at the start of the design process to start mapping out our design at a high level. Importantly, the stories are focused on satisfying our users’ needs. In short, user stories helps us to get a feel for what users’ goals are at a high level. We can then use these stories to develop different scenarios which we can begin to design.
Using Scenarios to Inform Your Design
At the start of a project it’s easy to get carried away adding features aplenty and getting lost in ‘featuritis’. The danger of this approach is that it’s easy to begin adding features and functionality that detract from your users’ core goals.
By using user stories to develop typical scenarios you remain focused on your users’ core goals. This approach also enables you to establish expectations and develop benchmarks for typical user needs, which can be used to set clear deliverables and scope at the start of the project.
Starting with user stories we can begin to build different scenarios that satisfy varying users’ needs. Mapping these stories and building flows allows us to establish how different users’ needs are accommodated.Returning to the previous example we can establish some high level goals from the perspective of our different users: for the lecturer, we’re going to need to design an upload feature; for the student, we’re going to need to design an access feature. These are high level goals, but we can – as we develop our scenarios – start to add some granularity and complexity to our user stories informing the design further.
For example, returning to the earlier example, from the students’ perspective we might consider the following scenarios:
- At a base level the students want to access the slides.
- At a slightly more enhanced level, the students might want to be able to annotate the slides, capturing their notes.
- Finally, if resources allow it, the students might want to share their notes with their peers, enabling collaborative learning.
Scenarios, like the example explored above, enable us to get a clear picture of differing levels of complexity and design for these accordingly. They also allow us to get a feel for the flow of users through our design, enabling us to map them out on paper so that we can begin to build a birds’ eye view of the project.
Mapping Your Design Flow
Using your user stories and scenarios as a driver for discussion it’s possible to begin to map pathways through your design at a high level. This process of user story mapping, illustrated earlier, helps us to define different user flows.
At this point in the process paper is a powerful tool for rapid prototyping, before moving on to develop more refined storyboards. A low-cost, low-fidelity and fast approach, paper prototyping has many benefits:
- It’s low cost, allowing you to explore multiple ideas with very little barrier to entry;
- It’s low fidelity, which encourages you to focus on the big picture and not get lost in the details;
- It’s fast, enabling you to quickly iterate through multiple variations of a flo
Paper also enables collaboration, allowing multiple participants to get around a table and develop a design quickly, taking on board everyone’s opinions and insights.
Paper is a powerful tool for early prototyping phases. Low cost and low fidelity it helps you to focus on the ‘big picture’ and get the skeleton of your design in place.Lastly, paper “saves itself.” When we design on screens we often lose design artifacts due to the nature of software saving ‘states’, different points in the design process. Paper prototyping allows us to see the entirety of the design process including rejected ideas en route to our finished concept.
In my experience a typical project will often require multiple rounds of paper prototypes as you iteratively work your way through your thinking. At this point in the process working on screen is too slow and too refined, which can quickly lead to getting lost in needless detail. Paper frees you up to focus on the big picture, which is what matters at this stage.
Of course, even experienced designers can recoil when confronted with the idea of sketching interfaces, finding the process intimidating. It’s not uncommon to hear, “But, I can’t draw!” This is patently untrue, all of us were able to draw just fine when we were children (as all those pictures on our parents’ fridges attested!) we just need to re-learn this valuable skill.
To paraphrase Jason Santa Maria: sketching isn’t about being a good artist, it’s about being a good thinker.
With high level sketches established it’s time to start adding some fidelity by creating some storyboards and wireframes. Hold that thought, however, I’ll return to it in my sixth article on Wireframing and Prototyping.
Continue reading part two of A Comprehensive Guide to UX Design: UX Laws.