LTUX: From Fire Fighter to Fire Starter

Last night, I had the amazing opportunity to speak at the San Francisco chapter of Ladies that UX. The audience was engaged and asked tough questions, so I think maybe I did a decent job 😉

Download the presentation PDF.

My talk was centered on a client project at EchoUser. The financial software company engaged us to increase the impact of the UX team. Originally, we planned to do that through doing on-the-ground work and modeling good UX process for the rest of the organization. What we learned instead was that this complex organism needed a overhaul of their collaboration, process and relationships to stakeholders.

I fundamentally believe that the way to make impact through design is to utilize empathy to understand the “real” picture of your organization, followed by collaboration that rallies teams together around the existing opportunities and where they want to go. These two forces create an energy and magic that creates a flame of new ways of working.

The audience laughed at my jokes, groaned when I talked about the stuff we all hate, and nodded when what I said resonated. They also had some questions about finding advocates (A: be empathetic, be human, be dedicated), ways to keep the work going (A: artifacts and making them public) and how to carry the torch internally (A: you’ve have trust that a consultant has to earn, so leverage that).

I feel great this day after because I genuinely enjoyed my time with this group of ladies (and men!). A friend texted me on her ride home last night and said, “You made me remember why I’m in design/research again 😊 ”

To that, I say, mission accomplished!

5 Tips for Planning a Great Design Sprint Workshop

I got into design because I love tackling design problems. But, working on my own isn’t nearly as fun as working with others. At EchoUser, my colleagues and I commonly lead workshops with clients to supercharge the design process and bring teams together. It’s a great way to kick-off design work, learn new design techniques and engage in research findings.

In this post, I’m sharing some of EchoUser’s favorite tips for preparing for a design workshop. Behind every tip, there’s a story of an EchoUser learning it the hard way. ;)

Presenting a service blueprint in preparation for brainstorming activities

Presenting a service blueprint in preparation for brainstorming activities

Tip 1: Set the right expectations

One of the greatest values of the workshop format is that it gives people a chance to try out new ways of thinking and doing. As valuable as design workshops and sprints are, the ideas that result aren’t final, fully-fleshed out solutions. Instead they serve as instigators for future work and exploration; it’s important to communicate that during the planning phase and workshop day. Be explicit about what the group is doing and what they’re going to get out of it.

Joanne Wong, senior experience designer, summarized this best when she said, “The process is as important (or actually more important) than the solution. I found that a lot of people were really focused on the solution. We always had to reel them back in to understand that the discovery phase and the problem space is really important.”

It’s also important that each person or group knows why they are involved — they will be more engaged because they know they are needed. Ideally, leadership is involved as participants who can lead by example but also work with their teammates as peers. I’ve heard of situations where a leader from one company kept walking in and out from the workshop, which may have affected the group dynamic.

Snippet of a workshop schedule.

Snippet of a workshop schedule.

Tip 2: Build a detailed schedule (and checklist!)

I know how challenging it is to get on everyone’s calendars. So you want to get the most out of the time you have. In the same way that a design project is done when the final deadline approaches, a workshop ends when the time slot is over.

Be sure to discuss the goals and output of the workshop with clients and moderators to determine which activities best fit the goals and time you have.

My colleagues and I like to plan schedules at 5-minute increments and include everything: introductions, activities and breaks. It helps us know if we’re on track to finish all we hoped to accomplish. Focus on how long activities will take and use timers; otherwise, “it’s very tempting to give people more time,” says Laura Chang, director of EchoUser East.

Along with managing the schedule, make sure to prepare a checklist with materials, space and food. You don’t want to forget markers or extra sketching paper! It’s a small detail, but checklists help you make sure you don’t forget to ask about details like dietary needs before ordering lunch.

Tip 3: Prioritize your schedule, and choose the first things to go

Detailed schedules are great, in theory. But, I’ve learned that no matter what, I have to plan for an seemingly inevitable reality of a late start or change of plans. Maybe a key participant is leaving early to catch a flight, or a conversation gets completely derailed and goes on twice as long.

Plan in advance for what activities can be adjusted, shortened or removed. That way, when (not if) you have to adapt the session, you already have a game plan and don’t have to think that much the day of. It’s like designing a product, you shoot for the ideal but have to make trade-offs to get to release.

“We’ve definitely fallen off of the schedule many times; one workshop was an hour behind on the first day. However, the detailed schedule allowed for us to see what we should cut out and allowed us to shuffle things around,” says Joanne Wong, senior experience designer.

Tip 4: Don’t moderate alone

Even if you’ve got an exact schedule and you’ve done your best to streamline the day, don’t think you can do it alone. Throughout the workshop, you need to be documenting activities with photos, capturing notes and guiding teams through unfamiliar activities, all while keeping an eye on the time and gauging the mood of the room. That’s a lot of work for 1 person.

Since EchoUser workshops often have full group and small group activities, we like to plan for a moderator for every small team of 3–6 participants, with potentially a lead moderator who manages the whole room. During large group activities, moderators serve as presenters, photographers and note-takers. When the small groups take over, the moderators mentor teams in creating artifacts and helping them when they get stuck.

I’ve also found it really valuable at the end of the workshop to have multiple people for debriefing to understand better what was happening in the room.

Prototyping a workshop game.

Prototyping a workshop game.

Tip 5: Rehearse everything

With every workshop, I try out new methods and agendas tailored the tasks or client. I like to rehearse the format once I have a pretty solid schedule. There’s two ways we’ve done it here at EchoUser: 1) prototype and test activities either as small practice runs, or 2) run a brief, sped-up version of the entire workshop.

With a new activity, I like to prototype it with some colleagues to test out the timing, instructions and solicit general feedback. As a result, I can decide whether it makes sense in the agenda, needs better focus on workshop goals or needs to be streamlined.

I’ve also worked with colleagues who have run full workshop dry runs. Working through the agenda at a speedy pace, moderators critique the flow or timing. This also is a good time to practice presentations to make sure they fit in the time you’ve allotted for them, or to adjust your agenda to fit your presentation length.

Planning workshops gets easier as you have more formats and practice under your belt. Next time, I’ll share 5 more tips on executing a great design workshop on the day of.

Why go lo-fi?

When I first started out as a graphic designer, I used a notebook to take notes, make small sketches and conduct calculations. I organized my thoughts before diving into Adobe’s Creative Suite to begin finding the right type or page arrangements.

Those rough sketches were always intended to get myself organized and resembled annotated diagrams more than artful layouts or page spreads. I’m sure to anyone else, those sketches would have looked like half-baked ideas or ramblings of a design nerd with no drawing skills (which is half true); but for me, it was an important step in preparing for detailed design work.

I never included those types of sketches in my portfolio; your work was always meant to be presented as the final, production-ready product. I tried to figure out how to include them, but the sketches just didn’t seem beautiful enough to share with anyone. And, unfortunately, messy design isn’t what gets you hired.

In those times, I’d usually get feedback after combing through our stock photography catalog, fiddling with the page elements and finding the right color palette. It took a lot of time to get the details far enough along for my creative director to provide feedback.

I once had a boss who had a hard time reviewing in-progress comps. She’d always managed to focus on the parts that I hadn’t yet fully figured out and tell me that they weren’t quite working. It was frustrating because I felt like it was a bad thing to be “still working on it”.

I would have to go back to the drawing board and redesign something because critique did not go well. I felt like I was wasting tons of time trying to read her mind, and I was junior enough to not know how to solicit what she was looking for. I’m sure, dear reader, you’ve felt caught in an cycle of guess-try-repeat like this before.

Making it pretty (fast)

After a reprieve from pretty-making during a mind-expanding and process-altering grad school experience (stories for another time), I now find myself in the SF UX/tech industry dealing with similar challenges again.

I’m not sure if it’s an SF thing (the “anyone can make an beautiful app in a weekend and get rich” mentality) or if it’s just the UX industry as a whole, but I’m shocked by the intense focus on making that pretty thing as fast as possible.

Prototyping in InVision

Prototyping in InVision

From a design standpoint, this might be fueled by an arsenal of apps for creating production-level looking designs: InvisionFramerPrincipleHypeMarvelProto.ioUXPinAxure. Or, it could be the influence of flat design and the talk about design as the great differentiator.

When I transitioned from designing for beauty to designing for people in graduate school, I came into the habit of whiteboard sketching, using post-its for more than notes, making paper models and acting out scenarios with my teammates. I learned from my teammates and adapted designs on the fly. We created artifacts that had nothing to do with the final design solutions, but were always strengthening our concepts as the process moved forward.

Even in my own recent projects, I’ve been struck by a focus on high-fidelity renderings early in the design process. First-cut concepts are rendered in a shiny (and animated) glory that makes it very difficult to tell it’s an early idea.

I personally struggle to provide my teammates the critique that they need in these situations because I don’t know what we’re trying to solve. Do you want typography tips or do you want me to make sense of the user value? And, if you want me to critique everything, it’s a heck of a lot easier to focus on the easy stuff (like “fix this type weight”) than to tell you, “I’m not sure I believe your product.”

There’s not necessarily data to prove this point, but I definitely have my own hesitancy towards telling a fellow designer to start all over. Maybe I’m too nice, but I’m also aware of the work that can go into getting a design to that fidelity level (whether or not they have one of these easy-to-use tools).

Why it’s worth making ugly things

“Fancy” prototyping tools afford us the ability to design in high-fidelity (slick transitions and all) quickly and early on in the project, but what’s our goal in working that way?

Some designers prefer the computer and I respect that. But design is consumed in more places than a computer (and always has been), requiring complex interactions and scenarios; it seems like we delaying the learning process to make something that looks cleaner.

A physical prototype for a fitness tracker

A physical prototype for a fitness tracker

Stacks of post-its stuck on a cellphone can be tested in real time in the real world. And, if you suddenly realize you need a new screen or a design or user wants to see it done a different way, it’s just takes a few minutes with a pen to bring that new screen to life. If you’re using a pencil, just turn that puppy upside-down and put that eraser to work (though I’m personally a fan of not losing anything, but just adding new layers to see the progression). If you had to do that same work in InVision or Sketch, it will take more time and effort to respond to your users. It’s far more valuable to spend those resources iterating cheaply early on, so when you get on the computer, you have far fewer version to work from.

Whiteboard sketches for a client website homepage

Whiteboard sketches for a client website homepage

I’ve seen designers (myself included!) make detailed sketches on whiteboards, but then deem them not worthy enough to share with users or clients.

  • Are they concerned that without a .sketch file there was no design done?
  • Do they only know how to communicate design using high-fidelity tools?
  • Is it because our clients don’t trust us and need to see something clearly beyond their personal skills to justify paying that designer at all?
  • Is it because design is more about making artifacts than thinking?

These are just hypothesis, but I hear it in client’s undertones and in the anxiety of late-working designers. And, I’m sure I’m missing something too.

I find that pretty disappointing. If we can educate our clients better and present the “dirty artifacts” well, can we take this part of the process out of the shadows and pixels, into the real world?

Fidelity, so what?

Since the UX field is famous for using competing definitions, I’ll be as clear as I can here. Fidelity is the volume and granularity of detail in design elements. So, low-fidelity designs are “rough cuts” of ideas that tend to be executed in analog materials; they often contain little of the actual content, but instead contain placeholders. High-fidelity designs tend to be chock full of content and have clear structure and components which are often executed digitally and sometimes (though I see it more and more) with visual design such as colors, typefaces and artwork.

And, thanks to the new high-fidelity world where everything seems to be rendered in high-fidelity, we have a tendency to describe our artifacts with phrases like sketches and prototypes, using them interchangeably. In a classic sense, sketches and prototypes are different beasts and tend to be used differently in phases of a project. Sketches happen at the beginning and prototypes reflect a sophisticated design or test of optimization (A or B).

Framework courtesy of Bill Buxton, Sketching User Experiences

Framework courtesy of Bill Buxton, Sketching User Experiences

But, I’d argue the crux to it all is the goal of the artifact — not if it’s a sketch or a prototype. The volume of detail is dependent on what you need to learn and this is where I would disagree with Bill Buxton (and the federal government) in their assertion that “Low-fidelity prototypes are often paper-based and do not allow user interactions.”

It’s very possible to test user interaction in low-fidelity as long as you’re clear about what you’re trying to learn. With a few bits of paper and markers, a small group could create the user experience of a genetics-based dating app (which one group did at EchoUser during a bi-yearly offsite). You could determine if the idea would resonate with users, if the process too long, what the phases to the service are, what channels work best, how many elements would need to be developed, and even how you’ll make money.

Prototyping at EchoUser — just an idea, bit of empathy and mediocre acting :)

Prototyping at EchoUser — just an idea, bit of empathy and mediocre acting :)

Low-fidelity designs really shine when you share what you’re working on — not from working by yourself and going through the motions of making artifacts. Without socializing the ideas, you end up making a lot of assumptions and you might discover yourself debating between the inclusion of the Facebook social graph or whether you ask for friends’ email addresses before you’ve even determined whether a user’s friends would give a crap.

By starting at a low-fidelity, you also make the process more accessible and encourage your teammates and users to co-create with you in a way that helps you learn even more. Co-creation is a powerful concept that embraces everyone’s ability to feel empathy and be planful in what we make. Especially when you work with experts, even if that expertise is in being a mom who regularly juggles the demands of two young children, they need a space to give their voice.

If you only ever show something in high-fidelity, it becomes harder for users to find themselves in a finished-looking idea. The only question they’ll focus on is: do I love it or hate it? Users won’t necessarily see it as something they can mold into what they need or want; when there’s already enough choices in the market, users just walk away from the choices they don’t get or like.

If the user is given the space — and the chance — to talk about what they need, the designer can learn so much earlier in the design process about how the product fits into user’s lives. While co-creation does require analysis by the designer, it can have a huge impact in fundamental decisions that are easier to make at the beginning of a project. It’s ultimately up to the designer to decide how to use this information moving forward.

Designers will always need to end up in high-fidelity (depending on the scope) in order to really bring an idea to life. But, I’d argue that we’re mistreating a critical part of our own design journey as a designer by treating low-fidelity work like a dirty, little secret. If you haven’t tried these types of low-fidelity sketches and prototypes, you could be missing important reality checks needed for your idea to succeed. And, if you use these methods but don’t share them, your clients will continue to misunderstand your process and your users won’t be given the space to help you get to the right solution sooner.

911 in the Age of Sexy Services

We’re in an age of sexy services: Instagram makes photos sexy, Uber/Lyft make getting a cab sexy, Trunk Club makes your man look sexier (😉).

911 emergency service calls aren’t sexy — they are terrifying. It’s a background system that doesn’t really come to our conscious minds until we are faced with a crisis. And, when we do interact with it, we’re faced with life or death.

A few days ago, I heard a rerun of the Dianne Rehm’s show, “Why The Country’s 911 Emergency Call System Needs An Upgrade.” Unfortunately, I wasn’t surprised to hear how such a complex system was being neglected.

As a service designer working in the tech industry, I’m always trying to help clients and my colleagues to understand how user experience (UX) represents not just end users, but the entire system.

911 is more than a telephone number, it’s a system of people and technology that work together during emergencies to direct resources and expertise where it’s needed. The service can’t help you until 911 knows you need help, but it has to respond at a moment’s notice.

Old Systems vs. New(er) User Behavior

Panelists on the show revealed that the call routing and ID system has failed to keep up with modern consumer technologies; the system is so far behind the times that it means big costs and infrastructure changes to upgrade.

As consumers moved to mobile phones (70% of 911 call volume now comes from mobile phones), the ability to pinpoint a caller’s location became more difficult for operators working on equipment designed for landlines. On top of that, the caller is in a stressful situation and may not know where they are; so it’s not as simple as asking someone, “Where is your emergency?”

Call centers need upgrades to handle information like GPS, texts, photos and videos that give operators information they need to diagnose the situation. Even the switches that determine where calls get routed before being answered need to be upgraded, and companies like Verizon have no interest in footing the costs (according to the show’s panelists).

The Other Problems Impacting 911

This might seem like a simple fix: upgrade the call centers and equipment. On the show, it took until nearly the end of the episode to reveal that there’s more than one crack in the system.

  • The governance and funding for 911 services are almost 50 years old — as old as the equipment sitting in some call centers. The panelists, in particular, are seeking law changes and fund allocations to support upgrade costs.
  • Shifting to internet-based protocols (the future of all communication systems) will require new methods — like batteries, generators or some new invention — to keep the power on during prolonged emergencies.
  • Tracking and reporting apps, while well intentioned, aren’t meeting standards needed by authorities yet. They serve as complements to the overall system, but the system needs to learn from the best apps out there (of which there are few).
  • With Verizon no longer claiming responsibility for upgrading current technology, there’s a need to initiate new public-private partnerships that upgrade and deliver the technology. Municipalities shouldn’t be in the business of managing internet networks, but who will?
  • All of this hinges on the fact that there’s responders to step into action for calls. And, there’s a shortage of first responders already.

Bringing Sexy Back to 911

911 can be a sexy service, but maybe not how you might expect through innuendo-laden ads or interfaces for drooling Apple fans.

A great service just works — seeming to by magic make the right things happens. Enhanced 911 offers some magic, but next generation 911 requires so much more than that:

How might we fund emergency services so they can continually improve and are universally accessible?

How might we design the technology infrastructure so we can upgrade and change over time?

How might we get responders to the scene faster and more efficiently, optimizing their limited time and resources?

This is a complex problem, so it would be unfair for me to propose solutions so quickly. By knowing the right questions to ask and considering the whole system, we can create long-term strategies that help companies decide on the right short-term experiments/tactics. Sticking on band-aids won’t solve the problem if the rest of the system is a mess.

Because, let’s face it, band-aids definitely aren’t sexy.