StrategyFixing A Broken User Experience

Advertisement

Unless you’re developing completely new products at a startup, you likely work in an organization that has accumulated years of legacy design and development in its products. Even if the product you’re working on is brand spanking new, your organization will eventually need to figure out how to unify the whole product experience, either by bringing the old products up to par with the new or by bringing your new efforts in line with existing ones. A fragmented product portfolio sometimes leads to an overall broken user experience.

Understanding an organization and its users and designing the right interaction and visual system take exceptional effort. You also need to communicate that system to teams that have already produced work that doesn’t align with it. This isn’t easy work. In this article, we’ll introduce you to a strategy for fixing the broken experience that starts with surface improvements, goes progressively deeper into structural issues and ends with a big organizational shift.

The Hierarchy Of Effort

Many large successful companies end up in a situation where they must maintain dozens, if not hundreds, of applications in their product portfolios. These huge suites are the result of mergers, acquisitions, different sets of user needs, legacy services and contracts, and the inefficiencies that naturally develop in huge organizations. Sometimes the reasons for so many different product lines are legitimate; other times, the wide set of offerings doesn’t serve anyone’s needs particularly well. Users will often struggle to learn a suite of related products because of major differences in how they look and operate.

The initiatives to fix these broken experiences are referred to in ambitious and somewhat generic terms, such as “common look and feel,” “unified online experience” and “unified look and feel.” Regardless of the term, the common elements represent a drive to bring consistency to a large set of products in multiple stages of development and spearheaded by a centralized internal group. There’s a sense of urgency; we often meet with some internal resistance; and frequently we’re charged with fixing a previous agency’s failed attempt to deliver design and guidelines that can be metabolized by the client.

The Hierarchy Of Effort1
The hierarchy of effort to fix a broken user experience

One effective approach begins with surface improvements, goes progressively deeper into structural issues and ends with big strategic organizational shifts. We start with the low-hanging fruit and at each step reach higher to develop products that will ultimately deliver great experiences. It’s worth noting that this approach was developed to make it possible for a team to make incremental improvements to products already under development, but also to look ahead to future releases, when rewriting code or rethinking interactions won’t be so disruptive.

If your organization is working on its first product, then this approach would be totally backward. But in a large organization with a lot of history and many products, this approach will help you articulate both a short-term and long-term strategy for building a product portfolio that delivers a user experience that is learnable and builds confidence and a portfolio that makes your work easier and more effective.

Visual Consistency and Simplification

The lowest amount of effort required is at the bottom of the pyramid, so we suggest starting there. Sure, it’s lipstick on a pig, but simply taking a consistent visual approach will help to bring many different products under a shared brand experience.

Visual Consistency2

Assuming you’ve done the groundwork to articulate the design of an ideal experience, the simplest and arguably easiest way to start implementing it is to reskin the products currently under development. Finding ways to simplify and excise unnecessary information, unifying the information architecture, and adopting standard fonts, colors and controls are all relatively low-effort ways to improve existing products.

This is the foundation. It won’t improve a poorly designed interaction, but it could dramatically increase the appearance of unity to the end user. Products that have a consistent visual language will clearly convey their membership in a single portfolio. The benefit of improving the visual system first is that changing or adjusting the skin of an application is much easier than changing things such as behavior, which will require rethinking and recoding fundamental aspects of the application.

Behavioral Consistency

If your organization has simplified and unified the visual language, the next step is to make the behavior consistent. This is basic stuff: disciplined reuse of patterns instead of applying patterns ad hoc from a grab bag of widgets, and unifying the nomenclature and conceptual frameworks. Hopefully, any individual product will have internally consistent patterns; it’s when you look at sets of applications that were developed by different groups or obtained through acquisitions that you usually see wide discrepancies.

Behavior Consistency3

Assuming that the given design expresses high-level principles and provides a basic set of pattern libraries, the goal at this stage is to evaluate individual products and figure out how much work is required to align them. This work entails at the very least replacing widgets in some applications. It usually also entails a decent amount of coding and testing to ensure that the revisions contribute to a consistent experience. Maintaining a shared approach and understanding will require more coordination between development groups.

Behavioral consistency makes it easier for the end user to learn a tool and then to transfer those skills when picking up related tools. The user has to build only a single mental model of how the applications work. This gives them confidence and enables them to pick up new products without facing a steep learning curve and without being confused about how things are done.

Behavioral Optimization

The prior step was done solely to align the behavior of the various products. A deeper level of work is required to optimize the behavior and to make the applications more powerful and easier to use.

Behavior Optimization4

This step reworks the products even further. It means evaluating the current products against the user’s needs and goals and looking for ways to eliminate work and to simplify the patterns. This assumes some measure of design effort beforehand to identify the areas where this will make the most difference. It assumes a commitment to user-centered product design, some research, as well as personas and scenarios. Without these, you’ve got no way to decide what patterns to simplify, which work to excise, and what user needs to anticipate and solve for.

An optimized experience enables users to perform their tasks with less or more effective work. Any work that’s performed is captured in such a way that users aren’t asked to perform the same task twice. Smart defaults are captured and leveraged to make tasks flow more quickly. Where possible, shift computing work to computers, and judgements to humans. Mine data to see broader patterns and opportunities that allow the system to anticipate and meet needs before they become issues.

This is where you do everything you can to make each application the best it can be. It takes a lot of work, with new interactions introduced and much code rewritten. A considerable investment of time and effort is required.

Unified Experience Strategy

The result of the last iteration is a set of products that do what they do best. The point of this iteration is to rethink how the suite works together. This often means rethinking product strategy.

Unified Experience Strategy5

Designing a unified experience requires looking at the big picture, reevaluating the internal product silos in the organization, and reconsidering the ideal workflow for individuals and between roles. It could lead to collapsing multiple products into one, bridging gaps with new products, eliminating redundancies in capabilities or refocusing the service. This kind of work takes deep organizational commitment and a strong mandate. It takes long-range, instead of short-term, planning. It can’t be done quickly, and doing it well takes organizational honesty and courage.

The real beneficiary of this kind of effort is the end user, because this product strategy is user-centered. The company recognizes that the product exists to help people perform their work and that they might use other tools and services to accomplish their goals. Users don’t exist in isolation; they share work with others. Success isn’t measured by how well they perform a task, but in how competently they traverse a complex and dynamic ecosystem of people, data, devices and services. When a company brings their product line to this stage, both the organization and the product line have been transformed.

UX Culture

All of the prior steps were aimed at fixing a broken user experience. By following them as an iterative path, it becomes possible to greatly improve a severely broken user experience. The way to avoid having to repeat this cycle in a few years is to transform the organization itself. Software and services are conceived and developed in a particular organizational culture, and this has a profound effect on the products. Products coming out of an engineering-oriented organization bear the unmistakable focus on technology; services with a focus on sales deeply communicate this; and products that come out of organizations with a UX bent cannot avoid their focus on a good user experience.

UX Culture6

If you want to repeatedly deliver a great user experience, you need to go deeper than applying design to the surface. Your organization needs to understand and commit to making user experience a core priority. Executives have to support or advocate for the unique perspective that design brings; capable designers have to work for a user-centered approach; and a user-centered way of building things has to be integrated into the organization.

A great user experience almost never just happens. Understanding the user and keeping their needs as your priority throughout the design and development stages take deliberate effort. Products and services are created by teams of people who collaborate to bring an idea to life. The output is ultimately shaped by the agreements about what is important, the methods of performing the work and decisions on how to measure things. A shift in organizational culture takes the most effort and the longest time, but it results in the largest, most pervasive and most coherent shift — not just for the organization and its products, but for those who use them.

Isn’t This All Backwards?

“But wait,” you’re thinking. “Isn’t this all backwards? Shouldn’t you design the whole system around the right workflow, optimize the behavior within it, make sure it’s consistent with other products, and finally make sure it’s visually simple and clear?” Yes. Yes, you should, especially if you’re making a brand new product.

But we see again and again that few large companies really have the ability to clear the table, start with a clean slate and build something utterly new and great. Most start with a line of products that cannot be abandoned. They have applications that are supported by various teams around the world, perhaps owned by different subsidiaries and in various states of compliance. While you can design the ideal experience, you can’t just build it. Moving toward something whose design really delivers will take many iterations. This situation isn’t great, but it’s the reality. When you find yourself here, you can’t boil the ocean. You have to start somewhere. In our experience, starting at the bottom is a very practical way to move forward.

(al) (jc)

↑ Back to topShare on Twitter

  1. 1

    “Products coming out of an engineering-oriented organization bear the unmistakable focus on technology”.

    Unfortunately, the above statement is the reality, where the engineering team steers the product, without having the initial valuable input of usability and the user experience experts.

    Working in this part of the world, where civil engineers also design the building, instead of architects having their valuable part, will definitely put out a faster and less “costy” product on the table. But the disaster happens when the client finds the application very difficult to use. Suddenly, the UX guy is remembered and asked to perform a CPR or even a miracle.

    The maximum level that a UX expert can go to, within a confined time, is Visual Consistency and Simplification.

    This also is a reality to many companies, here in this and other parts of the world.

    27
    • 2

      I would have to second this. Unless there is a organizational mindset within the executives to include a UX representative (UX Director, CCO, whatever the title) the difficulty to get passed the the first phase is dramatically more complicated. Solely because the needed information to give well thought out feedback is received too late in the process and therefore results in poor decisions during development. Poor in the sense of Behavior Consistency and Optimization. Therefore the engineering department is left with making business decisions that weren’t thought of during the planning phase assuming there was one.

      I’ve worked on the dev team as a UX Designer/Front end developer for 2+ years and the same pattern repeatedly happens. I’ve been communicating with our CTO and my development manager for over a year now to create a UX department that would serve as a gate that all projects and product enhancement requests should go through before getting to development. Just last week we decided I should be part of the Product Management team and start the beginnings of a “UX team” that would oversee the usability and consistency of our application. Hopefully it will allow for us to have better planning and get UX more involved higher up in the process and result in a better product as well as steer us away from being an “engineering-oriented organization” and more towards a “User centered organization” where we’ve always got the user in mind along side our business (products).

      3
  2. 3

    This is brilliant.

    I think one of the points that could be added to reinforce the main idea of working “in reverse” is that, as I’ve been finding, when you’re working in a large company and trying to affect change, political “wins” are of the utmost importance. Especially when you have numerous different teams of seemingly disparate stakeholders that have their own respective cultures. With varying degrees of value held to UX.

    The quicker you can *gain* those “wins,” the better of a case you can build to executive stakeholders that would have the ability to mandate global changes. And, going up to the fourth and fifth level is especially dependent on how much UX-valuation the company at hand is willing to “stomach.”

    8
  3. 4

    Great article; that’s exactly what I’ve been doing in the last 5+ in my current job at a big university in southern Brazil as the leader of a small web design/development team, handling a plethora of sites of all faculties, laboratories and other departments. I firmly believe in this approach to handle a large legacy of sites,some having more than eight, ten years of age. It’s a tough fight.

    2
  4. 5

    Great read Stefan. It’s like Maslow for UX.

    7
  5. 6

    Fantastic article Stefan! I’m attempting to forge a solid UX culture at my company, and though my role as chief designer gives me some clout, UX often falls by the wayside in favor of speeding up the initial development (yes, we’re “Agile”).

    Though I will never abandon my commitment to user-centered design and a quality user experience, your article gives me hope that we can circle back and fill in the gaps after each sprint. Is that ideal? No, not at all. But sometimes it becomes necessary, and it really *is* possible if you’re determined enough.

    5
  6. 7

    This is one of the most challenging areas in helping large organizations with decent UX change. I find that once the visual ‘Corporate Identity’ is identified and adopted across all the different products, behavioral changes are easier to adopt as an organization. I like your analogy of makeup on a pig, but this is the most critical part. If this attempt fails, that genuine UX design and experience will never happen, the project stops dead.

    Brent Coetzee
    @leachgular

    2
  7. 8

    Abdulhamid Alattar

    September 27, 2012 2:05 pm

    loved the last 3 paragraphs. This process takes time, effort and cooperation between the corporation backbones. As the user experience designer want other teams to feel empathy…he should also feel empathy about how other sees it. It’s an internal investment!

    0
  8. 9

    This article hit the mark. Thank you for your valuable insight. Was just in a meeting yesterday discussing how to explain this process and then I see this! Very clear and concise.

    0
  9. 10

    I certainly agree that this is an issue for companies with legacy product lines. However, the challenge is often justifying the benefits of doing the work. How do you measure the value of unifying the user experience of products to people who use your products and the business? Addressing the visual consistency of web based products is comparitively much easier than applying consistent visual design and branding to desktop applications. UX designers usually have more hands on control e.g. by changing CSS files. With desktop applications you need to secure development resources to make changes and the work can be expensive to undertake. Do you have any experience of measuring the value, starting with the visual consistency? What metrics have you used? Thanks.

    4
    • 11

      It can be difficult to justify easily before the change is implemented and can depend on resource available.

      If you are able to prototype and test you could perhaps demonstrate improvements through reduced learning requirements or reduced hesitation in actions performed on elements.

      In the end you have to prove that these changes achieve improved revenue, improved efficiency, customer/employee retention or any other measure you can think of can be used to justify and “prove” the change was justifiable.

      Of course unification could even be about brand recognition and marketing improvements rather than any product efficiency improvement, which can be difficult to measure as the proxy measurement of revenue does not necessarily have a direct correlation to marketing improvements…

      1
  10. 12

    Great article, and I completely agree. One issue we have at my company is Developers finding no value in UX and ignoring the mockups. So we end up having to scramble to come up with a way to make their half baked implementation work. Good times :)

    2
    • 13

      That’s a tuff one and it speaks to change at the top. The business needs to be focused on quality. As long as the date is driving development user experience is going to suffer. Sell the business on the benefits of quality: customer service savings, improved customer relations and trust. A quality mandate from on high will result in development cycles that are not driven by dates and hires that will result in craftsman that can code and care about the experience. At least that is what I am hoping.

      2
  11. 14

    Fantastic article! This is such a clear and concise explanation of how to solve a HUGE problem that so many medium to large software companies face. We have been dancing around this issue for the last 2 years and this article has given me a plan as well as the language and vision for how to work with my boss and the executive leadership at our company to push our products forward. Thank you again for the valuable insight!

    1
  12. 15

    Great article, small world!

    0
  13. 16

    Is it just me, or are we missing a level-zero?

    Something like “use cases” or such.

    It doesn’t really matter if the products look the same if they don’t do what they were really intended to do. Widget-level user experience should come afterwards.

    On a sidenote, Dieter Rams and most people in the Bauhaus had a degree in architecture. What if we stopped bashing engineers and would rather start thinking about the whole stuff as an engineering product instead?

    You know, we have designs, we make other people construct them, and they get actually used for something by a community of people. This is what unites civil engineering, mechanical engineering and architecture.

    Can’t we just make this software engineering instead?

    1
  14. 17

    Geat article Stefan.

    A case study would have help me to understand the concepts better.

    0
  15. 18

    Dmitry Nekrasovski

    October 1, 2012 9:27 am

    Part of me really likes this article – it defines a clear and well thought out conceptual approach for solving a very common and complex set of problems in the field of UX.

    Another part of me, though, feels that this approach is dangerous because it would never actually fly in practice – at least not the way it’s described in this article.

    The reason is that the reality of the way organizations do product design and development is messy, political, subject to frequent direction changes based on various inputs, and generally not likely to allow for this sort of a measured and phased strategy for making UX improvements.

    Unless you have a UX-minded person heading the product organization (and taking the long view rather than focusing on the next set of releases, and willing to stand up to his or her bosses, customers, etc. to make this happen), you will never see enough of an organizational commitment for this approach to succeed in practice.

    Heck, try explaining the difference between “behaviour consistency” and “behaviour optimization” to your average product exec, and see how long it will take them to tune you out and start asking you if their whole product line can be as good as Apple’s by next quarter. :)

    In summary: I liked the article, but what I would really like to see is a case study of this approach applied in the real world. And, for reasons outlined above, I’m not holding my breath.

    8
  16. 19

    This is an extremely timely article Stefan. My team is currently in the exact situation that you outline here, and the solutions you present seem perfect in our case. In theory, these concepts seem flawless, so we’ll see how they work out in practice.

    Great Article.

    0
  17. 20

    Thanks for writing this post :)

    0
  18. 21

    Thank you so much for this great article. I have been trying to consolidate business applications written 10 years ago with the new ones. It is a challenging task and this article breaks it down and puts things in perspective for me.

    0
  19. 22

    I don’t want to split hairs by constrating “unification” to “integration.” Some people admire Apple for integrating ipod with iTune etc. Some people(if I am not mistaken, it’s in BusinessWeek) admire Apple for not integrating iOS, MacOSX etc together, but integrating all Apple devices via iCloud — something similar to “blackboard” architecture.

    So, I agree with you that one product should work with another in the context of one company, but we should not press unificiation or integration too far.

    Thank you.

    1
  20. 23

    Luis Martinez Ordoñez

    October 22, 2012 3:59 am

    Great article.
    Although sometimes it is really difficult, is like a guide to do it ‘the proper way’.
    In different projects or situations there will be different approaches, but this is a very clear path to develop to the desired solution.
    Thanks for the opinions too.

    0
  21. 24

    I would love to see that pyramid as a letter or tabloid-sized print

    0
  22. 25

    Just revisited this article and after a year of working in an environment that embodies the challenges you wrote about I have to say this article is fantastic. Not just the astute insights in it but also the clear and relatively (considering the material) simple way you explain it. So great.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top