Failures

☀️ Epic 2017 Brightnessgate

What Happened?

After holistically updating the UI of a sprawling, decades-old piece of enterprise software—changing screens that were commonly muted and skeuomorphic to more modern bright minimalism—we recieved a wave of strong feedback from many of our users complaining that the screens were now too bright and were causing reactions ranging from slight annoyance to chronic headaches.

How We Responded

The design team scrambled to learn more about what was causing these issues and how we could act quickly to mitigate it, getting on calls with users and flying out to see their concerns in person. We identified several factors:

• As part of our design system implementation, we had removed some system themes that couldn't elegantly use the core controls and didn't achieve WCAG AA accessibility standards. We realized later that many users with light sensitivity were relying on those themes. We quickly designed replacement themes with lower contrast that worked with our design system (and were exempted from our A11y guidelines).
• The computer monitors used in many healthcare settings are often cheap and old, and users try to mitigate their issues by cranking up their native contrast settings. This resulted in the appearance of light shades being effectively white. We made modifications to the colors we used to deliberately darken some shades that looked fine on our own monitors.
• The previous two issues are more impactful in darkened contexts like hospital rooms at night or ophthalmic exam rooms. We identified screens commonly used in these contexts and made changes to darken them as much as possible.
• Some users honestly just disliked the colors we chose for the new styles. As we iterated on the design system, we created strategies for making it more flexible and customizable in the future so everyone could adjust the look and feel of the system to best suit their tastes.
• We created documentation, tipsheets, and webinars to disseminate information about the changes to customer staff and went on trips to talk directly to some of our most concerned customers.

What I Learned

• Change management, even when it seemingly only concerns aesthetics, is huge. When your user base lives in your software 40+ hours a week, they have strong feelings about every aspect of it. Make them aware before change comes and sell the benefits of the changes to them beforehand.
• When validating design choices, context is king. Simulating the exact circumstances of software's use, down to room lighting and equipment, can help predict a lot of issues before they happen.
• Beware of redesign for the sake of redesign. On high-stakes software, you'll need to be ready to explain the reasoning behind every choice you make.
• Don't try to tell angry users that you understand. You can't truly feel what they're feeling, especially when it comes to professional software. When receiving feedback, sympathize but don't convince them that you truly empathize. They'll know when it's not genuine.
• Disempowered users will suffer in silence while the ones with more social capital will raise a stink. Don't forget about the people who aren't complaining.
• Change hurts...but people get over it. While these changes caused an immediate uproar, most users got used to it within two weeks.

⬆️ Back to Top

♟️ Epic Strategic Design Initiative (2018)

What Happened?

Over the course of my career at Epic, the UX team went from being largely focused on execution of UI changes to being much more ingrained in product design and decision-making. About half-way along this process, I and a few of my peers had finally carved out enough autonomy to create projects of our own rather than just those that were assigned to us. I started an initiative to use research to determine what changes would actually have the biggest impact on our users' happiness, rather than just the features that were requested explicitly. I assembled a cross-functional team including UXDs, QA, implementation, and tech support staff. Each of us picked a research question we were curious about and began interviewing SMEs to understand the answers better. Every two weeks, we met to share our findings and discuss next steps.

Eventually, we determined that a big dissatisfier and frustrator for users was the backlogs of unresolved issues for internal tech support. Users would submit what they considered to be simple tickets and not see them resolved for months, if ever. One reason behind this was that communicating the context of an issue, its specific details, and the desired outcome was next to impossible using customers' existing issue ticketing systems. We proposed building a better system directly integrated with our software that would make ticket creation easier, while also including all the necessary contextual data for tech support.

Unfortunately, that project never got off the ground because we couldn't gather support from the stakeholders needed to actually allot time and resources to it. The initiative languished and eventually died.

What I Learned

• Every skunkworks or innovation lab-type project needs a champion from company leadership who understands the value and is willing to fight for it to their peers
• Get buy-in from leadership early and often. Remind them who you are, what you're doing, and why it's important.
• Every design project is inherently political. You can't make change happen purely on its own merits, you need to be willing to do the legwork and gladhanding to win people over.
• New perspectives are valuable, but equally valuable are people who have institutional and historical knowledge
• Volunteers will slowly disengage from projects if they aren't given clear tasks with hard, well-enforced deadlines