One of the best things about being a designer is that it’s your job to get things wrong.

That isn’t to say that you can design anything you want without consequence. Your job as a designer is to get things wrong as many times as possible before your team goes on to build the “least wrong” thing.

In a world where the MVP - building the smallest possible thing to solve a problem, and then iterating - is held in such high regard in organisations that have adopted agile ways of working, there isn’t enough room for a design team to create the best solution they possibly can when there are deadlines and sprint goals to be met.

This can be a difficult compromise for designers to make; having a picture of a “gold standard” solution to a problem in their mind, but only having the space to take just a few small steps towards it.

Agile isn’t the enemy of good design

If you work in an agile environment, you’ll be familiar with the retrospective; a meeting held after a sprint or release to discuss what happened during the product development and release process, to improve things in future. The Retrospective Prime Directive is:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This is a very valuable way of thinking, not just about what went before, but as something you can apply to the work you are doing, and in setting the goals of your design process when working on a solution to a given problem.

The agile process helps by giving you constraints to your design work in the form of timeframes, scope, technical capabilities, and so on.

"Design is all about finding solutions within constraints. If there were no constraints, it’s not design - it’s art."
Matias Duarte

If you design without constraints, you have nothing to focus on in the delivery of a solution. You can end up spending increasing amounts of time on problems that provide diminishing returns the longer you spend on them. Going around in circles on how to ask a user to enter a date simply isn’t a valuable use of your time, and it can be easy to dive so deep into a single problem that it can be hard to maintain a higher level view of what the real problem is that you’re trying to solve.

What is good design?

Good design isn’t measured by the delivery of working software, and nor should it be measured by the outcomes of your work as an agile delivery team. These are still valid metrics on which to measure the success of a product or service that you have put into the hands of your users - I’m not questioning that at all - but the success of your design process shouldn’t be bundled in with what you deliver together as a team.

Neither should it be measured on the delivery of an interface, how your solution looks and functions.

In fact, it’s really difficult to measure what good design is at all, but you can gain some insight into whether your design process is working well or not by reflecting on your journey through your design process;

  • what did you uncover that was previously unknown?
  • what ways of doing things didn’t work?
  • what problems do people currently have?
  • did you solve any of those newly discovered problems?
  • did you take positive steps towards the desired solution?

Getting things wrong is a fundamental part of this process, it’s how we all learn things as human beings; we make mistakes, and then we go about changing what we did so we don’t make that mistake again in future.

"It’s through mistakes that you actually can grow. You have to get bad in order to get good."
Paula Scher

If someone in your organisation wants to measure the performance of the design team and their process, then you should be convincing them that what you should be judged on is your ability to discover why the thing you did was wrong, and how that made you rethink your approach on your next attempt at getting the answer right.

The iteration within the design process (not in terms of the larger scope of agile working) is where you work quickly to find out the ways not to do things, so when you arrive at a solution, you have not gone down a blind alley that may result in you needing to undo the work you’ve done towards a particular solution.

Aiming for the “least wrong” solution

It’s worth considering that you’ll very rarely get to the “right” solution in the end. The best outcome you may often have to aim for is to create the “least wrong” solution for the problem you have to cater to the most people you are looking to solve the problem for.

Any number of things can prevent you from even getting to the least wrong solution; a lack of time to release, a lack of budget to continue your work or an arbitrary deadline that simply must be met.

Whatever constraint it is that stops you from moving any further forward on improving your solution, you will often have to settle for what is “good enough”. If you trust in your process, if you have iterated on your solution with the guidance of your users, you will always have produced something better than if you had none of that process.

Knowing that you tried something that didn’t work out is far more valuable than churning out designs with no input from users or validation of any kind. Being wrong means you’re learning what doesn’t work, and that can only help you towards your ultimate goal of designing the right solution.