We’re in the middle of a redesign project at the moment and as usual Design Thinking played a great part in how we approached it. Design Thinking teaches us to put our effort into figuring out the problem properly before we even think about going near a solution. Then, when you have some solutions, test them all thoroughly.
So this is what we’ve been doing in this project. Plenty of time was spent with customers up front to ensure that we were focusing on the right things. The issues were clearly defined and solutions designed.
Right now we’re building out the prototypes and testing them to see how they perform, but here’s the thing: some of the prototypes clearly aren’t going to do very well in testing, that’s fairly clear before the tests even go live. There are three things you can do in this situation:
1) You can redesign the prototype, which is usually the best option but takes time.
2) You can test the prototype anyway and find out more about how it fails, which gets you more data but also takes time, and then you have to redesign the prototype anyway.
3) You can redesign the test so that the prototype passes. Be very careful if you do this – it’s usually a terrible idea.
Now redesigning the prototype doesn’t sound too bad – that’s what iterative design is all about and it’s what we all signed up for. But when writing the user test is what exposes design weaknesses rather than performing the test itself, then something must surely have gone wrong with our process somewhere.
This is where I think we can take a leaf out of the software development bible and hearken to the process evangelists therein. It’s been nearly 15 years now since Test Driven Development became a Thing and now developers routinely write their tests before they write the code. The code isn’t written to solve a problem, but to pass a test that the problem defines. It’s an extremely rigorous way to code and results in a very robust codebase.
As designers, why aren’t we doing this? As soon as we have defined the problem we are trying to solve, why don’t we translate that definition into a suite of user tests that the design has to pass, before we start designing.
The beauty of this approach is that the tests have to be written anyway, all you have to do is write them earlier in the process and your results will improve, without the expenditure of more time.
Next time around we’re going to ensure that user tests are written as part of the problem definition and before anyone goes near a design tool. I’m guessing this will reduce the design cycle time significantly.