Here comes the heresy: isn’t that what those ‘people’ are? Users of our products? I don’t think that the term itself is derogatory, but our industry has made it derogatory in that we usually picture the bottom of the barrel when discussing users.

Therefore I believe that the real challenge lies in changing our thinking rather than our semantics. We could refer to users as “geniuses” and still reference them in a disparaging tone. In my mind “user” is still a term for people and it does not have to have a negative connotation. It was a term created to set them apart from the developer and the client. This is the person who is going to use the product.

But I’m not totally dismissing Norman’s point. I do agree that we need to be specific in our terminology when referring to users. Sometimes one product will have multiple users and many different roles. Creating personas is one way to deal with this. For e-commerce sites you can have “Sharon the Shopper” and “Mark the Merchant.” This allows you to get to know your target audience and think of them (as Norman requests) as people.

In the end I agree with the need to put a face on your ‘user,’ but I do not think we need to change our vocabulary when initially approaching a project. Instead we need to take on a more difficult challenge; we must change our thinking. I believe Alan Cooper has the right approach when he says, “Think of your users as intelligent but very busy.” Design for easy, efficient use that compliments your user’s strengths and supports their actions. They are our audience and our partners in design; work hard to get to know them and give them the best experience possible.

Like a typical time-crunched yuppie, I don’t get to cook a decent meal nearly as often as I would like and perhaps that’s why I look at it as a luxury. There’s a zen within chopping vegetables, sautéing garlic, and planning a well-rounded menu. Inevitably whatever I make tastes better than what I would get at a restaurant because I invested time and thought into it. I know what I’m going to consume and it’s not some junk food out of a microwavable box. It’s my own expression and it can be as complex as I wish.

Food isn’t fuel. It’s an experience that you concoct for yourself and others. It’s a chance to sit down, relax (read: stop multi-tasking!) and socialize.

You’ll remember my brief yet oh so true rant about my coffee pot. Well now I have a new appliance based enemy: the alarm clock. It’s a terrible experience to wake up scared every morning, yet I’ve had that same awful alarm clock for the past 7 years. The fact that I could avoid waking up every morning to its screams hadn’t even occurred to me until a co-worker mentioned that they never used an alarm clock. “You wake up every day of your life- why do that to yourself? Why wake up startled every single day?”

I was reminded of what they said when this morning the awful experience left my heart racing and my resolve firm. No more! I’m researching alarm clocks that allow me to have a better experience and not wake up flailing for once.

People have recognized this problem and have started designing some good ideas. Of course, I’m checking the reviews to see just how effective they are. As with anything, some of these have design flaws that ruin the entire product’s intended purpose. Others are somewhat pricey and I’m weighing cost versus my morning terror…

Regardless, I  refuse to wake up in fear anymore (and I don’t think these spunky alarm clocks will help). No matter how heavy you sleep,  there has to be a better alternatives than the clock radio that some sadist dreamed up.

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.

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.

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.

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.

Jumping right into it:

Learning the goals and the motivations of the user is key to a successful product. And how do we do this? Read about our subject? Make half-cocked, harebrained assumptions about who they are and what they want? No! We go to them. We put ourselves in their environment and learn their needs.

Maybe it’s my delusions of grandeur, but I like to think of myself as an ethnographer. I am there to observe, to enter with no predispositions or ideas as to how I think they operate. I enter with a blank slate and view this climate with fresh eyes.

Shadowing is a well-known method of user research. Trailing behind your subject, scribbling notes, and muttering quickly yet unintelligibly to yourself is highly recommended. Observe, take pictures, and most of all, take note. What are their surroundings like? What are the lighting conditions? What does their desk look like? What are the tools that they often carry around? Most importantly, as you take this all in, consider how you can support this environment and possibly even improve their work situation.

Another excellent way of getting to know your user is to talk to them. Imagine that. You might call this an interview but really it’s more of a dialogue and an opportunity to get to know for whom you are building. I’ve come to know this as a ‘non-directed interview.’ You are not there to barrage them with questions about things you assume they care about. You ask a question to get them going and follow their lead. Prod areas that need more detail and when things derail, offer a simple, ‘could you go back and tell me about ____.” A related note is that people love to talk about themselves (despite what they would have you believe), so if they can spare the time, be there with a recorder, a notebook, and plenty of writing utensils.

After you interview a good selection of users, transcribe your interviews (or, if you have to go the more time-conscious route, paraphrase) and review their statements on paper to tease out important tidbits. Goals, statements, motivations- it’s all there for you to review and pick up on patterns of behavior and stories. These will serve you later as you delve into the users’ environment for clues as to how you can support them.

• Motivations
  • Interviews
  • Personas
  • Scenarios/user stories
• Modeling
  • Activity model
  • Task flows
• Ideation
  • Paper prototyping
  • Design studios
  • Design strategy sessions
• Creation
  • Wireframes
  • Mockups
  • Styleguide
• Technical Prototypes
  • Flash
  • HTML/CSS
• Evaluation
  • User testing
  • Design principles review
  • Heuristic evaluation

I’m looking forward to it as I’ve been meaning to explore each aspect of the process in depth for some time. I’m hoping others will find it useful, and certainly let me know if you have something to add to the list.

The idea that I really loved was what he called the ‘Super Graphic.’ It’s a large, easy to read visual display that includes many factors in order to drive home your point. One such example can be found in his book ‘Beautiful Evidence.’ In it there is a map created by Charles Joseph Minard which displays the French army’s losses in the Russian Campaign. Minard conveys several factors in a very concise, visual manner: the amount of men over time, the dates in which the campaign took place, the army’s path to moscow, the falling temperatures, and where the greatest losses were incurred.

Tufte said that when you start a presentation by handing someone a super graphic, it allows them to process the information from their own point of view and peak their interest. In order to support your presentation well with a super graphic it should show comparisons, contrasts, and causality. Not only that, but because you’re showing something with many dimensions, you should convey more than two or three variables because a real world problem is multivariant.

Tufte’s books are full of historical documents that convey information in a variety of ways, and I love what it implies: that we need to get back to basics. That we need to set aside the powerpoint, stop worrying about fancy technological ways to convey information, and just sit down with a pencil and draw out what we want to say. Focus needs to be on analyzing the problem, solidifying the explanation, and proposing a solution rather than worrying over how our graphs created in Illustrator look. As always, it’s not about the medium-  it’s about the subject matter.

After discussing this with a friend, she told me that she had once taken the time to print out a report for the big cheese at her company and placed it on his desk. Later, he came back to her and said that he was so impressed that she had taken the extra effort to deliver it in person rather than through email. He had been able to take the repor ton a business trip, analyze it for himself, and come back to her with questions.

I’m all for saving paper, but I really do believe that creating a tactile presentation that someone can hold and take home for later makes a major difference in its ability to impact them, even if it’s only a simple report. Let’s get back to basics, intrigue our audience with our findings, and give them something to hold on to and remember.