Test-driven methodology in product design
How can the TDD methodology improve your design teams’ workflow
Test-driven development (TDD) is a methodology on improving the delivery from concept to deployment in the most efficient way. There’re plenty of buzzwords out there at the moment but strip it all back we are just trying to find a way develop software in the most agile way. Taking the TDD methodology we are going to modify the name a tad and change it to test-driven product design but still very much on the same lines.
First of all, what is TDD?
Test-Driven Development (TDD) is a process for developers to write the test cases for features before coding and building the feature. You breakdown all of the actions a user will take from start to finish. By following this test first approach a developer understands what they are building for and focuses on the product requirements.
What is TDPD?
Similarly to the TDD approach, for test-driven product design the idea is to test first. At the start of any project everyone has their own ideas, hypothesis and theories on what will improve the UX of the website or app.
The only way to objectively decide on what is the best approach is to ask the customer. In a test-driven product design world we’d have the following stages:
- Outcomes, assumptions and hypothesis
- Design and prototyping
- Create the minimal viable product for testing
- Research & learning
- Repeat the cycle
Outcomes, assumptions and hypothesis
The first part of the cycle is the hypothesis, this should be a clear vision of what we are trying to achieve. It shouldn’t be a wishy-washy statement like “we want to create a new landing page” instead set some clear goals such as “we want to improve click through rates on our landing pages by improving the mobile experience”. The key to this part is minimal documentation, you want to get your ideas out to the customers as soon as possible
Design and plan
To keep your team aligned and to show key stakeholders what the idea is then design and prototype your idea. Keep in mind that the key stakeholders aren’t the decision makers, your customers are. The amount of work at this stage should be minimal, it doesn’t have to be the polished end feature.
MVP and testing
At this stage build the product or feature to the point of where you can get useful, relevant customer feedback. For me personally this is where I would use software like Optimizely or Adobe Target to test the idea, taking the hypothesis with the goals, the designs which have been signed off by the stakeholders and then getting it out of the door. It’s also worth creating a test plan some time during this stage, this will be the go-to place for your hypothesis, designs and once you have them the results.
Research & learning
Once your idea has been tested analyse the results and see whether the hypothesis resonates with your customers. If the results are inconclusive then segment your results you may find deeper, unexpected results with your test. If the results are negative this is not a failure, record your data, go back to the drawing board and try to understand why it was negative. If it’s positive then implement the feature and then build on top of that.
Repeat
Your product will never be finished, there are always features to be tested and improve on. By going through this cycle you are minimising the guess work of whether something will work or not by going straight to your customers.
You will also have better team morale as it’s less about personal opinion and aligning on the business goals such as improving conversion, reducing bounce rates or whatever your key goals are. Finally, keep these cycles small and often, try and aim for constant feedback on your products to make sure your aligned with your customers.
