Ambiguity can still be helpful in a not so agile environment

My last gig was way more agile than what I’m navigating at the moment. Previously, my team was highly collaborative (maybe too much so?) wherein I had a continuous stream of conversations with a fearless, entrepreneurial front end developer and a I-don’t-do-work-that-looks-like-crap UI designer which lessened the need for UX documentation in my deliverables.

I was able to spend more of my energy on strategy and intent, and I could produce a more robust framework of problem statements that ignited the rest of the team’s imagination. I also had more space to coach and facilitate the adoption of customer empathy. In some ways it was a dream team and I do miss it. But I don’t want to get into which production philosophy is better, partly because I don’t want to look like I’m making excuses or complaining about the way things are done. I’ve instead gone with a surrender and embrace approach. I’m studying the art of writing a design spec.

Writing design specs is arduous even for those who really like to do it, so one thing to keep in mind is when to actually start spec’ing. Partly because if you start too soon, you’re days are spent updating your spec in reaction to the reality of decision making – things change, you get smarter, your blind spots become more and more painfully obvious, not to mention the twists and turns coming down from VIP stakeholders.

This environment seems like the most inappropriate place for ambiguity, right? Well… it can be a way to get closer to the truth by drawing people into your design process. The draw mechanism is realized by not having it all figured out, leaving some holes, presenting some ambiguity, giving others the opportunity to point out the errors, omissions and oversight.

While ambiguity can be useful in this way, the drawback is that people could make you feel like you didn’t finish or you didn’t think of EVERYTHING – because their frame of mind is less than agile. So your ego might take a hit, but getting others to start filling in the missing gaps is key in this approach. This not only facilitates decision making, but co-ownership is encouraged amongst your stakeholders and peers. Often times they opt in by virtue of their strong opinions and self-expression.

You may feel a twinge of discomfort because you don’t have all the answers. Certain personalities might call attention to the fact that things don’t feel ‘done’, making you feel even more vulnerable, but if you can ultimately land the plane without sinking precious time into spec writing, then in my opinion you’ve accomplished your goal. The goal stated is to spend more time building intent on behalf of the customer’s experience and less time moving pixels around and updating wiki pages.

Here’s my current check list for this particular less than agile environment:

First round: get some general concepts in front of your fellow designers and Product Manager (PM) for feedback which looks like

• A rough task list: this is just a quick, almost messy, list of words, phrases and placeholders that convey all the things that the user can do, should do and should not be able to do

• Empathy check: collect any existing user research data, quantitative or qualitative; account for user research planning if applicable

• Low fidelity visualization: high level, low-fi sketches and visual aides

• A straw-man: work out a structure that organizes the design and categorizes the intent of the design (wikis are good for this); include any rough planning for customer engagement or testing

• Prepare for mocks: start identifying and collecting patterns, styles, color palettes and font icons, and possibly a plan for the hierarchy of and naming conventions for your mocks

Second round: you now have refined concepts based on the PM’s feedback, but you’ve also consulted engineering for a sanity check and to gauge feasibility

• Design as a story: you’ve got a more cohesive design narrative now; you can more or less explain the work to anyone (product, dev, and VIP stakeholders)

• Phase 1 mocks: you’re armed with a prototype and story arc that’s available on the wiki

• Customer empathy: include any user evidence that can help inform design or product decision making

Third  round: shit’s getting real now; refine with a sense of convergence and commitment; your PM, as the final decision maker, should help get things in order so you can start locking things in

• Phase 2 mocks: get your design file ready to scale, assign symbols and clean up from your messy exploration

• The lagging prototype: usually the prototype can get out of date at this point; while it’s helped you get this far and it’s still an integral reference, the design spec is now taking over as the primary instrument of communication

Fourth round: it’s now time to start writing the design specification, albeit you’ve got alot of the thinking and documentation already in place, but you’ve held off to a point where hopefully the amount of time you spend actually spec’ing i.e. finalizing the thing has lessened

• Update the status: remove the ‘Draft UX Design Spec’ tag from the spec, and publish it as ‘done’

• Jira ticket: use the Jira ticket going forward to capture any variances, answer questions or add clarity and mostly let the design spec serve as the historical artifact

Because ambiguity leaves gaps in which to have conversations, it forces an agile philosophy without folks even knowing it. Conversations build tribal knowledge and therefore your specs are no longer as integral to the design, they’re lighter and serve only to remind us of what we talked about. Additionally, this standard of documentation is especially important if your organization measures your progress based on the degree in which you’ve documented it. Specs can also be crucial if the team is used to dialing in the design during the QA process.

I’m still learning and adjusting, so let’s see how this works out for me. By the way, as I finish these thoughts Friday evening over my favorite Old Fashioned I see this on the Liquid Bread menu. It seems fitting. Is it possible to gain some grey hairs and lose a few years at the same time?

You’re only as young as the last time you changed your mind.
– Liquid Bread bar menu