Sitting where we do within a consulting organization for a software vendor, my team and I often feel like mediators between two warring factions. On one side, we have Design and, on the other side, user’s actual usage of an application. Sometimes, both meld fantastically well. In such cases, the design is almost always well thought out, slick, and crafty. At other times, though, a design is found wanting in actual usage, especially at the higher end of the scale. It is at such times that, although a design seems great, all parties agreed to it, and we put it through rigorous testing, there are still significant user-adoption issues after the design gets implemented. How does this happen, and how can we address this problem?
During this golden age of design that we are experiencing, it is becoming increasingly important to address such situations. Even though the profession of User Experience is rapidly maturing, many executive sponsors of our efforts still look at User Experience as some sort of magic pixie dust. UX experts come in, sprinkle it about, and all is well. This mentality does not leave a lot of room for UX folks to fail to hit the mark the first time out. Such expectations may be unfair, but more and more, this is becoming the reality. Design, especially Web page design, is now becoming a commodity. Business leaders understand that User Experience is critical, but there is also a growing sense that what we do is totally repeatable.
Champion Advertisement
Continue Reading…
The challenging opportunity that UX professionals face is to be able to step up and provide real leadership—helping a business group to understand how to take their requirements and transform them not just into an elegant design, but a design that accommodates the way people actually work.
Issue 1: Requirements-Based Products
I meet with a lot of unhappy business people—good, well-meaning people who desperately want to improve the lives of users. They have lofty goals to change everything for the better, but often spend a ton of time and money on the wrong thing. Of course, where businesses go wrong is in defining all of the requirements, then handing them to developers, expecting them to create the most fantastic user interface and user experience imaginable.
The issue is, of course, that developers are not designers. They don’t usually have the right eye or the empathy to realize that requirements do not translate well into a successful user experience. Nor do they recognize that careful consideration of design is necessary to create a successful user experience. On some projects, the relationship between IT (Information Technology) and business is strong and harmonious. Unfortunately, making this the norm requires a lot of work, and most of the time—just as Design and users can seem like warring factions—it feels like IT and business are two players in a particularly acrimonious divorce. And just as in a nasty divorce, there is a lack of communication, empathy, and an almost inhuman lack of understanding of one another.
It does not have to be this way. In the modern era of User Experience and technology, we can change a design rapidly—more so than ever before. With a greater recognition of the importance of design, UX professionals often get drawn into projects earlier, allowing them to have true leadership impact. The ways in which users actually need to perform tasks are the main drivers, so requirements that have no basis in reality no longer drive design and development.
Issue 2: The Fragility of Design
In my experience, design is extremely fragile. Its fragility stems from its reliance on context for its viability. For all the templating of designs these days, the basic concept that context should dictate the appropriateness of a design construct still prevails. Yet we expect a design to exhibit rather strong characteristics: We want designs to be adaptable; responsive to the slightest whisper of user discontent. We also want designs to stand the test of time. It is not rare for me to hear from customers, “We want a design that will last us five years.” My reply is always, “No, you do not.” What customers really need is a long-range experience strategy that is inherently adaptable. The designs that we come up with should always support the overall strategy.
Too often, the designers who create a design expect users to bend to their will—to somehow get it. Even great designers sometimes suffer from having this expectation, which translates into rigidity in design that actually contributes to its fragility.
When you combine a requirements-driven design paradigm with a fragile design ecosystem, you get a user-interface design that neither meets the needs of users nor has the requisite adaptability. Plus, the development process lacks the agility to respond to necessary changes. This, unfortunately, describes the state of many enterprise software implementations today.
Frame Requirements as Jobs to Be Done
How can we solve this problem? Most of us know that we need to avoid requirements-based user-interface design. What is less well understood is how to tackle this problem. One possible way of doing so effectively is to start with a better understanding of the actual thing an application, page, or product is trying to enable users to do. A lot of designers—such as Alan Klement and the folks at Intercom—are using or taking inspiration from Clayton Christensen’s Jobs Framework, by framing what was once a user story as something more focused on what triggers an event, situation, or outcome—a job story. This job story focuses on a user’s specific motivation and goal, so seeks to identify the intended outcome. Comparing jobs to be done to a typical user story, it is clear that thinking in terms of jobs is way more effective.
Job Story Example—When I file a claim and need to correct errors, I want to be able to see the entire claim process, so I can easily jump anywhere in the process.
User Story Example—As a claims processor, I want the ability to correct errors, so that I can submit a claim.
By rephrasing requirements as jobs to be done, highlighting users’ motivations, we give the design and development teams a lot more visibility into what users actually need. In contrast, with requirements-based design, we end up throwing a lot of data elements on the screen or designing interactions that don’t speak to users’ overall motivations and goals.
By framing requirements in this fashion, you can also eliminate the fragility of design. Knowing users’ motivations and goals up front greatly increases your chances of getting a design mostly right on the first iteration. Because you start with a stronger basis for your design, you can make incremental changes to satisfy real user needs rather than making sweeping changes—as you may need to do when designing from requirements. You’ll also get much closer to matching actual usage patterns, which strengthens your overall design.
Remember, the key goal is to make your designs accommodate actual usage. Make sure that you’re adaptable and flexible in addressing users’ motivations and goals. When you do this, you will achieve a much better success rate and deliver high-quality user experiences.
Clayton Christensen Institute for Disruptive Innovation. “Jobs to Be Done.” Clayton Christensen Institute for Disruptive Innovation, undated. Retrieved July 4, 2015
Correction: The title of the Alan Klement blog article should be: “Replacing the User Story with the Job Story.” You can also find an updated version of the article on Medium.
At Pegasystems, Baruch helps global clients develop new ways of streamlining their operations, improving their customer experience, and creating real transformations—digital or otherwise. Previously, during his 12 years at Pegasystems, Baruch led their global User Experience team and served as the principal end-user advocate for the Pegasystems Services organization in their delivery of user-interface design and user experience to customers and partners. He has led and participated in successful efforts to improve user experience across various industries. Baruch earned his Bachelor of Arts in Professional and Technical Writing and Philosophy at the University of Hartford and his Master’s of Science in Human Factors in Information Design from Bentley University’s McCallum Graduate School of Business. Read More
