It’s so obvious. If we invest a little bit more time in design upfront then we will save so much time and money by building better products that customers actually love. And yet, somehow, our arguments fail to convince people. The focus stays on delivery and getting the feature built “on-time and on-budget”. We seem to be the lone voice advocating for the user (and ultimately for the business since better products will deliver more business value). The battle is exhausting, frustrating, and, most critically, ineffective.

But here is the good news. There is a much better way to get the outcomes we are looking for. We just have to work within the system instead of against it.

The realities of product development

People fall in love with their ideas

Ideas can come from anywhere, customers may have explicitly asked for a feature, we might be losing sales because a competitor has a feature that we don’t or it might have come as a result of an internal ideation session to address an unmet need. Regardless of where it comes from, the feature sponsor usually has had to put together a business case for how valuable this feature will be and then they’ve had to defend their work to get funding. This is now their baby. And some pesky designer has told them that their baby might be ugly.

Even if people don’t take it quite so personally, it still comes across as though you are implying they didn’t do a good job evaluating their solution.

Either way, the well intentioned push for more design goes down as well as might be expected.

Incentives are on delivery

When an idea has gone through the business case process, everyone is already aligned. The sponsor has written up the value the feature will deliver and senior executives have signed off on it. The business case process was the time to argue for effectiveness. Once we’ve passed that point it is all about delivery. We have a budget and a timeline and we have to stick to it.

You could argue that design should get involved prior to business case sign off to avoid this problem. But you really need developer input as well in solution design, experiment choices and feedback evaluation. Suddenly we’re asking for a lot of upfront budget to evaluate solutions before they’ve been signed off by the executive team.

Shifting from projects to empowered product teams is an effective way of addressing this problem. Teams are funded to solve problems, not deliver features. But since you’re reading an article on pitching the value of design I assume you are working in a more traditional organisational structure so this isn’t an option.

Making change happen

Your manager likely agrees with your points, and they were once in your shoes making the same arguments, but they can see all of the implementation challenges that get in the way. Like dominoes falling, if we change our processes it will require changes to funding, governance, team structures, alignment approaches and more. This is beyond the capabilities of any individual manager. It requires coordinated effort and alignment from the top down. Even if you can convince everyone of the value of making the changes, it doesn’t help anyone overcome the adoption challenges.

Now time for the good news. The Fogg Behaviour Model, developed by BJ Fogg at Stanford, is a model for understanding how change happens. There are two axes for making a change happen. We focus far too much time on the motivation axis, but we do not spend nearly enough time on trying to make the changes easier to adopt.

Making design easy

There is a concept called the Iron Triangle. There are three edges: Time, Cost and Quality. The size of the triangle represents the scope of the work. Since we are limited by the Time and Cost (we have to do design work that is both quick and cheap) then we only have the options of quality and scope to play with.

Reducing Scope

Testing a complete solution would be time consuming and expensive. But luckily we don’t need to test a full solution to know whether it will be successful or not. Every solution is made up of numerous identified, and often unidentified, assumptions about how people will behave. While some of these assumptions might be fairly innocuous, there will be others upon which the whole solution depends upon. We call these ones leap-of-faith assumptions. By reducing the scope of our design experiments to focus just on these assumptions we can dramatically reduce the overall time and cost.

Reducing Quality

This is going to be controversial, but we can reduce the quality of our design work. In an ideal world, we would be absolutely certain when we finish an experiment whether the assumption we are testing is true or not. But absolute certainty takes time. And the perfect is the enemy of the good enough.

Instead, we can focus on signals. When you have very limited information about a topic, such as an assumption we are trying to evaluate, every piece of information carries high information value. The Law of Small Numbers highlights how speaking to even as few as five people is enough to see signals of whether an assumption is true or not. Yes, there will be false positives and false negatives but this research should just be a starting point - it should be communicated and then see how that influences further actions.

Putting it all together

Using modern tools and systems you can identify assumptions, design experiments in a matter of hours and get results in just a few days. If you get a strong signal that the feature really is important then you just continue working as normal. If the signal highlights that an assumption is wrong, you can share this with the feature sponsor, with a recommendation to do further experiments. Sometimes they will support you, other times they wont. But over time you will increase your trust and carve out a little bit more budget in the upcoming projects.

In summary, while we think we are asking for a small change to do more upfront design, this actually requires a lot of changes for your manager to implement. Large companies scale by implementing rigid processes and they have “organisational antibodies” which protect the organisation from potentially dangerous changes. Real change takes years to implement so rather than trying to fight the system, we need to learn to work within it.

On your next project try to see if you can identify the core leap-of-faith assumptions and challenge yourself to think of quick experiments to validate them. You’ll be surprised what you can achieve.