The Young Grasshopper Reflects

Inspired by this blog entitled 101 Things I learned in interaction design school, I wanted to take a moment to document a few of the things I’ve learned from the school of hard knocks, i.e. being tossed in the pit of software development. I was very lucky to work with a dynamic team, and these are just some of the thoughts I came out with. Naturally, reading awesome blogs like Smashing Magazine and A List Apart definitely helped.

And lo! I give unto you a few of the things I learned while in conference rooms, standing before a whiteboard, and while hiding behind a sketch pad.

1. Open minds and active listening are key to success.
2. Always ask, ‘Why?’ How is this feature providing benefit to the user?
3. Mapping out purpose will provide the pathway to functionality, design and flow of the product.
4. Developers and designers come from two different viewpoints and have so much to share with each other, so always respect each other’s role in the process.
5. Clearly define scope of a product from the outset and beware little additions along the way.
6. Drawing on a whiteboard together will provide clarification of ideas and more often than not save a lot of time.
7. Your design is going to continually change. Don’t get hung up on your “vision” because you might just be blocking improvement.
8. Learn to take criticism well, and learn to give it constructively.
9. Taking a lo-fi wireframe or sketch to a meeting typically encourages a more lively exchange of ideas as people realize that this is just the first iteration of a final product.
10. Never hesitate to take an incomplete idea to a team member and brainstorm; it can help you get past roadblocks and provide some really amazing ideas.

Aligning Inspiration

When a friend is trying to get their name out quickly with a promotional site, I tend to recommend that they choose an image they love and begin to build a theme off of that. When my friend Stephanie, the soon to be famous Brooklyn based editor, requested a quick site that would serve as a launching point for her demo reels and video clips, I suggested she patrol istockphoto and see what she found. When she returned a few images, I quickly threw together a couple of suggestions that mainly relied on colors from the image and alignment. My other concern was that they could be coded quickly, so I kept it simple.

We passed ideas back and forth in this way and iteration was quick- the beauty of working on a two person team. This isn’t always a feasible method, but when working with a friend it was an enjoyable experience. Nothing beats playing around with a meaningful image and subtly making fun of your friend in the dummy text. It’s one of those priceless gems I hold dear when working for free.

(late) Adaptation

I was talking to my father sometime before the HDTV conversion, and he was complaining that the VCR couldn’t record shows anymore now that he had installed the converter box.

“You know,” I said, rolling my eyes at the fact that he had been recording TV shows on VHS for at least 20 years, “They’re going to stop manufacturing VHS due to their decline in popularity.”

“I know! That’s why I went to the store and bought them in bulk!”

I tell this story not to mock my father’s determination to hold on to analog technology but to give some background on why I’m such a skeptical adapter. I figure sure, maybe I’m not the first on my block to have the iPod but I was certainly right to have my reservations about Laserdisc.

Then I saw this article via Sean Biefeld and couldn’t help but admonish my own reluctance. I mean, Ray Bradbury is 89 years old. He has a right to hate new technology. I, on the cusp of my twenty-fourth year, have a lot more to see before I can begin shaking my fist and naysaying those meddling kids. And if you don’t adapt quickly, you will be left behind. Even more frightening to me is that I will not be able to innovate.

So bring it on, brave new world. I’m ready and willing…as long as it doesn’t cost me too much money.

Here Comes the Heresy

I’m going to commit heresy by disagreeing with Donald Norman’s article, “Words Matter. Talk About People: Not Customers, Not Consumers, Not Users.” In it, Norman proposes that we stop dehumanizing the audience for our products by calling them ‘users’ and refer to them as ‘people’. He recognizes the potential problem of there being multiple roles in the product development process (the people who design, the people that are going to buy the product, etc) but he states that it’s no excuse.

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.

Concocting an Experience

My senior year of college I took a class entitled American Food in the hopes that it would involve a lot of eating. Instead it was a large amount of discussion, reading and writing on the subject of food and culture. Despite my inner glutton’s initial disappointment, I gained an appreciation for food beyond its basic function of ending gnawing hunger. I learned that it was a social event, the sign of a culture, and an art form within itself. People studied it, wrote stories revolving around it, and I was fascinated. The way Ruth Reichl described a meal was so vivid and passionate that it was inspiring.

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.

UX of the Alarm Clock

Every morning I wake up frightened. Not for a legitimate reason such as a bear broke into my bedroom or I’ve had a nightmare where I live in a world without tex-mex ; no. I wake up every morning and frantically scramble to turn off the alarm that is so horrifically noisy and obnoxious it scares the bejeezus out of me.

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.

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.

Toolbox Series: User Interviews

As I was writing this entry, I realized that I had even more to add to the ‘toolbox’…so keep in mind that this is an overview at best of user interviews and there are tons of books out there dedicated to this subject alone. My large influences for this section would have to be Designing for Interaction, Mental Models, and of course, my coworkers. Questions, comments, and additions more than welcome as this series is meant to be a learning experience for me.

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.

Toolbox Series

I’m going to begin a series that will detail aspects and tools of the UX process that I’ve used and some that I’ve come across in my research. This will include (organized according to topic):

• 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.