As user experience (UX) designers and researchers, the most common complaint we hear from users is:

“Why don’t they think about what I need?”

In fact, many organizations have teams dedicated to delivering what users and customers need. More and more software developers are eager to work with UX designers in order to code interfaces that customers will use and understand. The problem is that complex software projects can easily become bogged down in competing priorities and confusion about what to do next.

The result is poor design that impedes productivity. For example, efficiency in healthcare is hampered by electronic medical records (EMRs). Complaints about these software systems are legion. Dr. Steven Ugent, a Boston-based dermatologist and Yale Medical School alumnus, is no exception.

Since 2010, Dr. Ugent has used two EMR systems: Before 2010, he finished work promptly at 5:15 every day. Since he and his colleagues started using EMRs, he typically works an extra half hour to 1.5 hours in the evening. “I don’t know any doctor who is happy with their medical records system. The crazy thing is that I was much more efficient when I was using pen and paper.”

The EMR systems are clunky, inflexible, and hard to customize. Ugent, for instance, cannot embed photos directly into his chart notes. Instead, he must open the folder with the photo of the mole and then open a different folder to see the text. This setup is particularly cumbersome for dermatologists who rely heavily on photos when treating patients.

Ugent succinctly summarizes the problem with EMRs:

“The people who design it [the EMR system] don’t understand my workflow. If they did, they would design a different system.”

Doctors are not alone in their frustration with clunky software. Consumers and professionals around the world make similar complaints:

“Why can’t I find what I need?”

“Why do they make it so hard?”

“Why do I have to create a login when I simply want to buy this product. I’m giving them money. Isn’t that enough?”

A major contributor to clunky software is flawed design processes. In this article, we’ll outline four design process problems and explain how to address them.

1. Complexity
2. Next-Release Syndrome
3. Insufficient Time For Design Iterations
4. Surrendering Control To Outside Vendors

1. Complexity

Scale, multiple stakeholders, and the need for sophisticated code are among the many factors contributing to the complexity of large software projects.

Sometimes overlooked, however, are complex laws and regulations. For example, insurance is heavily regulated at the state level, adding a layer of complexity for insurance companies operating in multiple states. Banks and credit unions are subject to regulation while utilities must comply with state and federal environmental laws.

Healthcare products and software subject to FDA regulations offer an even greater challenge. The problem isn’t that the regulations are unreasonable. Safety is paramount. The issues are time, budget, and the planning necessary to meet FDA requirements.

As Jeff Horvath, Ph.D., a UX consultant with extensive experience in healthcare, explains: “These requirements add a couple of orders of magnitude to the rigor for writing test protocols, test setup, data gathering, analysis, quality controls, and getting approval to conduct the research in the first place.” For example, a single round of usability testing jumps from six weeks (a reasonable time frame for a standard usability test) to six months. And that’s with a single round of usability testing. Often, two or more rounds of testing are necessary.

This level of rigor is a wakeup call for companies new to working with the FDA. More than once, Horvath has faced tough conversations with clients who were unprepared for the extended timelines and additional budget necessary to meet FDA requirements. It’s hard, but necessary. “It pays to be thorough,” says Horvath. In 2018 the FDA approved a mere 11% of pre-market submissions.

The demands on researchers, designers, and developers are higher for healthcare software requiring FDA compliance than for traditional software products. For example:

• A UX researcher can only conduct one or two usability test sessions per day as opposed to the more common five to six sessions per day for standard software.
• UX designers must remain hyper-attentive to every aspect of the user’s interaction with software. Even one confusing interaction could cause a clinician to make an error that could jeopardize a patient’s health. For the same reason, UI designers must draw interfaces that remain faithful to every interaction.
• A longer time frame for design and usability testing means that the developer’s coding efforts must be planned carefully. Skilled and well-intentioned developers are often eager to modify the code as soon as new information becomes available. While this approach can work in organizations well practiced in rapid iteration, it carries risk when designing and coding complex systems.

Failure to manage complexity can have fatal consequences as happened when Danielle McCray was admitted to Tallahassee Memorial Hospital as she was about to give birth. To ease her discomfort, healthcare workers connected her to a patient-controlled analgesia machine, a programmable infusion pump.

Eight hours later McCray was pronounced dead from a morphine overdose. A major factor in this tragedy was the flawed design of the infusion pump used to administer medication. The pump required 27 programming steps. Failure to address such complexity by designing a more intuitive user interface contributed to unnecessary death.

Solution

The solution is to acknowledge and address complexity This point sounds logical. Yet, as explained above, complicated FDA regulations often surprise company leaders. Denial doesn’t work. Failing to plan means your organization will likely fall into the 89% of pre-market submissions the FDA rejected in 2018.

When conducting usability tests, user experience researchers must take three steps to manage the complexity associated with FDA regulations:

1. The moderator (the person who runs the usability test) must be hyper-attentive. For example, if an MRI scan requires a technician to follow a strict sequence of steps while using the associated software, the moderator must observe carefully to determine if the participant follows the instructions to the letter. If not, the task is rated as a failure meaning that both the interface design and associated documentation will require modification;
2. The moderator must also track close calls. For example, a participant might initially perform the steps out of order, discover the mistake, and recover by following the proper sequence. The FDA considers this a near miss, and the moderator must report it as such;
3. The moderator must also assess the participant’s knowledge. Does she believe that she has followed the proper sequence? Is this belief accurate?

2. Next-Release Syndrome

One factor in the failure to acknowledge complexity is a fix-it-later mindset we call next-release syndrome. Software bugs are not a problem because “we’ll fix that in the next release.” The emphasis on speed over quality and safety makes it all too easy to postpone solving the hard problems.

Anyone involved in product design and development must tackle next-release syndrome. Two examples make the point:

• We discovered serious design flaws with a client’s healthcare tracking software. The company chose to release the software without addressing these problems. Not surprisingly, customers were unhappy.
• We conducted usability tests for a large credit union based in the U.S. The participants were seasoned financial advisers. Testing revealed serious design flaws including confusing status icons, buttons with an unclear purpose, and a nearly hidden link that prevented participants from displaying important data. Remember, if the user doesn’t see it, it’s not there. When we reported the findings, the response was: “We’ll fix that in the next release.” As expected, the web application was not well received. Responses from users included: “Why did you ask us to review the app if you had no intention of making changes?”

Solution: Reject The Fix-It-Next-Time Mentality

The solution is to address serious design problems now. Sounds straightforward. But, how do you convince decision-makers to change the entrenched “fix-it-later” mindset?

The key is to shift the conversation about achievement away from product delivery toward the value created. For example, teams that take the time to revise a design based on user research are likely to see better customer reactions and, over time, increased customer loyalty.

Strengthen the case by using quantitative data to show decision-makers the direct connection between user research and increased revenue and a positive customer experience.

Re-defining value is, in effect, a process improvement because it establishes a new set of priorities that better serve customers and your company’s long-term interests. As McKinsey reports in The Business Value of Design: “Top-quartile companies embrace the full user experience; they break down internal barriers among physical, digital, and service design.”

3. Insufficient Time For Design Iterations

Related to the next-release syndrome is insufficient time to iterate the design based on research findings or changing business requirements. “We don’t have time for that,” is the common refrain from developers and product owners. Designers working in Agile environments are frequently pressured to avoid “holding up” the development team.

Development speeds along, and the software is released. We’ve all seen the results from confusing phone apps, to clunky medical records software, to the cumbersome user interface for financial advisers referenced above.

Solution: Design Spikes

One solution comes from the coding world. In his article “Fitting Big-Picture UX Into Agile Development”, Damon Dimmick offers the idea of design spikes, “bubbles of time that allow designers to focus on complex UX issues.” They fit into the Scrum framework by temporarily taking the place of a regular sprint.

Design spikes offer several advantages:

• They allow UX teams to focus on holistic issues and avoid getting bogged down in granular design issues that are sometimes emphasized within a single sprint;
• They offer the opportunity to explore complex UX questions from a high level. If needed, the UX design team can also engage in design-centric thinking at any point in order to solve larger UX challenges;
• By adopting design spikes, UX teams can leverage the same flexibility that development teams use in the agile process and devote the time needed to focus on design issues that don’t always fit well into a standard scrum sprint;
• Development unlikely to be affected by design decisions can proceed.

Naturally, design iterations often affect certain parts of the code for a site, app, or software product. For this reason, during design spikes any code that will likely be affected by the design spike cannot move forward. But, as Dimmick clearly states, this “delay” will likely save time by avoiding re-work. It simply does not make sense to write code now and then re-write it a few weeks later after the team has agreed on a revised design. In short, postponing some coding actually saves time and budget.

4. Relying Too Heavily On Vendors

Addressing complexity, resisting next-release syndrome, and allowing time for iteration are essential to an effective design process. For many firms, another consideration is their relationship with software vendors. These vendors play an important, even critical, role in development. Yet, granting them too much leverage makes it difficult to control your own product.

Certainly, we should treat colleagues and vendors with respect and make reasonable requests. That doesn’t mean, however, that it’s necessary to surrender all leverage as happened during my tenure at a large finance firm.

While working at this firm as a UX designer, I frequently encountered this dynamic:

Manager: “Hey, Eric can you evaluate this claims software that we’re planning to buy? We just want to make sure it works as intended.”

Me: “Sure, I’ll send you my preliminary findings by the end of the week.”

Manager: “Great”

The following week:

Manager: “Thanks for the review. I see that you found three serious issues: Hard to find the number for an existing claim, screens with too much text that are hard to read, and the difficulty of returning to a previous screen when processing a new claim. That is concerning. Do you think those issues will hinder productivity?”

Me: “Yes, I think these issues will increase stress and processing time in the Claims Center. I’m quite concerned because my previous work with Janet’s team demonstrated that the Claims Center reps are already highly stressed.”

Manager: “Really good to know. I just sent the check. I’ll ask the vendor to fix the problems before they ship.”

Me (screaming inside): “Noooooooooooooo!”

This well-intentioned manager did precisely the wrong thing. He asked for changes after sending the check. No surprise that the vendor never made the requested changes. Why would they? They had their money.

Not only did this scenario play out repeatedly at that company, but I’ve witnessed it throughout my UX career.

Solution

The solution is clear. If the vendor product does not meet customer and business needs, and the changes you request are within scope, don’t pay until the vendor makes the changes. It really is that simple.

Conclusion

In this piece, we’ve identified four common barriers to quality design and corresponding solutions:

1. Complex regulations and standards
   The solution is to acknowledge and address complexity by devising realistic timelines and sufficient budget for research and iterative design.
2. Shipping software with bugs with a promise to fix them later
   The solution is to avoid next-release syndrome and address serious problems now. Persuade decision-makers by re-defining the meaning of value within your organization.
3. Insufficient time for design iterations
   The solution is to include design spikes in the agile development process. These bubbles of time temporarily take the place of a sprint and allow designers to focus on complex UX issues.
4. Relying too heavily on vendors
   The solution is to retain leverage by withholding final payment until the vendor makes requested changes as long as these changes are within the original project scope.

The fourth solution is straightforward. While the first three are not easy, they are concrete because they can be applied directly to existing design processes. Their implementation does not require a massive reorganization or millions of dollars. It simply requires commitment to delivering a better experience.