stevenclark.com.au

Sometimes there is a lot to be said for making up little stories. User Stories are provided at the beginning by the client and are a few short sentences on cards which represent a specific achievable minor function of the system. We talked again about writing stories with Personas which are a way of identifying major groups of users. We talked about writing Use Cases which record the system interactions in a formal way in terms of actors playing roles and striving to attain goals. Each technique has its own use and audience. So what about Scenarios? Are writing stories about the interaction as simple as they sound? How do Scenarios come together?

Scenarios probably fall into a timeslot somewhere after Personas and before Use Cases but there are no hard and fast rules. It really depends on the project, where you want to put your effort, budget constraints and time. Ideally we would do as many of these techniques as we could fit into the day but in the end constraints are a matter of business.

In a Scenario you are trying to capture the operations and interactions of the system in a non-technical way. You want to avoid technical terms and jargon. Logically you can imagine your Personas following Scenarios as a story of how they interact with the system and what functions they perform. The non-technical language is because they are intended for non-technical people.

Scenarios might help when you sit down with all of the stakeholders and discuss in layman’s terms what the system is meant to achieve. It helps the communication process if everyone is sharing a common language. Scenarios will also be very handy when you come to user testing and you want to observe how people effectively (or ineffectively) interact with your system / interface /website. Participants of the user tests will need some kind of mission to go on which you will effectively measure and compare their responses and performance to other users. Personas have a number of uses and are well worth developing earlier rather than later. It isn’t that uncommon to see someone trying to scrape them together after the horse has bolted and its time for usability testing to begin the following week.

If performed at a reasonably early stage in the design process a lot of issues can be spotted and ironed out way before they’re going to cost you money. So give it a go. Like a lot of really simple techniques its a very effective tool for capturing information early.

This entry was posted on Wednesday, August 29th, 2007 at 2:18 am and is filed under design, usability. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.