#ui18

I attended Christine Perfetti's full-day workshop at the recent UI18 conference in Boston. I was really impressed with the way Christine welcomed and handled questions, covered a lot of material, got us talking and working together, and kept up the energy throughout the day. Here are my notes. (Many of these topics were reinforced with short exercises throughout the day).

In the first 90 days

Get to know your internal audience much the same way you would your users...finding out what they know, what their needs are, how they want to be involved in research and what they hope to gain from it.

For your first project, choose something where you have an executive on your side...she called this person an "Executive Champion."

Write up a Study Plan. To do this, get your internal audience together and discuss the testing process and what you want to learn, as well as details like the number of users, how you'll recruit them, and the schedule.

Then craft the tasks the users will complete during testing. She went through a few different types: ** Verb-based tasks - ask users to DO something ** Scavenger hunt tasks - ask users to FIND something ** Interview-based tasks - find out what real users' goals are, and asses based on those goals

Facilitate your first usability test

Facilitating usability tests

Christine gave a lot of good pointers on how to effectively facilitate a usability test, including:

Pre-test briefing to put them at ease

What kinds of questions to ask

How to respond to participant questions

Providing reassurance to struggling users

She also suggested a few quick but fruitful test (which you can layer on top of more in-depth tests):

5-Second tests

First click tests

Comprehension tests

Analyzing the information

Rolling list of observations. An ongoing record of user problems, actions, or comments, one per line. For each participant it is observed for, their number is added to the line.

KJ Method. This was one of my favorite portions of the workshop so I'm saving my write-up for a separate post. Here's my post on the KJ Method.

Journey maps. You can map out anything from a specific task flow, to the whole experience someone has with your product, from discovery to purchase to use, etc.

Communicating the Information

In general, Christine seemed to favor less formal, quicker methods of getting the word out about user research results. This includes email, using your current bug tracking system, or a quick meeting.

General Takeaways

As covered by many people throughout the conference: doing user research doesn't have to be -- shouldn't be! -- some big expensive ordeal.

Involve everyone. Don't do a bunch of research on your own and send out a report. Get decision-makers, designers, developers, etc. into the process from the beginning.

Last week I attended two-thirds of UI18, the user experience conference hosted by Jared Spool and his company User Interface Engineering. I wasn't able to attend the first day of workshops, but I heard 4 interesting talks (plus Jared's keynote) Wednesday, and on Thursday attended Christine Perfetti's workshop, "Jumpstart Your UX Research Program."

Buzzwords

Stakeholders the folks that might be affected by your project one way or another

Getting buy-in convincing stakeholders that what you're doing will be good for them

Lean obviously this has been around forever but basically being a lightweight, nimble team rather than a slow-moving behemoth

Ask when did this become a noun, as in "my ask is that you..."? Weird.

Takeaway shit you learned

General takeaways

There is no substitute for going out and talking to your product's users continually, at all stages of the design and build (and improve) process. It doesn't have to be fancy and expensive, but there aren't any good shortcuts.

Don't be lazy when you design. Don't just follow a best practice or an archetype of how something is usually designed. Stop and consider if there is a more fruitful approach that will add value and delight your users.

More notes

Jeff Gothelf: Axe Requirements-driven Product Design

Dan Saffer: Dig Into Tiny Design Details

Stephen P Anderson: Help Users Decide

Christine Perfetti: Jumpstart Your UX Research Program

Stephen Anderson (who wrote Seductive Interaction Design and Mental Notes) talked about thinking beyond the list, grid, and table when it comes to presenting users with information. Arguing that these formats present information decently well, but often fall short on providing understanding, he encouraged UX designers to think more creatively to help users understand and make choices.

Overall, this was more of an "inspirational" talk than a "how-to" talk. Stephen showed a number of interesting examples of his own work and others that revealed just how much the display of information facilitates or impedes our understanding of it.

A key shortcoming of tables, lists, and grids are that they generally fail to capture relationships. Or, with sorting, at most they convey a single relationship at a time. The most extended example he gave was a grid view of digital cameras available on Amazon. In his redesign, he didn't simply display the same data in different formats, he also chose different data to display (for example, removing number of megapixels and brand in favor of reviews, sample photos, and release date).

Key takeaways

Grids, lists, and tables are a somewhat lazy way of displaying information. When you spot these in your design, consider a couple of things.

Are you including the information that will be most important to users, to help them understand their options and make a decision?

Are you displaying the information in a way that shows not only the collection of data for each individual item, but the relationships among them?

My thoughts

This stuff is visually very compelling, but there are a couple of concerns I have:

Dev time. It has to be proven worth the extra time investment to actually build these complex, dynamic, and interactive displays. These displays may be straightforward to layout in Illustrator, but not so html, css, and javascript.

Jeff Gothelf (author of Lean UX: Applying Lean Principles to Improve User Experience) gave an excellent talk about the perils of "requirements-driven" product development: that is, starting with a list of features, functionality, etc. that you've just pulled out of a hat (or the CEO's head, or wherever).

A product requirement conjured this way, Jeff argued, is an assumption, an unproven hypothesis about users' wants, needs, and behaviors.

He started with a couple of rather sad examples of entire products or major features that took months to develop and utterly flopped because, essentially, no one wanted them.

Design thinking to the rescue

Jeff read a tidy quote summarizing what "design thinking" is:

As a style of thinking, it is generally considered the ability to combine empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality to analyze and fit solutions to the context.

The better approach, then, is to:

admit that you're starting with a series of assumptions

define hypotheses about what solutions might work

build lightweight prototypes to test early and often

He gave some good detail about how to put together appropriate "cross-functional" (I heard this term a lot during the conference), get funding and "buy-in" (another popular buzzword)...all of which apply to a larger company than I'm working in so I kind of zoned out during that part.

Key takeaways

Shift your thinking to prioritize learning over growth or feature output. When you do that, the approach above just comes naturally; of course you want to test with users early and often, because how else are you going to learn anything?

Focus on outcomes, not on building products or features. You ultimately want to engender a certain behavior, and the success of a project is based on whether you achieve that, not on whether you fulfill a series of product requirements.

Further reading

A collection of videos on design thinking

Stanford d.school's Design Thinking Bootcamp methods

Plancast post mortem

Much like Stephen Anderson, Dan Saffer gave a more "inspirational" than practical talk. They were both likely saving their more hands-on, practical content for their full-day workshops, so the 1.5-hour talks were just a taste.

What are microinteractions?

The topic of Dan's talk was "microinteractions". He first defined microinteractions in a few different ways:

a design's "smallest parts"

the "feel" in "look and feel"

shallow, fleeting interactions that require no cognitive load

self-contained "product moments"

the details of a product

He described the four parts of a microinteraction:

trigger - the interface element that initiates, or prompts the user to initiate, the interaction

rules - all the details of the sequence and behavior of the interaction

feedback - lets the user know what is possible, what has happened, what is happening, etc.

loops & modes - cycles, and the different states an interface can be in

Throughout the talk Dan provided some examples of successful microinteractions, from playful to just plain helpful (like GMail letting you know when you've claimed to be attaching something, but you haven't).

Much like Stephen Anderson's innovative displays of information, microinteractions can take a lot of time to design, develop, test, and generally do well. Dan talked about some ways to make the case for them (such as giving your product such an awesome microinteraction it becomes a "signature moment"). He also discussed ways to communicate microinteractions, like storyboarding and prototyping.

Further reading

Much of Dan's talk condensed into a blog post

An interview with Dan