Intentional failure as a workflow
We’ve all been there, designers counterproductively curating Lorem ipsum; developers swearing under their breath at yet another incoming change; project managers writing the same email for the third time that day begging for feedback — with no response and a looming deadline, the client silently remains the only blocker on the board and the project is not moving forward.
How do you unblock this problem? Well, here’s my working approach.
I’m sure you’re familiar with “fail early, fail often but fail always forward” by John C. Maxwell. The concept’s simple: getting things wrong can (and should) be a good thing. More specifically, it’s an approach that we can utilise to engage with unresponsive stakeholders and clients to get results.
Before I go any further I should clarify upfront, to clients specifically: This approach has your best interests at heart. Ultimately it’s about getting your input before it’s too late so that we can create the product that you need and hired us to create.
So…how do you fail early and safely to avoid real failure in the future?
Failing with purpose
In my experience, stakeholders and clients tend to get caught up on the small things. Try as you might, it can be impossible to get them to focus on the areas where you need their input. You can repeatedly explain it’s just a wireframe or mockup and not the final design, and that they should be focusing on the more important aspects, specifically what the meeting has been set up for instead of chasing butterflies. But that rarely happens or instead, you end up with an incomplete; copy paste bullet point mess from an email trail that‘s been passed around more than a bug card on a sprint board.
This is where you put your master plan into action; use the information gathered so far, however minimal it may be; use what content you can on the screen, change up the order, repeat content if needed to fill the page or add some of your own additional bits that they might not have considered that could add value to the project — just the normal design process so far, but here’s the most important part: plan to fail. Don’t just follow the requirements as laid out by the client exactly, question the reason, the need.
Create the screen as the client thinks they want it, but change it. Make the screens different enough from their expectations to start the conversation: “Why did you create the screen like this?”. With luck, the conversation will lead to them questioning their motivation and reasonings for their choices and reveal the real understanding behind the content that they were proposing. By having the client start asking the question of ‘why’ and getting them more involved is how you show your real value and expertise while getting the input or feedback you need.
This approach can work wonders, especially when implemented early in a project timeline, to the point where you might want to consider creating a rough concept as early as the first briefing just to have an idea on the table and getting people to ask the right questions.
Intentionally failing to deliver what the client expected, and with the correct approach to get them more involved, you can kickstart the progress and get the project moving forward in no time!
Final thoughts
Obviously, failing isn’t ideal but failing with the intention to deliver something that will get the client to ask the right questions themselves and get involved, can produce results that prevent real failure. It’s a workflow I’ve used quite a few times to get the feedback I need externally — and internally. And has become a reliable tactic during my design process. All thanks to previous projects where we battled received the necessary feedback and input we desperately needed upfront to finish a project.
To those clients: Thank you for helping us fail forward.
