An Education in User Centered Design

UX Study Review Image

I received my certification in User Centered Design (UCD) from the University of Washington last summer. Before spending two years in the Human Centered Design & Engineering Department, I had a clear idea of what I wanted to get: I wanted to justify my decisions as a designer.

A couple of years later, I realize that goal extends beyond any individual or position- including my own.

School: What I Got

I started the UCD program around the same time I started my current job. My daily activities put me in a good position for applied learning. I could see how things I covered in the classroom could affect real work. I could also got to work on a scale and with resources that weren’t going to be options for my small team in the professional world.

The best part of a graduate school class in UX design was the hands on experience. I rotated quickly through projects with many groups of people and put the things I’d read about to work. There was lots of practice, but I admit that I practiced some things I don’t use much. Other valuable takeaways were:

  • Familiarity with resources. I’m aware of a lot of studies and processes available to me.
  • Familiarity with context. I know when those resources are an asset to my work.
  • Technique. Through practice and study, it became easier to design and execute studies properly. You learn to wear the right hat when you test.

Still, these aren’t the most important things I learned. My big discoveries were a result of combining my academic experiences in the evening with my work during the day.

My Top Lessons for a UX Designer

Being a designer, I was always worried about making the right plans. I didn’t have confidence in my work because I couldn’t see it’s effect. I eventually learned that seeing the immediate impact of design work is only a very small part of User Experience design. I was right in assuming that UX research was a way of confirming your work, I’d seen enough results to know I wanted that.

What I failed to realize is that the assumption should fit into a larger plan. My work as a designer is a very small part of achieving a goal, and the User Experience is affected by all the components in the larger plan- of which I was only a small part. I learned that in order to be a better designer, I’d have to find ways that the user’s voice could improve the plan for everyone. So, in designing and building web experiences professionally while working my way through User Centered Design courses, these were my top takeaways:

 

1.) UX Testing Will Confirm or Dismiss Your Assumptions:

It’s about as high level as you can get and it’s one of the first things they tell you. It’s true.

This is worth recalling every time you or someone on your team utters syllables. As plan making cogs in a larger plan, we devise paths to our goals on our way to the business’ goals. Sometimes the routes are questionable. A critical attitude towards assumptions (paired with a friendly disposition :)) goes a long way. Lines like “we should test that” and “cool, do you have the data?” are indispensable. We can all make recommendations based on our professional knowledge, but even those theses come from experience and data derived from the history of our occupations.

Finding easy ways to get quick results will encourage a more critical process and help you cultivate a more user-focused culture. You always have the ability to put things in front of users. Emailing relevant friends and acquaintances a design with 3 questions can quickly confirm or dismiss some assumptions (if questions aren’t leading or confusing). There are also affordable online tools, like UserTesting.com, which will let you take your research a step further. It’s important to remember that these results aren’t cataclysmic, you’re piling the grains of sand that will make the bricks that will make the pyramid.

2.) Present your findings.

Research results only matter if they’re applied to the decision making process. A lot of that process is design, but it can come from everywhere. If you’re harvesting user data, it’s on you to go out and inspire a reaction. It’s easy to create a handoff document or deck, hit send, and call it a day- but if you have the avenue to create a stronger platform, do it. Sometimes it’s just scheduling a meeting and presenting your deck.

Explain the problem, how it was affecting your team’s goals, the hypothesis and details of the test, and your results. Leave the floor open to conversation and you’ll see new paths to your goals surface. New assumptions will form and beg attention and some old ones will make their way to the back of the room. Some people will make an effort to defend old assumptions and sometimes they’ll drop those initiatives because you’ve revealed something else they’re excited about. If people can’t let go of a bloodied mantra, explore it. How does the research disprove the assumption? Does it? One test usually doesn’t, you’ll have to brainstorm other ways of testing the integrity of that assumption. Above all, be positive. It’s not a personal endeavor and you’re supposed to be working towards the same goals.

It’s important to make sure your presentation is in front of people from different disciplines. A room full of designers will probably miss things one business focused individual will see- and developers will let you know when something isn’t worth trying. Having a diverse audience is especially helpful when you’re finished, because you shouldn’t leave the room until you know what’s next: getting the people in the room to act, even in some small way. Often, this is planning the next test, or taking something from prototype to soft release.

3.) Iterate: Find the Crumb

Iteration is something that should happen constantly. You won’t know if your boat floats till you throw it in the water. Sketching the User Experience by Bill Buxton, and the follow up workbook (Sketching the User Experience: The Workbook), are great for learning how to implement lo-fi iteration and improve your end product. Small scale iterations get you the quickest results. Don’t try and make the whole thing right away and then remake it eight times. You’re going to have to whittle your way down from proving the very high level ideas to deciding the details.

When I returned to the classroom two years ago I was busy with the details. Now I try and put something representative of the product in front of people right away. You can also test parts of a product. It can be overwhelming, and dilute the feedback of participants, to expose them to a large experience. Big tests can also burn up all your, and your team’s, fuel. If something seems arduous, no one’s going to want to do it.

While the idea of “sketching”, or getting quick iterations into the world for feedback, is driven by an iterative mindset, iteration serves a larger purpose. Your team’s assumptions are iterative also, some will be disproven and others will evolve. There is no doubt that the path between you guys and your goals will change, sometimes going a few steps back. You’re not just working on the design, you’re working on the plan that will get you to the goal.

Jimbo Fisher, the coach of the Florida State football team comes to mind here. He had a line I keep with me every day, “find the crumb”. It’s something I heard him say in an interview after the NCAA National Championship game. It’s incredibly important to keep chipping away. Every iteration, whether it’s a design, a prototype, or an idea is just the next little step toward your goal. The key is to keep your goal in mind and keep looking for that next crumb.

Moving Forward

If I had to do it again, I’d do it exactly the same. It’s not easy to work full time and go back to school- but for UX design and research, it helped me understand the context of what I was learning. I recommend it wholeheartedly. Anything you can do to perpetuate the conversation that will get you toward success is your job as a Designer.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>