Published on <a href="https://blog.prototypr.io/how-to-fail-at-design-f3078c984e28?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Amalie Barras 
So the other night I was watching a ridiculous film called Boss Baby… when I heard a surprising quote that I had to pause the movie and contemplate for a second.
<blockquote>“Aim for failure and you’ll always succeed.”</blockquote>
Just to clarify, this is an animated child’s movie has nothing to do with design, and is almost 100% a tongue in cheek political commentary. But ever since I began studying design thinking and agile methods, I perk up at the word “failure”.
In the world of design, we talk about “failing fast” and “failing early and often”. There’s even a really great improv technique called the <a href="https://www.youtube.com/watch?feature=player_embedded&amp;v=cXuD2zHVeB0">failure bow</a> which I’ve seen used in working teams.
<img alt="" src="https://cdn-images-1.medium.com/max/256/0*N9FOzMvRo9YlmoFk.">
We’re coming around to the idea that maybe failure isn’t bad… and that’s good, because we want to give ourselves room to take risks. But is this quote really accurate? Should we aim for failure at all costs? Aren’t there wrong ways to fail?
I kicked it around in my head a bit and came up with some guidelines I use to make me the best failure I can be.
<h3>1. Have a clear objective of what we want to learn:</h3>
Lack of a game plan is not a good reason to fail.
I’ll be the first to admit I’ve accidentally made a useless prototype. When I was first applying the design process to data dashboards at EA, I wanted to wireframe the design to get feedback on my dashboard before actually doing it. I used a charting design sticker sheet to put things in places, and buttons where buttons would be. I put it in front of the eventual end users and asked in a super open-ended way for feedback, and in almost every scenario it was “it’s really hard to say if this will be useful without seeing how the real data changes.” Which is true. A line chart with a flat week over week trend is not actionable … but if the trend is all over the place and links to deep dives, it’s a completely different story.
The takeaway? We need to leave room for flexibility, but in the same way we don’t want to have a meeting without an agenda, we don’t want to sink a week of work into a prototype that won’t answer any questions. In order to experiment deliberately, we’ve got to start thinking early about how we’re going to get our answers.
<h3>2. Do our homework:</h3>
Gaps in information are not a good reason to fail.
This is another example from my analytics past life, where a stakeholder sent along information to review and for one reason or another, our whole team wasn’t up to speed. I could feel the stakeholder becoming frustrated at having to answer the same questions multiple times. I felt super frustrated because I’d worked hard to form this relationship and then one bad impression made the whole team look unprofessional. Now, as a user-centered designer, stakeholder and end user relationships are even more crucial, and therefore more fragile. Doing our homework is more important than ever. Without this due diligence, not only do we we run the risk of seeming sloppy, but it becomes difficult to build rapport with our users and uncover insights during research.
This is a tricky one, however, because while we want to have enough information to know the domain we’re in, we also want to leave room to discover the problem space. That said, we can research things like history, business goals, and competitive analysis without compromising our curiosity about the user’s problem space.
<h3>3. Process our info fully:</h3>
Confirmation bias is not a good reason to fail.
For a research project during my city era, I entered what felt like the “upside down” of political stickiness to solve a very technical problem that I had no background understanding and no opinions in solving. I was terrified of this lack of background information, but once I got in front of these users, it actually ended up being an advantage because I felt more objective in understanding and asking direct questions about the problems users were having. When you’re wearing your researcher hat, you get to ask basic questions because that’s your job. Nobody knows how much you actually do or don’t know about stuff.
We can’t help but be attached to our ideas. They crawl into our brains and massage the thoughts and feelings along the pathways that are already forming there, validating our understanding of the world around us and strengthening our identities. This is a great piece of the human experience, but it can be a total obstacle to discovering new information. We all have certain default settings which give us reactions to information. And it’s important to analyze info from that “me” standpoint. But to have the strongest analysis possible, it’s also important to make deliberate space for the head, and then heart, and then gut to all have a turn in the analyst seat.
<h3>4. Get feedback</h3>
Isolation is not a good reason to fail.
When I was a baby analyst, I received a request directly from an external stakeholder for a report. Eager to impress my new colleagues, I hastily pulled some numbers based on the methodology I partnered on with a producer, and sent the report out. WASN’T SUPPOSED TO DO THAT. There was a protocol for vetting new metrics that I wasn’t aware of because I wasn’t interacting with my analytics team and getting feedback on what I was doing. I had impostor syndrome REAL bad and was afraid of seeming needy or junior if I asked for feedback.
Whether you’re isolated because you’re afraid of rejection, because you think your work is good enough and nobody cares, or because your organization doesn’t create space for feedback, working in isolation will at the very least limit your growth and at the worst, destroy your spirit. Conversely, getting as much feedback as possible turns your opportunities into greatness.
That’s another blog post for another time.
<h3>5. Challenge our process</h3>
Risk aversion is not a good reason to fail.
I’ll never forget the feeling of my first time drowning in qualitative data and the strong urge of wanting nothing more than to throw the pieces of it into excel and quantify it to the best of my ability. That’s how I handled ambiguity in the past. It’s what I was comfortable with, and what I felt safe doing because I knew it would work.
Good thing I didn’t. As I quickly learned from my brilliant colleagues, <a href="https://medium.com/civiqueso/the-harmony-of-qualitative-and-quantitative-research-80d0bebc4fec">this is not the best way to process qualitative data</a>. Learning a new process when you have a perfectly good one imprinted into your mind can be mind-bending, painstaking, back-breaking emotional work. But just because what you have is good doesn’t mean it can’t be better. That’s what agile is all about, right?
Optimizing?
<h3>Conclusion</h3>
I think this quote is pretty insightful and accurate, but I’d make a couple tweaks.
<blockquote>Aim for failure that is</blockquote>
<blockquote>1. Deliberate 2. Informed 3. Analyzed 4. Critiqued 5. Outside of the box</blockquote>
<blockquote>And you will always succeed.</blockquote>
<img alt="" src="https://cdn-images-1.medium.com/max/400/1*yosd2rLYrogU-6AL6d2uvw.png">
How do you fail? Does anything in here resonate? Something not sit well with you?
Comment below and help me fail at blogging!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=f3078c984e28" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/how-to-fail-at-design-f3078c984e28">How to Fail at Design</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to Fail at Design

Top Stories