Mobile UX Design Approaches: Workshops

Workshops

Maybe it’s just that our UX methods need a better name. I normally call my quick gatherings of project stakeholders for discovery workshops, and most of the UX professionals I work with know what that term means without any explanation.

We use the term workshop in very much the same way actors use it—meaning a way to figure out how to make a stage play work better. By working together and getting everyone to contribute, we achieve better outcomes.

For design workshops, during the very earliest phases of a project, we get everyone who knows anything about a product, a project, a service, a line of business, or the domain for which we’re designing a solution together in a room. Workshops are not about what has already been built, but what the team wants to build.

These people have a lot of useful knowledge in their heads. Annoyingly, it’s inside their heads. People are often bad at analyzing and sharing. This is why classic brainstorming and other techniques that just gather people in a room don’t work well. But there are techniques that do work. A workshop is about listening and asking the right questions so you get the right answers.

Planning a Workshop

First, you must plan a workshop. I don’t mean just setting up a meeting time and making sure there is coffee. Think how long you prepare for a presentation to a big audience. The job of moderating a UX workshop is, in many ways, like presenting at a conference—but for days at a time. It takes time to prepare properly. You cannot just rename your last workshop and use the same plan again.

It takes about two weeks to do all the necessary research to make sure I’m speaking the right language to a team and create my presentation materials. I normally use a PowerPoint deck to guide the discussion, but you can put cards on the walls if you’re allergic to slideware.

Participants

Most important are the people participating in a workshop. You want to include everyone with some knowledge to share and especially those who can make decisions. But be careful about the crowd getting unruly. With too many participants, discussions can get unwieldy. If you’re the only UX person in the room, keep the team to a maximum of 10–15 people.

In the context of training, I have run workshops with over 200 people, but they participated in self-organizing groups, with only 5–10 people per table, working on their own little exercises. I’ve run a handful of design workshops for products with almost 50 people, and the same approach works best, with several individual groups, then a separate step at the end to merge the results of the various groups together.

One other thing to be careful about is not to include too many executives. While you could manage this, it takes additional effort to make sure they don’t exert undue influence. This advice is in direct opposition to that for GV Sprints, but it is rare for a CEO or any C-level leader to contribute much. They don’t have the tactical and operational knowledge you need, and that’s okay. Anyway, most of the people I know would giggle or roll their eyes at that GV advice because, in almost any company larger than a one-room startup, getting the CEO to attend your workshop for one of many projects is not going to happen.

This doesn’t mean you can’t get the most relevant senior people to attend your workshop. Learn the corporate culture—and the department or project culture if it’s different, which it can be—and invite people strategically.

Moderating, Advocating, and Transcribing

One way to handle a larger crowd is the same as for any guided experience: have more guides. While I often have to run workshops by myself, ideally, you should have a minimum of three people: a moderator, a user advocate, and a note taker.

The moderator must express no opinions—just make sure the right activities happen and that everyone is heard.

The user advocate, on the other hand, should argue points that ensure a solution meets users’ needs. All too often, a group may want to make decisions based on their internal process, jargon, legacy systems or methods, or engineering-focused solutions. You can get only so far by challenging them to think about the users, so you need an advocate for the user’s point of view. This can be challenging.

The user advocate is a key UX role throughout the process. To be a good advocate, you need to be able to express the proper mindset, but also to argue effectively. You should be able to discuss cognitive psychology, physiology, best practices, industry standards, adoption rates, and trends. You should get some of this information from the preparatory research I mentioned earlier.

Someone who’s not on the UX team can take notes, but that person won’t be able to participate in other ways, so it’s hard to pull the project manager or anyone else out of the session for that role. But, if someone is new and has no project knowledge, talk with him about taking on this role. He may be happy to do it.

Scheduling

There’s a lot of data to capture, so it’s easy to decide that you should schedule a full week, but that’s simply too tiring, and the group very rapidly starts finalizing decisions prematurely, without having the chance to look back, have others review your learnings, or analyze them.

The most productive approach I have found is to hold two or three half-day sessions, in quick succession. If you hold your sessions in the morning, your attendees will come in fresh, unburdened by the problems of the day, and it’s less likely that a crisis will interrupt them.

Logistics

If at all possible, hold your workshops away from the office. Clients came to our office for some of my most effective workshops. At least, pick a place that’s far away from the area where most of the team works. Meeting at the other side of your campus or building can help more than you’d expect. Getting away from your day-to-day environment helps focus the mind. You want to make sure people can’t run back to their desk during breaks.

The typical advice is to ask participants to set aside their phones and computers, but I find it is almost impossible to do this anymore. They may feel they’re being treated like children. Besides, people often pull up useful information you need during the workshop. If you provide interesting enough tasks, people will pay attention.

Be sure to provide breakfast and snacks. Have a plan for breaks. They shouldn’t occur on a rigid schedule, but whenever your exercises end or when people seem to need a break. If someone asks for a bio break or tries to sneak out and it’s not a terrible time to break, call a break for everyone right then.

Running a Workshop

Workshops differ from some other types of meetings in that they’re well planned and organized. You don’t just state objectives, then start talking. Break up a workshop into phases, progressing step by step toward a series of specific answers.

Orient

First, tell everyone what is going to happen. Do this at the beginning of every workshop. Recently, I kicked off a workshop and, two minutes in, someone raised his hand to ask what I was talking about. It turned out that the project was less far along than I had expected. We had to tell them what the point was.

Introduce

For much the same reason, an introduction is second. Introducing participants to one another helps make a workshop more interesting, without silly team-building exercises. Participants can talk about why their attendance is relevant to the domain, now that they know why they are there.

I have often seen people come out of a workshop with new connections to other parts of their company. People finally meet other people who are doing much the same work as they are or meet the consumer of their product or service.

Define

Define your terms. Experience has taught me to add this step, and I’ve seen it work well. I often get participants who don’t understand the terminology—or sometimes I don’t. Ensure that everyone is on the same page. Language matters.

Defining your terms is also a way to sneak in topics you might not otherwise be able to cover. For example, you can discuss what platforms you’re building for and the right way to build for them. When a business says what they want, they effectively use shorthand. For example, iPhone app just means a native mobile app, responsive Web site means a Web site that works on mobile devices. There’s not much understanding of where the boundaries are.

When I define such terms, it gives the team a chance not only to talk the same language, but also to broach the subject of why we’d do each thing—for example, to discuss Android versus iOS market share per region, adaptive versus responsive, and more.

Exercises

As quickly as possible, get people involved in contributing to the work. Use formal methods—such as the K-J method, or affinity diagramming—that involve everyone equally and give you documented results.

Use the right method for what you need to find out. I recently did a workshop where the team modified a large, user-taskflow diagram. I brought Post-its, scissors, tape, and other supplies, so they could change the diagram in whatever way they wanted or needed.

Later, during that same workshop, I did a role-playing exercise in which a few people pretended to be the customer and various users, while others asked questions and documented how they wanted the process to work on a big flowchart. I had brought name tags so we could label the role players.

Lectures

Each hands-on exercise shouldn’t last more than about an hour. Give people a break to sit down and help them to re-orient themselves, so they are ready for the next step.

Try not to jump around too much, but find a way to talk about something that naturally fits. The worst case is talking about the principle behind what you are doing—for example, explaining how information architecture is not data architecture.

More Exercises

Then, do more exercises. Organize the exercises so people occasionally have to stand up, even if it’s just to put their Post-it notes on the wall. This helps.

Here’s a list of things I typically try to address:

• audience—Define the user base. Ideally, you can use the participants’ knowledge to create what Kelly Goto calls presumptive personas.
• content—List everything you want display to the user, regardless of how you display it.
• functionality—List everything the user can actually do, with no consideration of how it really works.
• information architecture—Tie all of the content and functionality together structurally.
• user flow—Start working out how tasks flow from one to the next. Functions often beget information, but make sure to define how.
• contexts—Back to the audience. If you haven’t already addressed this, talk about how people work, where they are working, and start looking at what that would mean to the user flow.
• endpoints—Only now should you address the best way of delivering the content and functionality. Is it a Web site, an app, an SMS? Often, it’s many things, and all you identify here is what best fits the content, functionality, flow, and context.

Have each exercise build on the group’s previous work, so it all flows together, and they see the work they’re doing making a difference right away.

Wrap Up, Re-introduce

Even speedy workshops cannot be done in a day. Two days is typical for me, but that still means a big break. So, at the end of day one, be sure to wrap up what has happened and outline what you expect the next time.

Your preparation continues. Use the afternoon or evening to review the information you’ve gathered, and prepare for the next day. Your deck will need revisions based on the work the group has done, and you may change your mind about what exercises to do the next day. One of the key things is to create the first slides for the next day. Review what you’ve done—both to re-orient everyone and to reassure them that they’ve done good work.

Document

Often, a group will create items that are not portable. You must record whiteboard scribbles and Post-it exercises. Try to book the room for the entire day, but do not trust that everything will be the same when you come back the next morning. If you don’t have a note-taker, make sure you take photos at the end of each exercise to preserve the information.

Distribute

A workshop is not an end unto itself. While you’ll usually capture your best results in actual design documents, it is important to share the results sooner than that.

Summarize how the workshop went, what decisions the group made, and what you left on the table. Distribute this summary widely. Provide a copy to anyone who might care about the results—anyone with whom you are allowed to share it. Ideally, you will continue to get feedback, especially from people you didn’t know you should invite and from whom it might be good to get information.

Use Your Time Wisely

The biggest things I argue about with project teams are time and cost. Even when they’ve already engaged a UX team or person, they often want everything immediately. So I point out that things should not always be in such a rush. If there are two weeks between the end of your workshop and the start of the actual project, use that time to do more work. Get out and do some research, design a complete task flow, or build a prototype.

Most importantly, you need to get everyone to understand the value a good user experience can add to a product. On a lot of speedy projects, teams actually do understand that they will fail, so they go with limited launches to reduce their risk. They know that it might be the third release before they can figure out the app, Web site, or service well enough. With a good design process, you can avoid a lot of that muddling through. Just take a few weeks to start things off right, and you can save your team months or years.

Next time, I’ll continue to explore this theme of working at all deliberate speed by discussing the tactics I use for testing concepts reasonably quickly, but very effectively. 

References

Google Ventures. “The Design Sprint.” GV.com. Retrieved August 23, 2016.

Hess, Whitney. “Why I Detest the Term Lean UX.” Pleasure & Pain, February 27, 2011. Retrieved August 23, 2016.

León, Michael. “People Adapt: Talking UX Design with Steven Hoober (3/3).” Nearsoft Design, June 7, 2013. Retrieved August 23, 2016.

Spool, Jared M. “The KJ-Technique: A Group Process for Establishing Priorities.” UIE, May 11, 2004. Retrieved August 23, 2016.