Toolbox Series: Scenarios and User Stories

Scenarios

I think a quote that sums up the essence of scenarios can be found within Dan Saffer’s Designing for Interaction:

“Scenarios provide a fast and effective way to imagine the design concepts in use. In a sense, scenarios are prototypes built of words.”

Taking a persona, you can create some different scenarios for your user to walk through to further examine and understand what kind of system they need in order to help them with their day to day tasks. Not only are you uncovering gaps in functionality and justifying current design decisions, but you are experiencing your design with a fresh perspective which allows you to understand what ultimately needs to be in the final product. You also uncover different wants and needs when you use different personas within the same scenario. A scenario saves time that might be spent making storyboards and wireframes that will undergo heavy editing after feedback. As Saffer says, a scenarios simplicity can be equated to “a sketch with words.”

Ah, but there are pitfalls to the seemingly simple scenario. Don’t let yourself write a “scenario” that is long-winded and includes implementation language such as which link the user has to click to get to a certain page. Along with not letting your scenarios get tangled up in code, don’t allow yourself to include extraneous information that is not relevant to what the persona is trying to do. As Indi Young notes in Mental Models, that information might be better off in the actual persona description, rather than bogging down your scenario.

User Stories

Originally I listed scenarios and user stories together in the toolbox series list, and though the names sound the same they really are quite different, so i thought it was worth expanding on. A scenario is a way for the interaction designer to imagine design concepts in use while a user story is a way for an Agile project team to plan out solutions for the product and estimate the amount of time implementing such functionality will take.

According to Mike Cohn’s User Stories Applied for Agile Software Development, a user story prompts people to write the story, discuss the story between themselves and clients, and finally to test the story. Most of all, a user story is a representation of functionality that will be valued by the user and the purchaser. One pitfall of user stories is that technical jargon such as ‘Form will be built using telerik controls’ fall into the story, and that makes for a bad story because that is purely for the developers; the user and the purchaser do not care how it works, but what it does.

Cohn also states that a good story is:

• Independent because if you have stories that intertwine, it can be difficult to prioritize and plan solutions
• Negotiable and able to be discussed amongst the project team as well as the customer.
• Valuable to user or purchasers as a purchaser may be interested in configuration information while a user may not.
• Estimatable so that a team can understand and evaluate how long a solution will take to build
• Small so that they can be used easily while in the planning phase.
• Testable so that developers know when they have finished that particular part of the project.

Pieces of the Puzzle

Both scenarios and user stories work to define solutions for your users and maintain flexibility before any major prototyping is done, but there are fundamental differences. Ultimately the scenario is a sketch of the system to be used in tandem with personas in order to understand the needs of the user. User stories are a tool of the development team to estimate time and discuss methods of desired functionality. Both are key in Agile development and are necessary to make a successful product that will result in happy users.

BA vs. UxD: Beyond Thunderdome

A co-worker challenged me (not in the traditional duel sense) to define what the difference is between a Business Analyst and a UX Designer. I replied with my stock answer of, “BA’s define business requirements and UX Designers define user requirements.” “What’s the difference between business requirements and user requirements? Doesn’t the user comprise the business?” I then replied with, “Not technically” and floundered for awhile before finally giving up and saying that I needed to articulate my thoughts and get back to him.

It’s one of those things that for the past year I’ve taken for granted. For me it’s like asking why the sky is blue and the clouds are white- they just are. I had taken the definition of the two roles as simple enough: I was the designer and the BA was the typically the Subject Matter Expert (SME). They would gather technical requirements, pass them on to me and I would design an experience built upon those requirements. Easy enough, right? But upon my co-workers question a thought occurred to me- one that had been scratching at the back of mind for awhile. I knew my process and documentation like the back of my hand and had evangelized UX like it was the last salvation for software- but I didn’t know the BA’s process at all. All I knew of it was a small percentage of the documentation they generated that was passed my way every now and then.

So what better way to figure it out than to ask? After trimming down the feedback I came up with this: The BA is concerned with the goals of the client’s company, the technical requirements, and how data interacts. The UX person is concerned with how the technical requirements are presented to the end user, how the program flows, and creating a usable system with which the user can accomplish the company goals that the BA has laid out. Business Analysts, as the name implies, view things from more of an implementation and business perspective whereas UX follows the users’ mental models (which is why we make such a concentrated effort to get to know the user).

Another way to put it is that the BA looks to accomplish the goals of the client with the product while the UX Designers design so that the user can accomplish the goal of the client through a well-thought out experience.

That seems to make it clear enough for me, but then again I’ve been over-analyzing it all day, so comments, additions, and critiques are more than welcome.

Negative blockers and tiny gods

It seems so obvious now that it’s laughable, but until I started working in such a large company, I had never realized how key communication and collaboration were in the development process. It was a naïve notion, but I pictured designers mocking up the UI, ‘throwing it over the fence’ (or in this case, the cubicle wall) and having the developers go at it. In my mind, that’s how the process went. Of course, now I realize that it’s about constant communication and the discussion of ideas so that everyone has a personal investment in the product.

In a perfect world, the designer and the developer would work in harmony, traipsing through fields of wireframes and code with utmost respect for each other and open minds eager for revisions. We have good intentions, but that’s rarely how it goes. So when I came across two great articles that detailed the at times tense dynamic, I couldn’t help but send it out to my department.

“These are amusing to read, but basically can be summed up in a few words: collaboration is key to success. Sometimes developers and designers clash over aspects of the development process when instead they should be discussing and brainstorming. These articles detail how these conflicts arise.

One discusses how designers can become ‘the negative blocker guy’.

Another details how programmers can become fickle gods of their code universe.

The articles are part of a series entitled ‘Things I learned the hard way.’ Let’s not learn it the hard way and instead keep these ideas in mind while developing together.

As it says in this article referencing this series, ‘It’s about approaching developers as co-conspirators in producing great work: designers know what needs to happen and developers know how it can.’”

Both have great skills to bring to the table, so let’s become tiny, positive gods of the domain together.

Toolbox Series: Personas

Some might put a persona, or user profile, in a different area of the process but for someone who enjoys a good narrative like myself, it’s helpful to get to know your user. After I interview and have a strong sense of the end user I usually create an initial draft. Then I run it by a subject matter expert, revise, and hand it out to the project team and facilitate discussion over  the working persona.

A persona not only aids your team in having a common person to talk about, but it also helps you imagine what Mike the Mechanic or Joe the Jet Pilot would prefer when it comes to those big decisions. In the past I’ve handed out a copy of my created persona to my project team so that they can offer input and we can all become acquainted with the user. And magically, the ‘user’ is transformed into a person with a face and name.

The persona is formed from a conglomeration of multiple target users and from there, determining your ‘archetypal’ user that reflects the users’ goals and motivations.

There are many different ways to go about organizing the actual data of the persona, but the method that I’ve found to be short, sweet, and helpful to the team is to create a personal background with some demographic information, motivations for the persona as related to their job, and how the system can support those goals and motivations. For example, Arthur the Operations Manager is a 30 year old college graduate that climbed up the company ladder to where he is today. He’d like to open his own company after gaining more knowledge in the Logistics field. He looks for accuracy in state of inventory, wishes to maximize revenue, and promote good communication between the team and his superiors.

Quick, simple, and has some staying power with the project team. It also helps to have a friendly photo of the person at work so that they can associate that person with the duties they perform on the job.
It’s a surprisingly simple artifact once you get down to it, but it makes a world of difference in your team’s communications.