Chris Thorne

I have worked in many teams who define product and project requirements as user stories and acceptance criteria. What makes a good user story?

As a User I want to listen to a documentary programme from Radio 4 on my PC, so that I can increase my understanding of the subject of the documentary.

As an example, here is a bad user story:

I want to click on a ‘buy this’ link that adds the item to my shopping basket.

One of the easiest ways for us to assess a projects success during development is by using user stories and acceptance criteria. However, user stories seem to be very dependent on who has written them.

In my opinion, a good user story has the following characteristics:

* It defines Who needs this requirement met – for example the Product Manger, a Stakeholder, or the User.

If the team don’t know who the requirement is for, and we want to find out more about this requirement, who should we talk to? Knowing who is important, to help us get further understanding.

* It defines what is supposed to happen.

This is the surface requirement. Ideally there is some evidence, research or analysis to support this requirement. You might add this research as supporting notes for the story.

* It defines why it is supposed to happen – what is the benefit?

Defining why a requirement is important (the ‘So that’ part of the story) increases understanding of the underlying need, and can greatly help innovation.

For example, we know that in the above ‘radio 4 programme’ story, the goal of the user is to understand the subject better. Perhaps on the web, this can be accomplished in other ways than ‘listening to the programme’ (a solution might be simply providing some related links for the programme). If we just have 1/2 the story – eg ‘As a User I want to listen to a documentary programme from Radio 4 on my PC’ , without expressing why this is important, we miss the opportunity to innovate.

To further encourage innovation, I also try to remove any reference to how from a user story. Supporting notes for the story might suggest:

* When it is supposed to happen.

* Where it is supposed to happen.

* How it is supposed to happen – this is just an idea, but might be useful as inspiration for the team.

The keyword here is ’suggest’. If we dictate the How and When and Where then we have weakened the project teams ability to innovate. If we were working on a factory production line, a lack of innovation can be useful (although Toyota seem to have done quite well through innovating on the production line), but if we’re knowledge workers working on a project, one of the outcomes should be some innovation.

Improving user stories

‘I want to click on a ‘buy this’ link that adds the item to my shopping basket.’

The above is a restrictive user story. Lets try and improve it.

Start by adding who it is for:

As a user I want to click on a ‘buy this’ link that adds the item to my shopping basket.

Now we know that if we want further information about this story, we should talk to user experience staff, or audience research staff. They may have further research that explains this story.

Now we can remove the how from the story. In this case the ‘buy this’ link is defining how the story is to be implemented. Removing this we end up with:

As a user I want to add items to my shopping basket.

This shopping basket idea might be well understood, but we would do well to define its behavior better, just to be sure we will get what we want. The shopping basket concept has several features that are worth considering separately.

The underlying function of adding items to a shopping basket is to collect all items I want to buy in one place, so that I can review all my proposed purchases  and pay for them all at once.

As a user I want to collect all the items I want to buy, together in one place, so that I can review my proposed purchases and organise payment and delivery details for all of my shopping just once.

If we add a note to this user story ‘The one place that collects all items together might be a ’shopping basket’ then we’ve explained our idea, but also left it open to design staff to think about other solutions that satisfy the same story. For example, they might think about storing previous payment and delivery details, so that repeat visits to the site are even easier.

The other aspect of the basket is being able to add, remove and change the quantities of items I have collected, before I purchase them.

As a user I want to be able to add, remove and change the quantities of items I want to purchase without journeying back to each individual products page, so that it is easy to complete my shopping.

So now we have 2 user stories, but a clearer definition of the basket functionality, and a clearer definition of the underlying needs of the user.

Conclusions

Great user experiences (I’m going to say it, sorry) for example, those delivered by Apple, are partly successful because they have worked hard to answer not just the surface requirement, but the underlying need. Great user stories are the foundations on which experiences are built. Making sure those stories are solid, researched, and prescribed appropriately for the project aims is very very important. By making sure that a user story defines who, what and why we have the basis of a good story.

Keeping how out of the story gives a project important room to innovate.

Thanks for reading – let me know your comments.

I’ve been thinking about the project process recently. If we ask the wrong questions, we get the wrong answers, so what are the right questions?

How often do we check – is the right problem being solved?

I’ve recently read Gamestorming – an awesome book of exercises to fire your creative juices. Similarly, I’ve found Dan Roam’s ‘The back of the napkin‘ inspiring.

Both books include an exercise ‘The 6Ws’ which I think should be applied in the initial phase of any new business project or proposal.

What are The 6Ws ?

The 6Ws are: Who, What, When, Where, Why and How. For a given goal, each of these ‘W’s is the starting word of a question. Crucially, questions created for each of these W’s cannot be answered with a simple ‘yes’ or ‘no’. Investigation of these questions leads to a better understanding of the goal, and the issues surrounding it.

An illustration of the 6Ws

Example problem: The carrot shop.

Suppose we have a new problem to solve, for example a shop sells carrots and asks us ‘How can we sell more carrots?’.

By asking questions beginning with one of the 6 Ws we can start to explore the problem. Is this the right question?

The below list took me 5 minutes to produce. By working quickly, we can focus on what the obvious questions are and hopefully therefore the important questions as well.

Carrot Shop: How can we sell more carrots?

Is this the right question? Let’s apply the 6Ws and find out:

• Who visits the shop?
• Who works in the shop?
• Who delivers the carrots?
• Who grows the carrots?
• Who buys carrots?
• Who could buy carrots that currently doesn’t?
• What are the features of a carrot?
• What types of carrot do we sell?
• What types of carrot can be grown?
• What do people use a carrot for?
• When do carrots grow?
• When do carrots get planted?
• When do people buy carrots?
• When do we receive the carrots?
• When do we sell the carrots?
• Where are the carrots grown?
• Where are the carrots stored?
• Why do buyers buy carrots?
• Why do we want to sell more carrots?
• How do carrots get grown?
• How do carrots get prepared?
• How do carrots get used?
• How are carrots presented for sale?
• How are carrots packaged?

I think the quality of business thinking about a new product or feature could be greatly improved by applying the 6ws at the earliest possible stage of a project. I suggest the 6Ws should be applied at the start of a new feature exploration, and before any user stories.

Just answering the questions raised forces the business to think critically about what the problem is they are trying to solve. Having asked these questions, does the problem still look like it is the best one to solve? Or does it suggest new, better opportunities?

Is ‘How can we sell more carrots?’ the correct question? In the Why section of the above, we ask ‘Why do we want to sell more carrots?’. By asking this basic question, we might well get the answer ‘to make more profit for the store’. So, perhaps a better question would be ‘We are a shop that sells carrots. How can we make more profit?’. Again, the 6Ws now suggest lots of ways to answer this new question.

As an example ‘What is a carrot?’ might be answered by ‘it is orange’ ‘it is a vegetable’ ‘it is a food used in cooking’ ‘it is a prop used at christmas to make a snowman’ ‘it is food for a pet’. So, new product opportunities – can we sell other vegetables? can we use or sell carrot recipes in store? Should we promote it at christmas as a thing to use in your snowman? Can we sell to pet owners?

Why I like the 6 Ws

* Its a framework that is old

There are records of this framework being used since 1st Century BC in Greece. Which suggests to me it has some value, if the framework has survived for this length of time.

* It feels like a solid set of lenses with which to review a stated goal

* It is as flexible or rigid as you need it to be

If your organisation, or a part of it, needs to ask specific questions, you can use the 6Ws to define those questions.

If you’re exploring a fuzzy goal, then you can start with each of the 6Ws. Given a particular W, what are the useful and interesting questions?

* Its strategic and tactical.

If you apply it to a tactical goal, it works, or you can apply it to define strategies.

A general set of the 6Ws for a project might be:

• Who is going to do the work?
• What are the roles and responsibilities of the people involved?
• What does success look like?
• What work is required, to achieve the project goals?
• What does this project depend on?
• When will the work be done?
• Where will the work be done?
• Why are we doing the project?
• How are we going to do the project?
• How can we measure success?
• How does this project fit with our strategic objectives?

I’ve seen these questions on every project I’ve taken part in, but some of the projects that have had problems have not had clearly defined answers to these questions.

* It can be easily understood and applied by teams with a variety of disciplines.

* It can be managed.

If the process of the 6Ws results in too many questions, a manager can prioritise the questions.

The most exciting reason for applying the 6Ws:

Using the 6W framework leads to better, and faster, understanding of the issues involved to achieve a goal.

A well defined goal should be able to answer questions for each of the 6W lenses. Once a goal is well defined, a clear supporting document – for example writing a creative brief, or a strategy document, or defining business objectives, a project plan,  or clear user stories and acceptance criteria becomes much easier.

Its taken a while to write this up, but on January 2nd of this year, we conducted a little social media experiment with The Archers.

The audience were invited to tweet their reactions during the 60th Anniversary broadcast of the show. We built a web experience for users to enjoy. This experience summarised live reactions to the unfolding storyline in the Archers.

We also built a ’summary experience’ for people to enjoy after the episode.

Screen grab of the archers tweetalong

The hard work was largely done by the Radio 4 interactive team, and the BBCs social media team, and a company called metabroadcast. [Who are rather excellent at their engineering and getting stuff done]. My role, as usual, was to lead the information architecture for the BBC.

This project comprised an audience experience, with a content management system including integration with the ‘twitter firehose’. The entire development took just under 5 weeks over Christmas. A great example of us doing agile development.

There are several interesting parts to the information architecture:

Despite a careful social media campaign, the hashtag that got used most by the audience was not one prescribed by the BBC, but one prescribed by the hardcore fans, on the archers message boards. They picked up on the marketting that had been done, suggesting that events in the 60th episode would be ‘Shaking Ambridge To The Core’. Their chosen hashtag? #sattc.

Naturally there were several other hashtags in use, each of which had to be monitored by the content management system. For example #archers #thearchers #archers60.

The content mangement system we built can be reused for many other dramatic events. For example, Metabroadcast used it for covering dramatic news in Egypt. It would also work on Xfactor, The Apprentice or any other broadcast where there is a controlled vocabulary of terms (eg peoples names).

Different users refer to the people involved in the drama in different ways. For this reason there are a set of synonyms for a particular term. For example, in The Archers, fans refer to Helen as ‘The Ice Queen’. It’s important to capture this reference to Helen and attribute it correctly.

The word cloud needs to reflect audience sentiment, but also block rude terms. So, our moderators had full control (including revoking approved terms, in case they made a mistake) and could look at the unmoderated list of terms, choosing which are appropriate to be published.

Similarly our moderators have full control over ‘Highlighted tweets’ and can also select a host account to be highlighted in the experience (in this case @BBCthearchers with a title of ‘Plot’ – see the above screengrab).

One of the interesting results of this work was the idea that when you’re moderating in real time, you can actually moderate too quickly for the audience! The highlighted tweets were, in my opinion, updating to quickly to be read by users -  something quite distinct to real-time experiences.

The experience seems to work best if it starts slightly before broadcast, and ends after it. That way you capture the lifecycle of the episode – from anticipation to the broadcast, to the aftermath.

I really enjoy the sense of connection that these experiences can bring. It feels a little similar to watching a film or theatre in an audience – the sense of joint participation and connection with the unfolding drama, it’s one of the compelling things about social media in general.

There are many things I would improve about the experience, but I think given the time and effort that we had available, I’m very proud of this work.

All credit to the audience and social media team for the fact that the Archers trended worldwide for an hour on January 2nd 2011. Not bad for a drama that’s been running 60 years .

If you’re a UX professional, I suspect you’ve used Lorem Ipsum dummy text in your deliverables.

I’ve done it, but I don’t want to anymore.

It appears I’m not alone, but Lorem Ipsum dummy text in UX deliverables does us no favours. It adds confusion.

One of my main concerns at the BBC is to check if we have the metadata and content to deliver a great user experience. In my role as lead Information Architect for external projects, I often review wireframes from agencies. It has made me realise a really common question. “What is this text here?” [*points to dummy title or copy text*].

In a large data driven website (for example almost any website delivered on bbc.co.uk) it is important to know if a design will work in practice, given our metadata systems. A wireframe that has dummy text ‘This is the programme title’ as dummy text is much more easily understood than one that states ‘Lorem Ipsum’. “This is the brand title (maximum 90 characters)” is even better  – it implies that you understand the data system being used to populate the wireframe, and makes it easier to understand if the design works.

So, lets all use better, more descriptive dummy copy please – copy derived from the underlying data and domain model is best. Lorem Ipsum, just say no, right?

I’ll be honest, I’m not a big fan of blogging.

At the Information Architecture Summit 2009 in Memphis I gave a talk titled

It went well(!), and those at the  more technical end of the IA skillset seemed to enjoy it. All good.

After my talk I kept being asked ‘do you have a blog’?

‘No’.

Up until recently my attitude to blogs was ‘they’re online diarys for people that want to shout about how great they are’. I’m not sure my opinion has shifted that much (oops!).

However, over the last year, I have found myself reading some excellent, informative blog posts. Posts like “How we make websites” are examples of the blog posting I like. Its informative, and it helps us all learn and develop.

So, that’s what I’m going to try and do here. Its a chance for me to share and learn from others.

I don’t expect to post often.

But sometimes…..

Thanks for reading, let me know what you think of my posts, and I look forward to learning from you.

C