Frictionless Design Choices

No one wants friction in their products. Everyone works to reduce it. Yet it sneaks in everywhere. We collectively praise a service, app, or design that masterfully reduces friction. We also appreciate minimalism. We love when products are artfully distilled down to their essence. How do we achieve these broadly appreciated design goals?

Frictionless and minimalism are related but not necessarily the same. Often they are conflated which can lead to design debates that are difficult to resolve.

A design can be minimal but still have a great deal of friction. The Linux command line interface is a great example of minimal design with high friction. You can do everything through a single prompt, as long as you know what to type and when. The minimalism is wonderful, but the ability to get going comes with high friction. The Unix philosophy of small cooperating tools is wonderfully minimal (every tool does a small number of things and does them well), but the learning and skills required are high friction.

Minimalist design is about reducing the surface area of an experience.

Frictionless design is about reducing the energy required by an experience.

When debating a design choice, feature addition, or product direction it can help to clarify whether a point of view originates from a perspective of keeping things minimal or reducing friction. If people discussing a decision start from this common understanding, I bet a decision will be reached sooner. Essentially, is the debate about adding a step or experience fork, or is it about adding something at all?

Product managers need to choose features to add. That is what makes all of this so difficult. As great as it is to stay pure and within original intent, if you and the team don’t enhance the capabilities of your product then someone will do what you do, but with a couple of more things or a different factoring and you’ll be left in the dust.

Therefore the real design challenge is not simply maintaining minimalism, but enhancing a product without adding more friction. Let’s assume you built a product that does something very exciting and has a very low friction to usage and does so with a minimal feature set. The next efforts are not about just watching your product, but about deciding how to address shortcoming, enhance, or otherwise improve the product to grow users, revenue, and popularity. The risk with every change is not simply failing to maintain minimalism, but introducing friction that becomes counterproductive to your goals.

When you look back you will be amazed at how the surface area of the product has expanded and how your view of minimalism has changed. Finding the right expression of new features such that you can maintain a minimalist approach is a big part of the design challenge as well.

There’s an additional design challenge. The first people who use your product will likely be the most enthusiastic, often the most technical, and in general the most desirous of features that introduce friction. In other words you will get the most positive feedback by adding features that ultimately will result in a product with a lot more friction.

Product managers and designers need to find the right balance as the extremes of doing nothing (staying minimal) and listening to customers (adding features) will only accelerate your path to replacement either by a product with more features or a product with less friction.

Low-Friction Design Patterns

Assuming you’re adding features to a product, the following are six design patterns to follow, each essentially reducing friction in your product. They cause the need to learn, consider, futz, or otherwise not race through the product to get something done.

Decide on a default rather than options

Create one path to a feature or task

Offer personalization rather than customization

Stick with changes you make

Build features, not futzers

Guess correctly all the time

Decide on a default rather than options. Everything is a choice. Any choice can be A/B tested or debated as to whether it works or not. The more testing you do the more likely you are to find a cohorts of people who prefer different approaches. The natural tendency will be to add an option or setting to allow people to choose their preference or worse you might interrupt their flow to ask preference. Make a choice. Take a stand. Every option is friction in the system (and code to maintain). When we added the wheel to the mouse in Office 97 there was a split in the team over whether the wheel should scroll down or whether it should zoom in/out. From the very first release there was an option to appease the part of the team that felt zoom was more natural. Even worse, the Word team went and did a ton of work to make zoom performant since it was fairly unnatural at the time.

Create one path to a feature or task. You add a new feature all is good—you’re in X in your product and then you can do Z. Then someone points out that there are times when you are doing Y in your product and you also want to do Z. Where there was once one path to get to a feature you now think about adding a second path. Maybe that sounds easy enough. Then a few iterations down the road and you have 5 different ways to get to Z. This whole design process leads to shortcuts, floating buttons, context menus, and more. Again all of which are favored by your early adopters and add friction for everyone else, and also add code. Pick the flow and sequence and stick with it. The most famous debate of all between Windows and Mac was over right click and it still rages. But the design energy to populate context menus and the cognitive load over knowing what you can or cannot do from there is real. How many people have right clicked on a file in the Windows desktop and clicked “Send” only to be launched into some Outlook configuration dialog when it would have been frictionless to always know that insert attachment in mail works and nothing will fail.

Offer personalization rather than customization. Early adopters of a product love to customize and tweak. That’s the nature of being a tech enthusiast. The theory is that customization makes a product easier to use because every use case is different enough that the time and effort saved by customization is worth it and important. In managing a product over time, customization becomes an engineering impossibility to maintain. When you want to change behavior or add a feature but it isn’t there or moved you introduce an engineering impossibility. The ability in Office to reorganize all the toolbars and menus seemed super cool at the time. Then we wanted to introduce a new scaleable structure that would work across resolutions and input devices (the ribbon). The problem was not just the upgrade but the reality that the friction introduced in using Office by never knowing where the menus might be (at the extreme, one could open a document that would rearrange the UX) was so high the product was unusable. Enterprise customers were rearranging the product such that people couldn’t take courses or buy books on how to use Office. The constraint led to the addition of a single place for personalization (Quick Access Toolbar) which ultimately allowed for a much lower friction design overall by enabling personalized efficiency without tweaking the whole experience.

Stick with changes you make. The ultimate design choice is when you change how a feature used by lots of customers works. You are choosing to deliberately upend their flow and add friction. At the same time the job of designing a product is moving it forward to new scenarios and capabilities and sometimes that means revisiting a design choice perhaps one that is the standard. It takes guts to do this, especially because you’re not always right. Often the path is to introduce a “compatibility mode” or a way to turn your new product into the old and comfortable product. This introduces three problems. First, you have to decide what the default will be (see the first rule above). Second, you have to decide if/how to enhance the old way of doing things while you’re also adding new things. Third, you have to decide when down the road you remove the old way, but in reality that will be never because you already told customers you value it enough to keep it around. But adding compatibility mode seems so easy and customer friendly! Ultimately you’re creating a technical debt that you can never dig out of. At the same time, failing to make big changes like this almost certainly means your product will be surpassed in the marketplace. See this HBS case on the Office 2007 Ribbon design http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 ($).

Build features, not futzers. Tools for creativity are well-known to have elaborate palettes for formatting, effects, and other composition controls. Often these are built on amazing “engines” that manage shapes, text, or image data. Historically, tools of creativity have prided themselves on exposing the full range of capabilities enabled by these engines. These vast palettes of features and capabilities came to define how products and compete in the marketplace. In today’s world of mobility, touch interfaces, and timely/continuous productivity people do not necessarily want to spend time futzing with all the knobs and dials and seek to minimize time from idea to presentation—call this the Instagram effect. Yet even today we see too many tools that are about debugging your work, which is vastly different than getting work done. When a person needs a chart, a table, a diagram or an image how can you enable them to build that out of high-level concepts rather than the primitives that your engine supports? I was recently talking to the founder of an analytics company struggling with customer input on tweaking visualization which was adding complexity and taking engineering time away from adding whole new classes of visualization (like maps or donut charts). You’ll receive a lot of input from early customers to enable slightly different options or adjustments which will both challenge minimalism and add friction to your product without growing the breadth of scenarios your product enables. Staying focused on delivering features will enable your product to do more.

Guess correctly all the time. Many of the latest features, especially those based on machine learning or statistical models involve taking action based on guessing what comes next. These types of features are magical, when they work. The challenge is they don’t always work and that drives a friction-filled user experience. As you expand your product to these areas you’re going to want to find the right balance of how much to add and when, and patience with guessing too much too soon is a good practice. For better or worse, customers tend to love features that guess right 100% of the time and even if you’re wrong only 1% of the time, that 1% feels like a much higher error rate. Since we know we’re going to be learning and iterating in this regard, a best practice is to consider how frictionless you can make incorrect guesses. In other words, how much energy is required to skip a suggestion, undo an action, or otherwise keep the flow going and not stop to correct what the software thought was right but wasn’t. Let’s just call this, lessons from “bullets and numbering” in Word :-)

Finally, a word of caution on what happens as you expand your customer base when it comes to adding features. Anything you want to do in a product can be “obvious” either from usage data or from customer input. The challenge in product management is to create a core set of principles or beliefs about how you want to move the product forward that allow you to maintain the essential nature of your product while adding new features. The tension between maintaining existing customers via stability or incremental improvements versus keeping pace with where the marketplace is heading is the classic design challenge in technology products.

It shouldn’t be much of a surprise, but a great deal of product bloat comes from adding the obvious feature or directly listening to customers, or by failing to stick with design patterns. Ironically, efforts to enhance products for today’s customers are often the very features that add friction, reduce minimalism, and lead to overall bloat.

Bauhaus to Bloatware

This march from Bauhaus to Bloatware is well-known in our industry. It is part of a cycle that is very difficult to avoid. It is not without irony that your best and most engaged customers are often those pushing you to move faster down this path. Most every product in every segment starts minimal and adds features over time. At each juncture in the evolution of the product there is a tension over whether additions are the right marketplace response or simply bloat.

This march (and tension) continues until some complete rethinking introduces a new minimal product addressing most of the same need but from a different perspective. The cycle then starts again. Operating systems, databases, instruction sets, peripheral connection, laptops, interfaces, word processors, and anything you can name has gone through this cycle.

This re-evolution or reimagination of a product is key to the long term viability of any technology.

By adhering to a set of design principles you are able to expand the breadth of use cases your product serves while working to avoid simply adding more friction to the core use cases.