This post is the first in a two-part series on this topic.
This past weekend, I had the pleasure of speaking at the 2017 UXDC Conference, where I revisited a topic I’ve spoken about before: communicating the need for human-centered design to non-designers and stakeholders, with the clickbaity title of For Human-Centered Design, Just Look In Your Bathroom. I originally spoke on a version of this topic at the UNC + Knight Lab’s Media Workshop back in May 2016, when the inspiration first hit (with many thanks to Steven King, John Clark, Sara Peach, Laura Cochran, Matt Sheehan, and Dean Haddock for the support), and since then, I’ve iterated on it by incorporating the most successful teaching methods I use for teaching adult learners in my work as an Instructor at General Assembly. In short, the key takeaways are some strategies for us designers to use to conquer the hurdle of communicating why our work matters and how to better set ourselves up for success.
In long, my strategy is based around the critical communication of the message that experience designers do not just make things look pretty. Rather, we build solutions to solve for fundamental human needs. We in the field know this to be true, but the adversity our designs face in the stakeholder review phase is often exaggerated when we don’t establish the proper context for our designs and the problems they solve up-front. By contextualizing our work through analogies and metaphors, we can seamlessly level-set expectations and utilities going forward. (For more on setting stakeholder expectations, see my post on How We Use a Pre-Discovery Phase To Set Our Projects Up For Success.)
In my time as a UX designer, I’ve worked on mobile and emerging platforms, experimental stuff, microinteractions, and some very straightforward things like responsive websites. I’ve gotten to tinker and incubate on high-level conceptual stuff that may or may not ever make it out into the world, and I’ve also been a part of the powerful problem-solving process, where we turn user needs into something tangible and measured. In each of these projects, the constraints were really different, based on devices, deadlines, challenges of the internal politics, and ultimately the product decision-making process. The biggest lessons have come from the similarities in projects that appear completely different in statement of work.
Going into all these projects, in agency life and in-house, I’ve noticed that the team habits are similar, even when the team dynamics are new. As a team, we’d go into the project with the same high expectations for our work, regardless of constraints, device, budget, timeline, or platform, and somewhere, along the way, the project evolved and compromises were made. The end result was often this weird amalgamation of concessions.
While that’s expected and encouraged among internal teams who really want to challenge each other to build the best product, what I’ve noticed is that a lot of the product compromises we found ourselves making were actually just trade-offs for stakeholders, based on a lack of general context about the design in some way. The traditional product cycle we ascribe to, based around research, prototyping, and testing, is a mere aspirational philosophy.
The real product cycle typically goes like this:
1. The A-Ha! Phase
This is where the ideation happens and a killer concept hits. “A-ha!” I think, “If we can just do it this way, we’ll really be on the right track.” Of course there is no “A-ha!” stroke of genius in product design, but there is a crucial moment of passion and excitement at the spark of a concept.
2. The Documentation Phase
This is the part where we build/prototype/mock/spec or craft a memo detailing the idea in The A-Ha! Phase, and we work furiously from all the momentum we built up at the thought of it taking form. Again, I’m generalizing here, because this process varies from team to team and goal to goal, but this phase comprises the transcribing of the idea from brain to formal documentation.
3. The Ta-Da! Phase
This is the phase where the prototype/mock/memo gets presented to someone important up the chain, or to the core stakeholder group, and it’s our chance to really wow them with our concept. It’s the song and dance routine round needed to communicate the design, with the hope that we put on such a good show that we communicate its ROI enough to put it above all other priorities in the queue.
4. The Deliberation Phase
This is the phase where the stakeholders incubate on their thoughts and try to really understand the work we did. This usually means that you are not present and the group is left to review the document you’ve presented without you. In short, it feels like there’s a jury conversing about your work in a room that you are not in.
5. The Revision Phase
After the deliberation phase come the revisions, sometimes solely connoted via bulleted list in an email, on Basecamp, or red-lined on the work itself. In this phase, we must account for the considerations from high-level stakeholders, whose feedback often negates the UX process entirely, whether or not they’re even aware of it. This sometimes takes us back to step 4 before proceeding.
6. The Swirl phase
This is what happens when the deliberation and revision phases come with perpetual struggles and scope creep. Stakeholders change, the project needs change, the bureaucracy changes, the expectations change, and somewhere in there, when you add stakeholders — especially later in the game or secondarily — some part of the goal changes, which ultimately changes the output of the product. Hopefully, the changes that arise in this phase are for the better, but the reality is that without providing the same context for each stakeholder, each time the product is being represented, the product mission changes, and often it dilutes the end result. This typically brings about Step 7, Launch, but in some cases, the product, and all those UX decisions that were once your labors of love, they get lost and stuck forever in the perpetual swirl.
7. The Launch phase
This is the phase when the product is out the door, and there is a wave of relief/terror/excitement that fills the air.
To help move through these phases more efficiently and mitigate design concessions, I use analogies to contextualize the utility of human-centered design when advocating for my work to those who aren’t designers. Per Wikipedia, an analogy is “A cognitive process of transferring information or meaning from a particular subject (the analogue or source) to another (the target), or a linguistic expression corresponding to such a process.” The human brain looks for familiar patterns to make sense of the information it consumes in daily life, and so just like we map out the affordance patterns in page-level UI, we must map out an affordance pattern when communicating our work.
The great thing about analogies is that they’re polite, friendly, and familiar to all audiences. They’re not pejorative; they don’t require you to state the obvious. They don’t condescend. They make complex, nebulous concepts into very familiar mental models. Particularly with regard to communicating the utility of technological concepts, analogies are an equalizer.
In the world of adult education, analogies are heavily used as a device to further contextualize complex material. When teaching, I’ve found analogies to be my most-effective tool for immediate contextualization and simplification of complicated processes. In fact, the Sideways Dictionary was recently launched by The Washington Post & Jigsaw to help people problem-solve and simplify the intricacies of technology concepts. (Use it & contribute to it here.)
Then there’s the age-old (or web-old?) house analogy, in which we identify specific team roles by the phases of building a house: the UX designer is the architect, crafting the blueprints for the foundation, the front-end developer is the contractor, brought in to frame the walls and build the structure, the visual designer is the interior decorator, carefully staging the furniture. There is nothing wrong with a platitude if it helps you more easily communicate your intentions as a designer. Effectively communicating our design goals is the best way to get buy-in and to ensure that we as designers are owning the feedback conversation and ensure transparency in the product process. If nothing else, it can help us bridge the gap between the traditional product cycle and the real product cycle.
Be sure to check out Part 2 of this series.
