Google UX Designer David Hogue Shares How to Reverse Over-Complication in Product Design and How to Avoid It Altogether
Most product designers have the best of intentions with their work — they want to make quality products that solve problems for their users, and strive to constantly find new ways to serve and delight them. But these noble intentions can have unintended negative consequences: slowly, piece-by-piece, new product features, expansions, and tweaks pile up, resulting in clutter, complication, and eventually friction. It’s very difficult to remove features once they’re added to an app or service, and before a designer knows it, their once effective user experience has deteriorated.
That’s where David Hogue comes in. An applied psychologist and interaction/UX designer, he is a UX design lead at Google responsible for improving UX quality, cohesiveness, and consistency across Android platforms and devices. He has made it his mission to help design teams avoid overly complicating their products, and to helping them triage their apps and services when ‘feature bloat’ gets the better of them.
At FITC Toronto 2019, David will present a talk called Simplicity Is Not Simple, focused on this very issue (along with a workshop called Designing for Wicked Problems, which focuses on solving user problems that don’t have a clear optimal solution). FITC runs April 29 — May 1, and you won’t want to miss David there. In the meantime, we asked him to share of his best advice on keeping your products lean and effective, and why simplicity is key to making sure the products of tomorrow place human-focused design at their core.
Products and services naturally evolve and grow, always trying to be more and better. Technological advances enable products and services to do more, users give feedback and requests, product roadmaps mean new features and content are already planned, unanticipated use cases pop up, and more. There are many indicators of when products and services are crossing over into complicated territory. If the product team spends more time on things on the below (instead of product research, design, and development), it’s often a sign of increased probability of complication:
Once we add something to a product, it can be very hard to remove it. A few users of a little used feature are often given much more influence in deliberations and decisions, because their pain at losing something feels greater than the friction that every other user will feel by keeping that feature and complicating the product. A little friction and ambiguity added here and there feels like an acceptable trade-off to avoid the pain of removing something, but gradual increases in friction and ambiguity lead to an overall decline in the quality of the product. Each individual change seems tolerable, but together the experience deteriorates noticeably.
All the negative things that can happen to products can be instigated and exacerbated by complication: abandonment, dissatisfaction, negative feedback, reduced usage, decreased revenue, slower adoption, increasingly differentiated competition, etc. When products become difficult to use, frustrating, and/or confusing, users begin to seek alternatives and replacements. People will tolerate an unreasonable amount of complication if they think they have no other options, but they quickly abandon this kind of product as soon as a potentially viable alternative appears.
There are very few products where users welcome increased complication — the value provided by the product or service and the user’s confidence that it will meet their needs must exceed the costs of increased effort (time, pain, work, error, friction), otherwise they’ll look for other products and methods to perform tasks and achieve their goals.
Take the time for foresight and forethought. We know the product is going to change, grow, and evolve, so put in the time to anticipate the directions it might take. Leverage methods from speculative design and critical design to explore potential futures and failures.
The pressure to get a minimum viable product (MVP) out the door can make it difficult to spend time planning beyond the current phase (maybe not even the next step), but design can look and plan farther into the future than what is being built now.
Anticipate the future and design scalability into the product or service from the beginning as much as possible. What new data or analyses might become available? What user needs and tasks might be needed? What content might be useful? How might the architecture need to grow to accommodate new features, flows, and information? What new, emerging technologies might be relevant to incorporate? What new business models might be pursued? It is easier to remove something from a design (then put it back later when it is needed or when it can be built well) than to force it in under time pressure.
Stay focused on the critical user journeys and key use cases. Research, metrics, and analytics help us understand the difference between essential and/or differentiating features from those that users and stakeholders think are ‘nice to have.’ You are not your user, so do not focus on designing for yourself. Be user-centric in research, design, development, and product strategy.
Critically evaluate every new and existing feature for the value it provides weighed against the costs of including in a product or service. Does a feature introduce friction or ambiguity? Does adding something more make flows, paths, and choices harder to understand? What are the potential positive AND negative outcomes of adding something, and it is worth it?
Yes, constant vigilance against entropy, scope creep, and the accumulation of friction is necessary. Pausing for review after major releases, conducting retrospectives after updates or changes, critical analysis of product performance before and after a change, and ongoing quantitative and qualitative research can all provide information about and indicators of increasing and unintended complication.
When faced with a complicated product, you should ask:
If we have the opportunity to improve the product or service, these methods provide some paths to simplification:
For many teams, it takes time and effort and lots of persuasion, because the more complicated a product has become, the more difficult and painful it can be to simplify; the greater the perceived risks, and the greater the cost of reducing complication.
Monitoring and maintaining simplicity on an ongoing basis requires commitment, but this mitigates the time, effort, and pain of making large corrections. It’s easier and more cost-effective to be continuously vigilant, because a little work done frequently is better than much work done infrequently.
For example, Android phones are highly customizable, and over time the Settings evolved into a long, shallow list of options full of technical terms. For the past few years we have been focused on making settings easier to use without losing the important customizability. Long, flat lists of options have become shorter with more hierarchical depth. Settings categories are organized around key functions using meaningful, recognizable terminology. Options are prioritized with high frequency, important items exposed and low frequency, optional items hidden or collapsed in the navigational hierarchy.
I would ask them, “How often have you wanted to simplify other aspects of your life? Clear your desk? Organize your books, files, and asset libraries? Complete tasks on your ‘To Do’ list? Be more like ‘Tidying Up with Marie Kondo’ on Netflix?” Users want their lives simplified to, and we’re doing it for them.
Valuable products bring focus, are well-organized, provide guidance and direction, and inspire the user’s confidence in their ability to complete difficult tasks and make them feel easier and simpler. We do not lose value or confidence by making things more usable, meaningful, and predictable.
Yes, sometimes we have to remove something significant or radically change a product, but that is typically when we have a better replacement for it. For example, USB ports have changed over the years, and it’s a hassle in the short-term (in terms of time, effort, and cost) to buy new cables, connectors, and adaptors, but the newer standards are faster, easier, and more reliable.
Sometimes the business costs vs. returns dictate changing or removing something that still has user value, and this is a difficult situation to be in. We know people want, need, or like using it, but we cannot reasonably continue to offer it without some other substantial sacrifice in terms of cost, complication, or technical capability. In these situations we might ask:
The decision must be a rational compromise that balances user needs, business requirements, and technical capabilities. Our products and services are providing value to users, and what we are able to offer may change over time, but remember: the great thing about many digital products is our ability to improve and change them as often and as quickly as necessary.
Google apps like Gmail, Calendar, Drive, and Docs can be continually improved (and periodically revised) as advances in technology, user feedback, and usage data from research and analytics help us understand what people need and how they use the products.
The Chrome browser receives an update (some fixes, some new stuff) about every 6 weeks. Every new feature, function, or service is an opportunity to review the value of the product as a whole and manage the natural ebb and flow of complication and simplification. Chrome has adopted new CSS standards (technical advances), offers new Developer Tools (new features), modifies how browsing history can be reviewed (improved features), and even changes the appearance of the interface to reflect newer standards and tastes (improved quality).
If we, as designers, want to solve problems, fulfill needs, and provide value to people around the world, then it’s our responsibility to craft usable, focused, purposeful products with high quality, positive experiences. Our products should eschew unnecessary complication, and we’re in a position to influence the discussions and decisions by defining a product’s purpose and showing what an experience with it should aspire to be. Ultimately, what we and our teams deliver to people is a carefully optimized balance among user needs, business requirements, and technical capabilities; as designers, we connect these worlds.
Simplicity is not the goal, it is a guiding principle, and there are certain product design principles that have arisen repeatedly over the past few decades:
As UX matures, we will more formally embody core principles in our craft, goals, and practices. Principle-guided design will join data-driven design and user-centered design as ‘just the way we work.’
People tend to notice when things fail or do not work (a frustration) more than they notice when products succeed and work well (an expectation.) Sometimes our best work goes unnoticed, because great products help people focus on what is important to them, not the thing they are using. Success may be quiet, but silent gratitude and appreciation manifest as product adoption, loyalty, referral, and (hopefully) revenue. When we do things right, we re-do fewer things.
I’m a fan of the television program Futurama by Matt Groening, and one of my favorite quotations from the show is from the “Goodfellas” episode from 2002: “When you do things right, people won’t be sure you’ve done anything at all.” Great design doesn’t distract people, it keeps them focused on what they are doing, feeling, and achieving.
FITC Toronto is a three-day professional celebration of the best the world has to offer in design, web development, media, and innovation in creative technologies. To catch David Hogue on other technology and design experts from around the world, join us April 29 — May 1, 2019.
Google UX Designer David Hogue Shares How to Reverse Over-Complication in Product Design and How to Avoid It Altogether
Research & References of Google UX Designer David Hogue Shares How to Reverse Over-Complication in Product Design and How to Avoid It Altogether|A&C Accounting And Tax Services
Source