December 8, 2013 7:16 am

As User Experience Designers, we have to answer the dreaded question time and time again. “What is it exactly that you do?” Do you design what’s on the screen? Well – sort of. Do you make the wireframes? Yes, and then some. Do you work with clients, and their users? Surprising to most – that’s actually the most important part of what we do.

This is all a bit bizarre for those outside the inner circle of the design community, since the idea of User Experience is a relatively new concept. The rise of User Experience Designer as career path has been unprecedented, especially considering that it was just coming into existence as I was studying to work in the field. The tools which we use daily are drawn largely from Industrial Design, Ergonomics and the Cognitive and Behavioural Sciences, but also from a lifetime of paying attention to patterns in User Interface. (User Interface: any thing, physical or digital, that I have to work with in order to get something I want.)

As UX Designers, we build tools to test theories, refine user touch points (physical, human, or digital), and encourage user-driven engineering in organizations that typically see the world through code-colored glasses. We’re involved in the high-level conception of products, working directly with Product management and closely with User Experience Researchers. Research is what gives us the kernel of insight that sparks the idea for a new solution. We work to develop the “flow,” which is the series of touch-points making up a product experience. We’re also often involved in product development at the detail level, refining elements of the visual design for clarity, consistency and appeal. UX Designers are always looking to make an imperfect experience simpler, smoother, and more delightful.

In the name of getting a deeper understanding – here are the things we do & the tools we use from the conception of a product to the beta launch:

User Research

Ideally, we would have the luxury of working directly with a Researcher, but in many companies that’s not the reality. There isn’t always an understanding of the value of this role, or there simply aren’t enough researchers to go around. We often have to advocate for research and conduct scrappy studies ourselves.

The two main kinds of research we use are quantitative and qualitative. Quantitative research yields numbers (eg. 35% of our key target group has an understanding of our policies). This research can be quite complex, but a simple approach might be to run an online survey. Qualitative research on the other hand explores how people behave and why they behave that way. This used to mean conducting a focus group- but it’s important to note that there is often a gap in our users’ perception of themselves and their real existence. That’s why it’s important to do and observe, rather than just asking. There are a very wide variety of tools and methods available to Designers for conducting participatory qualitative research. These might include:

-cultural probes
-card sorting
-storyboarding
-acting it out
-participatory design (literally sitting with users as you design a product together)
-paper prototyping for guerrilla user testing

I realize that I’ve just listed titles here – I think that this list necessitates an article in and of itself. In the meantime, an excellent resource is Elizabeth Sanders’ Maketools. There’s also this great explanation from Jacob Gube on Smashing Magazine.

Creating a shared vision

Whether working as a freelancer or internally at a company, it is the role of Designer to bring together the team in the name of a shared vision. There are a cavalcade of experts – in management, engineering, and marketing to name a few, with different perspectives on what is most important. Designers use a number of tools to direct the design process amongst these stakeholders and communicate a vision:

-design sprints
-personas
-user journey mapping
-prototyping (paper, powerpoint, high-level adobe software and click dummy builders etc.)
-storyboarding / storytelling (sketches, photos, videos and acting it out)

The goal is to eliminate cloudy goals which lead to wasted time. An expert can collect the knowledge of stakeholders and bring the key insights into the project. It’s only after research and team communication that the actual design can take place.

 

Low fidelity prototyping

As part of the process of creating a shared vision, and/or after this vision has been created, low fidelity prototyping is often used to flesh out the product. We test the prototypes with users (in casual or lab settings) and iterate on the prototypes based on the outcomes. Here are some of the tools:
-flows
-whiteboard diagrams
-wireframes
-paper prototypes
-click dummies
It’s important to increase the fidelity of prototypes as is necessary for communicating with other designers, team members and project stakeholders.

High fidelity prototyping

Once the flow kinks are worked out, moving fast to high fidelity prototypes is a must. I find myself shrinking the gap between steps whenever possible to speed up the process. This is a luxury of working internally, since the stakeholders and team members tend to already have a great understanding of the process. Here’s what I mean by high fidelity prototype:
-visual designs of screens or communication materials
-motion designs (animations)

A process of testing and iteration is generally recommended with the visual design as well. I’m not a visual designer myself, so I can’t speak to this process as much. However, I do my best to include visual design as part of the testing needs and ensure that it is communicating the right message. When the final visual designs are complete, a spec document is often produced. This is a detailed diagram of layout, spacing, colours, typefaces and other details about the design. The goal of the document is to make implementation as easy as possible.

Implementation

In the software and industrial design worlds, designers work with engineers (software, hardware) in order to get things made. I’ve written about these steps as a clear linear process, though it’s anything but. As a designer, it’s important to collaborate with engineers at every stage in the process in order to avoid technical pitfalls later on, and to take advantage of their own interface expertise. Designers in the software/tech fields should also have a basic or intermediate understanding of code (in fact, many have computer science degrees themselves) in order to work well with engineers and find creative solutions when faced with a challenge.

 

Testing

As a freelancer or working internally at a company, under no circumstances should a designer forget this step. Testing any designed product is essential, since engineers are not trained to see the world as you are. Spacing issues or typography choices that look like glaring, unmistakable errors to you are functional code to someone else, and it’s your job, not theirs, to catch it. (Though any engineer worth his salt will be professional enough to fix it.) Thoroughly test every website in all the browsers you care about, on all the platforms that matter to your users, or expect that there will be mistakes. That’s the professional standard.
You should:
-ensure compatibility across devices, mobile and desktop
-ensure that internationalization and localization are correctly implemented
-address edge cases and bugs, and
-learn from feedback in order to refine

At this point, you’ve found the errors in implementation, and discovered some of the weirdness that should be ironed out of your product. Hooray! You’re ready for Beta.

The most interesting part of this process is testing with real users when you release your product into the wild. Users always seem to find new ways to use your product that you hadn’t imagined.. and new ways of breaking it, of course. That’s usually when we start again, iterating and iterating.

---