The importance of saying ‘no’ in digital and product design

I am basing this article on my own experience of designing/building digital products, and in reaction to attending a great talk by Jared M. Spool, where he talked about ‘building a winning UX strategy using the Kano Model’. I recommend watching his talk and reading more on his site. His talk got me thinking, and I wanted to share those thoughts here.

The ultimate goal for user experience is that users enjoy using your product. Many companies use satisfaction as a metric for measuring their success. But satisfaction is really just the lack of frustration.
— Jared Spool

It’s easy to get sucked into adding more and more features, scaling our products and business inline with what people tell us they want, or what we think they want. This can be a recipe for disaster, leading to bloated, frustrating products and a diminished user experience. As designers, managers or founders, much of what we do is influenced by our customers, critics and fellow team members. To build, maintain and scale the best products and services, we need to identify and focus on what’s important. We don’t do that by saying ‘yes’ to everything, we do that by making informed, considered decisions, and by saying ‘no’.

Who are you designing for?

All of this really is to say: You are designing for your users, your customers! They are people, they have needs, and they respond positively or negatively to good/bad experiences. They are the ones who matter, ultimately. It’s as simple as that. But this is often overlooked.

Products need to meet business goals. But consider, all or most of your business goals will ultimately be met by keeping the people who use your product happy.

Depending on the size and culture of the company behind a product, there will inevitably be many people or departments involved. All of these parties have their own agendas, be it marketing, sales/profit, development, SEO, community, design, UX etc… These internal parties should have their input. Their experience, expertise, and (where applicable) the metrics, data, analytics and research they bring to the table are all very valuable.

Informed decisions are more likely to be good decisions.

But you need to know when to say ‘no’ — and you will know when you are the one to do it, if your expertise, experience, research etc… gives you the foresight (via your insight) to do so. So push back, say ‘no’! In recent years, as a product design lead, it’s very much been my job to do this. It doesn’t always make me popular, but I always explain why, with good reason.

Some people find it harder than others to see it from a users’ perspective, broadly speaking. Be it an engineer (internally) pushing for a simpler, quicker implementation, or one customer (externally) only considering their own need, ignoring the other 99.99% of users. It’s constructive to help these individuals understand the problem from a wider perspective. I often try to set a scene, offer an example scenario, and help them to consider the problem from a (specific type of) user’s point of view.

Basic expectations

In Jared’s talk I mentioned at the outset, he refers to the ‘Kano Model’. An interesting part of the Kano Model is your users ‘basic expectations’. People just expect to be able to do certain things. The interesting thing about these basic needs is that very few people will congratulate you on meeting them, but if you don’t meet them, they may be very vocal about it! So it’s important we consider, identify and satisfy those needs.

Another part of the Kano Model, as Jared put it, is to ‘delight’ your users. This is generally something that ‘wows’ the user, makes them smile, impresses them with how easy it was, how innovative it is etc etc…

Meeting people’s basic expectations will keep them satisfied, and delighting people is an experience to strive for. Both are important for retention.

Some basic features can also delight. Different users have different expectations. Perhaps that extra finesse in how you present a basic feature might be what delights. These kinds of features (or experiences) in your product are especially important.

An important thing to remember when considering what these expectations are, is they evolve over time — they are shaped by changes in technology, events, user behaviour, and your competitors! A competitor may launch a new feature that takes the industry by storm, and just like that your target audience’s basic expectations may change. This is something to keep an eye on. But always remember to stay true to the values of your product. Just because a feature is great in a competitor’s product, it doesn’t necessarily mean it is right for your product!

If your product attempts to do everything, it will quickly become unfocussed, bloated, hard to use and a nightmare to maintain or evolve.

Experience rot

‘Experience rot’ is a term coined by Jared M. Spool, which I encourage you to read more about here. To summarise: Consider, all those features you think are important (or you are adding because you were influenced to do so), are actually hurting your user experience. As you add more features you are likely adding complexity to the design and potentially decreasing the quality of the experience.

Focus on real customer problems, avoiding the problem of experience rot.
— Jared Spool

Listen to and understand your users. Focus on meeting your users’ basic needs, and never lose sight of those.

In any product design environment, you will hear ‘MVP’ (the minimum viable product). It is often seen as the lowest cost (time + resources) product (or new feature) you can put out that meet your target audience’s needs. In this startup era we’re in, most new products you encounter are an MVP. They are intentionally simple, they satisfy the users’ basic needs, and the successful ones most probably also delight the user in some way — probably with its design, UX or an innovative feature that makes it unique.

Most first releases of a design are really simple. The design is a small collection of well thought out features. Everything fits and makes perfect sense. As more features are added, it becomes harder to make the overall design coherent and sensical. Soon features are crammed in and don’t make sense.
— “Experience Rot”

Some products remain simple, and rightly so. If something is designed to meet a specific need, and does it well, then that may be all it ever needs to do, functionally. Jared uses a good example of the TV remote control: What do all those buttons do?! I bet you only ever use the numbers, channel/volume up/down, mute and power off… right? Or take this website for example, Medium.com: Medium stripped back all the noise and focussed on the content (whether you’re reading or writing). Nothing is competing for your attention. Other websites decide they should include all that other stuff, but what do their users/readers want? Medium stripped all that stuff out, and it’s a better product because of it!

“No” fights rot! The best way to fight experience rot is to say ‘no’ to everything except the most essential of features. Deliberately slowing down the product roadmap to only include well thought out and integrated new enhancements will keep experience rot at bay.
— “Experience Rot”

Of course you should iterate on and fine tune your product. Small (or even large) changes can be done subtly, without being disruptive, or cluttering the UI. Design finesse if done well will help to delight your users and improve their experience using your product. They might not compliment you on it, but they are satisfied by it!

Disrupting the market

I’m sure you’ve heard startups say they are ‘disrupting’ a market/industry/sector. What they are really saying here is:

The other products in this sector are bad at what they do. We have identified a niche created by those companies, and are attempting to do it better than them, with our simpler, smarter product.

Consider the outfall of users from Myspace.com to Facebook.com back in the day. For those old enough to have used Myspace in its heyday, you will remember all those profiles with hundreds of animated gifs, horribly broken layouts, custom CSS crimes and embeds crowbarred into every available pixel! All because they let you do it. The Myspace of old might be the best example of experience rot… Remember how unusable and annoying that version of the platform became… Now think about how many of those people left to Facebook, to a seemingly more basic product, with less control, but more order. It did what you needed it to do — turns out that’s all the majority of people actually needed.

A journey you take together

Learn from and design for your users

In my experience, the best products launch with a more limited set of features. An MVP. Get the product out there in the wild. Learn from how people use your product and improve/build from there. A product’s development cycle could look like this:

• Give the audience what they need. Meet their basic needs.
• Learn how they use your product and fine tune.
• Listen to what they want.
• Identify what they need.
• Refine the product to meet their needs.
• Establish there is value in anything you add.
• Add new features that delight — taking the product to the next level.

Never build features for a minority (unless they are genuinely valuable additions), or because people internally at your company think it’s a good idea, based on old data, or their assumptions.

Is there a better solution?

Respond to what people need, not what they say they want, or you think you know

Allow me to give you a real example from a product I worked on in recent years — a new product that replaced an existing product. The old product had one particular feature I made the decision to eliminate from the new product. I was put under a lot of pressure to build this same feature into the new product. The only argument I was given to do it was because the old product did it previously. But why? I asked.

Further investigation revealed the main reason people used that feature was to manipulate the product to do a number of other, distinctive things. The outcome of this was to say ‘no’ to that feature, and instead focus on more considered/targeted features and functionality to enable people to simply do what they were previously hacking the old product to do.

The solution to a problem is not always as obvious as just adding a feature. Consider all the options, and design something that actually addresses the real problem.

Too many people simply take user feedback and implement it immediately without researching, questioning, or thinking. People don’t really know what they need — they just tell you what they think they want.
— “Don’t design what users want”

Focus on solving problems

Or the problem with a roadmap

Having goals is good, but a roadmap makes a lot of assumptions.

Instead of focusing on feature development, see how users respond to your MVP and iterate until you achieve product-market fit demonstrated by real engagement. Use findings to guide your roadmap.
— “Lean Roadmapping: Where Product Management and UX Meet”

Instead of a ‘roadmap’, I favour keeping a record of possible features and enhancements, in a loose order of importance (i.e. value to the user). I personally use Trello to log everything from little product improvement ideas, to big features. It’s a digital record of your sketchbook you can share with your team — an idea pool you can dip into, discuss, concept, or research when the time is right.

A roadmap based on features locks you into a technological solution that may cause problems down the road. However, by shifting your strategy to solve customer problems, the user experience becomes the focus of the design process.
— Jared Spool

I think the above quote is an excellent point. Focusing on solving customer problems is a better strategy than a roadmap of features. Identify and turn your users’ problems into projects. The sentiment being:

Our users want to do/are frustrated by _________________, how can we help them?

This can form the basis of your design brief, or discussion. These projects can be research projects, not every problem requires an immediate design solution. Research, thought and discussion help guide the best course of action.

Don’t be afraid to say ‘no’

Leaders make the calls. But we all have a voice

Product design leads and managers should ultimately take decisive steps to ensure your team/product don’t lose focus. But you don’t have to be senior to question something. Use your experience, knowledge and any data/research/analytics/examples available to you to push back. If you think it’s not right, speak up.

I’ll leave you with a thought from some dude much wiser than me:

“You have to pick carefully. I’m actually as proud of the things we haven’t done as the things we have done. Innovation is saying ‘no’ to 1,000 things.”
— Steve Jobs, Apple