UX Breakdown

I still remember the first time I was called “User Experience Designer”. It was many years ago, engaged as a consultant on a gig for Vignette.  We had decided to set up a test lab to test the usability of an application that we were building for some client.  That test group fundamentally changed how I designed websites from that day forward. Not because of what came out of the usability tests, but because I came to realize my psychology background had led me to this.  I now had the ability to manipulate the users into doing what I wanted! That prompted me to dig deeper into the world of UX, re-evaluate my processes, and dramatically shape my career.

While many designers hear a description of the term “UX” and reply, “Oh, that’s what I’ve been doing all along—I just didn’t know it was called that”, I was different. Before learning the term “UX Designer” even existed, my design process was already based off the questions we were asking in the user testing.  Why did the shopper abandon their cart?  Why didn’t they buy that thing?  Was the form too long to check out, can I see the server logs to see how far they got in filling it in? My husband was a network architect, so I knew there were ways to see the data, I just had to cozy up to the IT department and find the right people and ask the right questions.  But, that was before “User Testing” made it a whole new ballgame!  I got to SEE how users interacted with the site, when users were having trouble and why! Now there was a whole school of thought designed around what I had been digging through server logs to find out! Now I had analytics and testing and many more tools to find out these things! I was excited and now I looked for a company that used these principals and worked my way into Perficient who had a whole arsenal of UX people with pedigrees teaching me how to do user testing, cart sorting and how UX should make the applications I designed stickier!

Such is the power of UX!  It may be a buzzword, but that’s not necessarily a bad thing for those of us who design for the web. The principles, philosophies and techniques of which UX design is comprised are well established, and the good news is this: anyone can learn them, but few realize their worth in time. I have worked at companies all over the US who bring in UX too late, and realize their mistake. They find that they should have brought UX in sooner and their planning would have gone smoother, their development costs gone down and the whole experience more holistic.

So what does a User Experience Designer actually do? Well, there’s no typical day, however there is a grab bag of techniques that many UX Designers rely on at various stages of a project. I’ve expanded on a few of those techniques here, using panels from a short comic that appears in Everyday UX, an eBook containing interviews with 10 prominent UX designers:

Wireframes

wireframes A wireframe—a rough guide for the layout of a website or app—is the deliverable most famously associated with being a UX Designer.

Once created by designers as a series of static images, these days tools like Balsamiq Mockups and Axure RP make it straightforward to evolve your wireframe into an interactive prototype without writing any code.

While many UX Designers make a point that they are more than just wireframe machines, it’s certainly true that many UX Designers start with wireframes: creating a basic site layout is something anyone can do, and the tools are easy to learn.




User Testing

user testingSitting users in front of your website or app and asking them to perform tasks you’ve planned for them while they think out loud is the fundamental premise of user testing.

How many test participants you involve, how closely your test participants match your actual users, and how many iterations of testing you run are all decisions shaped by budget and time constraints. I believe in user testing for any product, even if it is a physical one. How will they hold it, where are the buttons? Every web application that goes mobile or is used on a tablet should be tested hands on with the tablet or phone. Does the user have to change hands to hit submit? Is the button close to their thumb so they can hold it naturally?

User testing is straightforward enough that anyone can—and should—experience running one. Being in the same room while someone struggles to use your product is a powerful trigger for creating empathy with users. I believe it will make anyone advocate for the users. Putting up story boards in SCRUM team rooms and having the development team witness and empathize with their users makes them more willing to make small changes when UX asks down the line. It may take time away from development efforts, but if that’s what it takes to make them empathize with their users it might be a value add.

Personas

personasA persona is a fictitious identity that reflects one person out of all of the user groups for whom you are designing. It should be the “average joe” that the application or product is designed for.

Personas need to be informed by research to be useful. It can be tempting to put on your creative writing hat and invent details to make them believable or interesting. However, the goal should be to have your personas reflect patterns that you’ve identified in your users (or prospective users).

There’s no shortcut for identifying these patterns—they come from user research: conducting interviews, surveys, user testing, contextual inquiry and other activities.

Scenarios and Storyboards

storyboardsA scenario is a narrative describing “a day in the life of” one of your personas, including how your website or app fits into their lives. If you’re familiar with writing user stories in an agile environment, you’ll be comfortable writing scenarios—although the focus here is on regular usage, not edge cases.

Depending on the audience, a storyboard may be a more appropriate tool for capturing how, when, where and why someone might use your product.

Inspired by the film-making industry, a storyboard is a visual sequence of events used to capture a user’s interactions with a product.

It may be an extremely rough sketch—purely for crystallizing your own ideas—or a more polished comic for engaging your audience more effectively.

Conclusion

This is just a sample of the hundreds of techniques that UX designers have available to them to ensure they get the right design—and the design right. UX is not just about making a product “pretty” but sticky and streamlining all the business processes involved behind the scenes. Getting into the process flows of how a returned item would work for even the business not just the user, and making that process easier to handle and be effortless so the end user chooses to shop again at your site is an undervalued and hot point where most companies can fail because of improper integration points. So keep in mind it’s not just the front end, it’s all of the application touch points within a business. So businesses have to learn early on where these choke points are, and that mishandling them can be catastrophic. You can have the best product in the world to sell, but fail on the returns and see the boards blow up your site for lack of empathy for the 2% that had a bad experience returning a few defective items. I speak of this out of first hand knowledge on all these hot points within an organization that go without scrutiny.

The trick is in applying all that you have learned doing UX and when and where to execute which technique.

But that’s a topic for another day…

References:

UX Techniques by Shu Wakasa
source: <http://uxmastery.com/resources/techniques/>

EVERYDAY UX by Luke Chambers & Matthew Magain
source: <http://uxmastery.com/everyday-ux/>

The Future of UX: Killing the Wireframe Machine
Published on November 8, 2012
Blog of Elisabeth Hubert
source:<http://www.elisabethhubert.com/2012/11/the-future-of-ux-killing-the-wireframe-machine/>