Mobile UX Design Approaches: Workshops

Mobile Matters

Designing for every screen

A column by Steven Hoober
September 8, 2016

Whenever a client or team comes to you for help designing anything specific—such as an app—your first question should be: Why an app? Or: Why whatever else they think they need?

UX design should always start with gathering information, understanding users’ needs, and establishing measurable objectives. Just adding design to someone else’s idea or cleaning up what development has created is not a recipe for success. Our job titles communicate our focus on users. But there’s still much pressure from businesses to go faster, and many believe we can just pull ideas out of our heads or quickly clean up turn-key vendor solutions and create something that’s good enough.

We need to start projects by focusing on the experience and push project teams to question the entire product ecosystem and set aside their assumptions so we can organically discover what we really should build and how. One effective approach to doing this is conducting design workshops.

Champion Advertisement
Continue Reading…


Over the past year or so, I have been excited to see certain flavors of Lean UX and the Google Ventures (GV) Design Sprint bring the concepts of early information gathering and design ideation to the forefront of our conversation again.

However, after attending a couple of sessions on how to run these processes—so I’m sure I’m getting the unsullied truth about them—and having seen their results, I’m disappointed after all. A telling quotation about Design Sprints is right there on the Google Ventures site:

“The sprint gives teams a shortcut to learning without building and launching.”

There’s the Engineering assumption that we know nothing about human nature. That the work we do as UX researchers, architects, and designers is just guessing or opinion. So the pressure always exists to take shortcuts and prioritize speed. Of course, product development teams used to frown upon taking shortcuts and rushing because that increases risk and lowers quality. Whitney Hess has said this better:

Lean UX implies that less UX is being done. That couldn’t be further from the truth, nor is it something we should encourage. And anyway, UX shouldn’t be measured in time spent conducting activities or producing activities; it should be measured in its depth of integration in a company’s philosophy and culture.”

It’s high time that User Experience no longer just tag along with yet another Engineering-driven trend, but take leadership in creating product-design solutions.


In Junior High and High School, I was on the track team. While I am not religious about running, I have run more days than not in the decades since. If you aren’t a runner and saw me passing your house, you might call it jogging. Not too fast, but fast enough for me to get somewhere as fast as I can.

This is really how running works: You run at a reasonable pace for the distance you have to cover. Sprinters go very short distances at a quick pace, then rest. To sustain peak performance, they rest for days between runs at maximum speed. Doing one sprint after another is not a sustainable way of getting anywhere.

In High School, I was one of the few good mid-distance runners, so I had to run the 220-meter hurdles just minutes after running the quarter mile. Going all out on the first race meant I had so little left for the second race that I almost injured myself on the hurdles—and I was embarrassingly far behind the pack at the finish line.

This analogy works fine because fatigue is fatigue. I never dawdle on projects, and most of the UX people I know already work at a breakneck pace, cutting corners because of pressure from clients and bosses. There are few classic user-centered design (UCD) projects that spend months on user research anymore. However, similar to the mostly unfounded gripes about waterfall development processes, traditional UX methods are not intrinsically slow.

UCD processes are well established, and they let us work as fast as we can at a sustainable pace, with occasional sprints for crises, unexpected bugs, natural disasters, wars, or because of poor planning. We know very well how to do all of this, from years of experience, with many people developing methods and proving them out thousands of times. We should not accept unfounded criticism or cast our methods aside for new, unproven ones just on the basis of trends whose focus is perceived speed.


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.


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.


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.


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.


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.


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 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.


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.


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.


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.


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. 


Google Ventures. “The Design Sprint.” 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.

President of 4ourth Mobile

Mission, Kansas, USA

Steven HooberFor his entire 15-year design career, Steven has been documenting design process. He started designing for mobile full time in 2007 when he joined Little Springs Design. Steven’s publications include Designing by Drawing: A Practical Guide to Creating Usable Interactive Design, the O’Reilly book Designing Mobile Interfaces, and an extensive Web site providing mobile design resources to support his book. Steven has led projects on security, account management, content distribution, and communications services for numerous products, in domains ranging from construction supplies to hospital record-keeping. His mobile work has included the design of browsers, ereaders, search, Near Field Communication (NFC), mobile banking, data communications, location services, and operating system overlays. Steven spent eight years with the US mobile operator Sprint and has also worked with AT&T, Qualcomm, Samsung, Skyfire, Bitstream, VivoTech, The Weather Channel, Bank Midwest, IGLTA, Lowe’s, and Hallmark Cards. He runs his own interactive design studio at 4ourth Mobile.  Read More

Other Columns by Steven Hoober

Other Articles on Envisioning

New on UXmatters