Responsive Design Using Contextual Product Backlogs and User Stories
Responsive design is one of the biggest challenges to solve in the modern UX world. How can we design effectively for multiple devices and screen sizes without needing to wireframe screens several times or mess around with HTML? To be honest, so far I don’t think anybody really has the answer. I’m going to throw another technique into the ring using user stories and what I am calling contextual product backlogs.
When we talk about responsive design it is easy to forget why it is being responsive in the first place – because of the user’s context
What is a user story?
To get the full run down on user stories check out our beginner’s guide to user stories but as a quick summary: a user story is a statement from the point of view of a user which summarises one of their user needs.
It takes the format of:
“As a user I want to be able to <do something> so that I can <reason for doing it>”
User stories are very common in Agile and SCRUM project processes as they form the basis for development, but they can just as easily be utilised if you are working in a waterfall methodology.
Prioritise the story according to context
One method of figuring out what you are going to build is to prioritise the high level user stories according to the perceived importance to the user and mapping it against the estimated effort to implement. This basically creates a standard Agile/Scrum product backlog.
The product backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. – http://agilebench.com/blog/the-product-backlog-for-agile-teams
I propose adding an additional prioritisation – by context.
The problem with how user stories and product backlogs are currently used is that they are issued a blanket prioritisation regardless of the context the user will be using them in. This may result in certain functionality being considered ‘more important’ when in fact in the most common use cases it may not be which is not ideal when thinking about responsive design.
In your user journey work you will have identified and illustrated common situations in which the user may be interacting with what you are designing. This could be for example:
- On a train
- At home
An example – a transport website
Lets assume we are building a website for a transport app, and because I’m a Londoner we will say it’s for the tube (London’s subway system for our international friends).
Different user stories will have different prioritisation based on their context. Let’s look at one user story in particular:
“As a user I can add a new monthly ticket to my account so that I don’t have queue up at a station to do it”
|On a train||At home|
We can see that the likelihood the user will want the functionality in these two different contexts varies.
If they are on a train it is probable that the user already has their ticket to have allowed them to get on in the first place. Combined with intermittent internet connection issues due to travelling it is less likely they will want to conduct financial transactions on the move. Therefore this user story gets a low priority in this context.
At home it is more likely the user will have a solid internet connection and be more willing to invest the time it takes to purchase a ticket. There is a high likelihood this will be something the user wants to do in this context and therefore it gets a high priority.
Of course your user journey and persona work will have also identified what devices the user is likely to be using at these times.
A contextual product backlog
We now have a prioritised set of user stories for the different contexts our users will be interacting with our website. Not only does this help us prioritise the hierarchy and importance of different functionality on a page but it gives us a more complete and user centric way of looking at our responsive design, rather than just thinking about how things should resize.
We can now more easily take into consideration the context of the user when defining calls to action, use of imagery, navigation and so on by making the context part of the user story itself.