One of the key components of every project I’ve worked on is consensus.
I’m not talking about consensus of opinion, although that’s great if you can get it. What I’m talking about is consensus of action: What’s the problem we’re trying to solve? What did we decide to do? Why are we doing it that way?
These conversations can be tough, but they’re important. They move the project forward. They’re a big part of the design process.
As tough as the conversations can be, having them over and over again is even tougher. Sure, it’s great to refine ideas, but at a certain point, your team has to embrace the solution you’ve chosen and get to work.
Meeting notes and project managements tools help keep a record of the conversation, but often, they aren’t an effective way to quickly understand design decisions. Style guides and documentation do a better job summarizing that information, but they usually appear too late in the project to help you build whatever you’re building.
What I’ve been trying recently is something in the middle. A living, changing, useful, consensus. It will look different for each project because the consensus depends on your goals and constraints.
Here are a few examples:
After analyzing user research with a co-worker, I transferred the contents of the whiteboard we used to a Trello board. Since the team is largely remote, the Trello board became the place where we kept refining and adding to our analysis. When we showed our research to other members of the team, the board became a valuable reference point.
While designing a website for a small non-profit, I sketched out the ideas that came up during a lunch meeting. My notes included a low fidelity wireframe, a rough voice and tone guide, message hierarchy, and a preliminary information architecture. After the meeting, I snapped a photo of the pages and emailed them to the group so they could use them during the next design iteration.
For a project that involved lots of interface writing and group meetings for approval, I created a content wiki for the project. We use it to reference decisions we’ve made as a group along with some reuseable boilerplate content. Since this project involved modifying a lot of existing copy, I also used the wiki to keep a running record of every content change we’ve made.
There are a lot of different ways to keep a written record, but a record isn’t the least bit valuable if nobody sees it. That’s why it’s up to you to keep referencing it. Keep pulling it out. Keep sending the link. Keep sharing your screen and walking people through it.
What I’ve found is that over time, the team will start to internalize the design decisions. If you’ve ever felt like the only person who understands what the group should be doing, that says more about you than it does about the people you’re working with. Give them a written record, point them toward it constantly, and soon they’ll be defending design decisions right along with you.