“Run it through someone other than yourself…”
There are no certainties in life — or, the art of testing in business environments.
Let’s talk about certainties for a moment. How many do you have in your life? And when innovating and developing a new proposal, how many certainties do you have regarding what you are drafting up and have in some way synthesized? Do you think everything is ready and awesome? What gives you this determinism only after having created your prototype? Be honest!
If I had to answer these questions, I’d be sure to say that I have no clue whether my original hypothesis of a product translates well in a design. After all, after empathizing, defining, ideating, and prototyping a concept, you still are unaware of how anyone else perceives this proposal except yourself. In our previous post on prototyping in this series of articles looking at design from a business perspective, we mentioned the benefits and reasons to prototype. Self-reflection and materiality were the case. But for whom other than us, to do what?
To be realistic, on the path from “design brief” to “design roll out”, we designers are on a journey that starts from the almost or completely unknown and reaches the point when we’re as certain as possible. But rarely 100% certain. Because we’ve studied, considered, interpreted, drawn on personal hunches, and combined these with worldviews, opinions, habits, and practices of people who might use these services, which are not necessarily us. And here is the clue. Creating something new for someone other than yourself surely holds a degree of personal interpretation. So, taking the stance of considering your proposal ready and perfect, without consulting the actual person the proposal is intended for, is at least arrogant if not, at times, dangerous.
So, how do you increase certainty?
Well, you’ve created a wonderful prototype! Or many of them! You’ve done a great job learning from them. You’ve thought many things through, and have had long and meaningful discussions with your prototypes and the design team. If you want to avoid personal bias, there is only one thing you could do.
Give your prototype to other people.
Up until now, you’ve made your own weighed assumptions and hypotheses, which carry a degree of uncertainty and possibly still bear blind spots for you. This is perfectly fine since our world has been built on hypotheses that were trialed, proven right or wrong, and readjusted accordingly — remember the scientific method as the way for humans to gain certainty on once unknown matters. It is good practice to follow similar steps when your proposed product/service is ready to leave the R&D lab and enter the real world.
Congratulations, you are entering the phase of testing your proposal. And you need to have a few things in mind to do so.
Testing is a wonderfully exciting stage when you get to learn a lot about your original idea. It is always an exhilarating moment when your prototype is handed over to a real person, outside your immediate team.
What you are after, is to learn where it stands in realistic terms, away from the design team and the R&D lab. The individual doing the testing will be the one validating the proposal, and their feedback after living with the prototype can enlighten any decisions you have already made. It is possible that your hypotheses were based on not-so-accurate or universal data — after all, you had limited time and budget to carry out your research and empathize with users. It is possible that something slipped under your radar, you mis-defined your challenge, or your prototype is missing information or features and gives a different impression of your service.
Nevertheless, during testing you have a chance to redeem your work, identify these mishaps and even amend them on the spot. And if things are not amendable on the spot and deeper thought and intervention is required, it is a first-class sign that you’d probably have to return to the drawing board. And you should.
But instead of considering this profound moment a failure, you should be extremely proud of yourself! Because on your own merit, you’ve been open to reactions and feedback and have identified a mistake that would possibly lead to great problems if you were not testing a prototype, and rather, troubleshooting while in the real world.
This is a great find!
When to run a test
As with the prototype, there is no good time to run a small or bigger test. As a “pain identifier” for the product or service experience, you can run a test whenever any prototype is ready and it makes sense to do so.
You can do so when you’ve made a decision but are unsure of it. Or when there is no way you can be sure of your design because statistically, you cannot depend on your own viewpoint. This is when you want a reality check from others, so they can challenge your thoughts and materialized ideas.
Another good moment to run a test is when you think you’ve nailed it! Or when you believe you’re done and have made, in your opinion, a great decision. In this setup, the results of testing a prototype can help you get a good night’s sleep, because it’s not all on you anymore. Rather, the test results provide a set of data for you to reflect on and understand what the implications of your current proposal are. These results help you develop wisdom on the service or product and act accordingly for its development.
The mindset for testing
There are a few things that anyone putting their prototype to the test need to consider about themselves. Already, the word “arrogant” has appeared in this text in a negative connotation, so that is one thing to keep in mind. Then, there is the element of being human. You are a natural at making mistakes and this prototype certainly is another one of your masterpieces! So, when someone points mistakes out, whether or not you’re already aware of them, take them in with humbleness and thank the feedback providers! Not everyone is kind enough to provide feedback, so cherish it when it comes your way. It is the case that sometimes, deliverable time and budget does not allow for full exploration of the challenge at hand and inevitably issues are prioritized. Keep in mind that issues unanswered tend to come up in testing and feedback sessions with users. If they keep on coming up over a number of tests all too often, it is clear that you should do something to address them. It can be that you did not set your priorities right.
To make testing work, you’d also have to leave some big things aside: your pride, ego and strong opinion. There is no room for these, here. I’ve heard immature designers complain that during testing, users don’t get how the product or service is supposed to work, falling into the loophole of claiming that users are ignorant, unaware and even uneducated. But this is the wrong perspective, since users should get it and should understand it. It is the designer, as the orchestrator of a new reality, that has not made the product work for users — has not made the user familiar to the product/service, aware of what it is there to do and educate them into the new reality. It can take some time for the designer to comprehend and mature their perspective in this regard, but once felt, this hard but wholesome lesson can shift one’s way of seeing circumstances for good. Remember the first text of this set, on empathy and reading circumstances.
Strong opinions are discouraged because they don’t easily permit a breadth of perspective on the incoming feedback, or even allow the space for something completely unexpected to enter the field of interest, however, that does not mean that no opinion is in place. On the contrary, a sense of direction ought to be present by the designer, in order to be able to evaluate the feedback and in response take it onboard, leave it out or transpose it in favour of the product/service. Additionally, one needs to remember that all original assumptions and hypotheses are placed on the prototype and shared out there to be happily confirmed or dismissed in practice. No designer should either feel offended by negative feedback or turn cocky because of positive responses.
F***ups will continue to happen, and people will identify them. It is the designer’s job to take whatever comes their way courageously, bite the bullet and not take things to heart. After all, it is just a new proposal, and nothing more. Had you not come across difficult feedback during testing, it would have come up in the product’s real life out there, and then maybe the term “full-blown shitstorm” is an understatement.
So, the mindset of the designer during testing is to be stoic, to gloriously and respectfully accept feedback, and aim to uncover as many faults of their proposal as possible, repeatedly. This can be the only practical way to move from the unknown to the “a bit more known” territory. And still, even when the product is living its own life, unforeseen situations will arise and more product fine-tuning will be required. All one can do is to try hard to minimize the consequences of their new intervention based on rigorous tests and keep their eyes open for the new arising unforeseen instances.
Different kinds of testing
Of course, when testing you want to find out as much as possible regarding your prototype and run as many tests as things you want to figure out, e.g, about form, legibility, understandability of your product etc. Given that the main reason of testing is to minimize uncertainty, unable to completely eradicate it, there are a number of ways one can try their product or service, depending on available time, resources and required breadth and depth of feedback.
The first and most natural path that a design team may take is to organize a test within a controlled environment, where testers might be easy to reach — be it extended colleagues or friends of the proposal — providing spare sets of eyes willing to experience what is being proposed. This controlled environment is a safe space and can be very interesting to gauge first impressions and gather initial feedback. However, these testers may not necessarily align to the user group of the final product/service, especially if the test is role-playing. Additionally, they may somehow have been exposed to elements of the proposal, making them biased users, possibly “contaminating” the test as an experiment.
In order to overcome this, it is important to additionally take a more extrovert approach — for some, a terrifying experience. I like to call this: testing “in the wild”. As you might imagine, this kind of testing uses an environment as close to the actual life of the product/service as possible. In this mode, the designer needs to let go and surrender their design in the arms of the almost unknown use. “Almost”, because whoever receives the prototype might be informed of the testing , might be given a relevant disclaimer, may receive information as to what is expected of the test, and might be submitting feedback to the design team, somehow. Whether or not the above are disclaimed, the design team needs to design how to invite and document feedback. Thus, the prototype can be completely handed off to real users for a limited time and the design team will have to go through the nerve-racking process of waiting for the test results, or it could be used within an observed environment and results arrive on an ongoing pace. In any case, the experimental process needs to be pre-organised.
In the business world, a test “in the wild” can be a mini project, a scenario exploration or thought experiment, where little is expected in return. However, when more robust findings and insights are expected by a test or a trial, business talks about pilot projects. An even greater test of products and services “in the wild” can even be a startup! Newly-found businesses incorporated around a core product not only test and continuously fine-tune their offering, but also shift around what actual users choose or do not choose to purchase and push the limits of what the market accepts or jettisons.
Then what?
After any sort of testing, the design team will have learned a great amount more. Assumptions challenged, original decisions altered, the beauty of testing is that it validates, optimizes or destroys hypotheses within a safe and controlled process. Real feedback from real users can generate new thoughts to the design team on what’s working and what is not, what opportunities arise and what weaknesses need attention. It can send the design team back to the drawing board, back to empathising with users, or redefining what it is they are doing and even pivoting the service. And there is no harm in any of the above, given the design team has stayed focused and test after test has strived for the most certain and robust results.
The more tests made, the less weaknesses in the final product. However, there is a time to ship the product. So, in every test, test like it’s the real thing. Accept the feedback like all comments are true. Ponder upon it and given your overviewing perspective, decipher what to take onboard and how. Even if it isn’t easy, these steps will make you walk taller and wiser. Because the originally unknown is now a bit more known, validated with the help of others. Be thankful, ship the product and begin the next iteration of your service.
And there it is. Your confidence has risen a bit, as uncertainty minimises. Though it never becomes pure certainty, this statistical reassurance can be extremely helpful to feel better about the risk you’re about to take.
So, then, do it. Ship the product and remain vigilant!
This text is the fifth in a series of five articles discussing the design process with a business outlook, focusing on the respective Design Thinking steps. You will find the links to the rest below as they are being created.
Intro: “Thinking Design”
Step 1 — [empathize]:
Step 2 — [define]:
Step 3 — [ideate]:
Step 4— [prototype]:
Learn how to turn innovation on in any organization or reach out to Found.ation for a tailored solution: thefoundation.gr.
