How to Fail Fast (without feeling like a failure)
Spoiler alert: I change positions by the time I get to the end of writing this.
We’ve all heard it over and over again the mantra “Fail Fast.” But what we haven’t really heard, is how do you actively fail and admit your failure without feeling like a complete failure.
We went through what could be interpreted as a failure recently (yeah, I’m not perfect) and figured writing it out would help me analyze the process and I could share some tips going forward.
Tables are more than just tables
To set the stage, this past year we did a redesign of a lot of our components throughout our product. We got to one that stumped me, and from my research has stumped a lot of peoples as well. Mobile friendly tables (this honestly still haunts me just hearing it). Working on a tax interview we have a lot of large data sets that we need to summarize in an easy to understand way, so, as you can imagine, we have a lot of tables throughout our product. I did what I always did, started my discovery process.
I came to the conclusion that keeping the table at 100% width with the ability to scroll could be the easiest way to maintain context and still be able to have it be easily comparable data.
I know, I know you are probably disagreeing with me right now, and from this project a lot of people did. Our goal was to try something a bit different and see if it was any easier. Remember fail fast?
Let me walk through some no-nos we made and some tips for how we learned from our failure.
1. Analyze the full risk
When working through components, we did the initial scope for summary tables (fig. 1). For someone that doesn’t work with our product day to day, this is the end of the sections summaries that pulls together all the numbers you have entered thus far (income, taxes, credits, etc.).
What we didn’t do was initial research on adding forms and summarizing them. This is an example of where we could’ve made some improvements.
In this instance, the use case is completely different. They may need to edit multiple forms, delete, or add new ones. While the new version looks a bit easier to read — and overall a bit more visually appealing — the call to actions are hidden (fig. 2). For a user that wants to quickly interact with different sections this wasn’t a big improvement, if anything we made it harder to quickly interact. In comparison, the summary example above they are not wanting to edit the content or it is a rare instance that they would want to edit from a summary. In that case de-prioritizing the call to action is actually the right move.
Takeaway: Our discovery process had some room for improvement. Since we didn’t know the full scope of the tables that we changed, we didn’t fully know how to design to them since these are actually two completely different use cases. When we made these changes with dev, we just bit off more than we could chew. Historically UI changes are hard to come by on our team, so when our dev had availability to take these on we just threw everything we could at them. I still don’t think anything is broken beyond usability (every component was tested through general UAT), but I also don’t think we made significant usability improvements on the form summaries. We tried to change too much, too quickly without taking into account the full scope.
2. Don’t take it personally
Have you heard about a little thing called imposter syndrome? When feedback started rolling in on the tables I took all of it as direct attacks on my ability. Looking back, I should’ve held true to our process. I did the research, I sketched initial solutions, I tested it with users, and I iterated. It definitely was a risk to try and make this large of a change, but at the time I didn’t think it was the wrong move. I still think that we made some steps forward, and I learned a lot in the process.
No one knows the work you did unless you share it.
Takeaway: If you did the work, be confident in that. People have visceral reactions to all different types of design choices. No one knows the work you did unless you share it. If you show them the process you took to get there, prove that you did what you did based on client feedback. Then they can’t say you didn’t put in the work.
3. Have a plan
“You don’t need a parachute to skydive, you just need a parachute to skydive twice.”
After we found out the larger issue (after it had already been developed), we came up with a fix pretty quickly (fig. 3). The cards from last year was a better user experience and a better solution for forms that you want to quickly interact with. Based on that understanding we looked at what the new cards could look like, we mocked it up and went through the same process (research, test, iterate, and implement).
By the time we got ready to implement, our remaining releases for this season were full. The priorities remaining in the release out weighed just a general UI fix. We had no time to fix this before going live, so we had to go with the existing table design.
Takeaway: Going forward if necessary we should be able to quickly revert back to old versions without having to use dev time to make changes. An ideal scenario would be to have each sprint save 10–20% and reserve that for design debt. That way when we compare general UI tweaks against a larger project, these tweaks would actually stand a chance.
4. Be transparent
I won’t say I tried to hide it, but I don’t think I was as transparent as I needed to be to prepare everyone for the change. We tend to have a lot of oversight and a lot of decision makers to get UX/UI decisions approved. Historically this leads to a lot of opinions that tend to water down designs. When we show things, we need to be prepared to defend them and our thought process.
Takeaway: We felt confident we did the work, but without a working prototype built out by dev it was hard to convey the extent of the design. As I said, people don’t know the work you have done if you don’t show it. If we would’ve walked through each of these changes we could’ve caught some missed opportunities along the way and delivered a better product.
What did we actually learn?
“Don’t be too invested in your idea that you are afraid to pivot quickly”
After writing all of this and thinking about this for a while some of my ideas have changed. I came to this conclusion, don’t be too invested in your idea that you are afraid to pivot quickly. All of these learnings from one all the way to four, result in times that I should have pivoted or tweaked the design slightly.
We learn there is a new use case?
Pull that out of scope immediately to look at more in depth later.
Feedback coming in that goes against your original idea?
Do some quick testing to validate our thoughts.
Not able to pivot after development?
We wouldn’t have even needed to pivot after development if we would have followed this methodology.
The cherry on top is not being fully transparent.
I should welcomed feedback as we developed new components.
What I learned in the end after looking at a failure and trying to figure out what went wrong is that we didn’t fail fast enough. We tried to prove our concept was right that we didn’t do our due diligence to ensure it was right for our user. By being afraid to completely fail and not deliver a component we ended up delivering a flawed component.
James Jensvold is a Chicago based UX designer.
