Bringing order to chaos
Managing information overload in a complex product design project
With a great project comes a lot of information
Not too long after I joined my current team, we started a huge redesign project. We were rebuilding the heart of our product. Our infrastructure had become so obsolete that we had to start from scratch. That was good news. As a designer, I had many times wished to toss out all the hastily developed features and the not-fully-thought-out interactions in many products I worked on. This time, the technical limitations would not hold me back. I finally had a blank canvas and infinite possibilities.
I knew it wasn’t going to be easy. The scope of the project was huge and I had to take into consideration the many stages of availability (alpha, beta, etc.) to create solutions that worked at all times. I had to focus on figuring out the process to follow, the research to be done, the deliverables to be submitted and most importantly managing the amount of work. What I did not foresee was the volume of information that a team collaborating on such a complex project would produce.
Creative minds are rarely tidy
As in most design projects, I started with a divergent approach, learning about users and their goals, finding problems, looking at competitors, and sketching by myself and with other stakeholders. There was already a lot of information going around, but most of it would be consumed by me, so organizing it in a way that made sense was not a big deal.
When we started the implementation work, things became more challenging. The one-on-one syncs with developers and the product manager felt like the wrong approach to take. Links to assets hosted on different tools and shared through all kinds of media started to get lost. Our brains were definitely not a reliable source to track the decisions along the way. I needed a better way to effectively exchange information with the team, a systematic approach to make sense of it all.
Thinking in systems
It was time to put on my information architect hat and decide how we should document, organize and share the information that was most relevant to our work. Taking advantage of the tools that were already at our disposal seemed like a logical first step. However, incorporating new elements into our work routine would not be enough. We needed a system.
“A good system shortens the road to the goal” (Orison Swett Marden)
Our fragmented pieces of information had to work together, be connected. As we adopted new tools (“places” or “objects”) to address newly emerged needs, I would define rules for using them. Simply put, I used a grouping and categorization exercise to establish that some “objects” belonged to a specific “place”.
If this all sounds too abstract, here are some examples of the tools I adopted, the needs they addressed and the rules I created.
a. Weekly meetings
Communicating with developers in isolation was highly ineffective in a project with so many dependencies and intricacies. We needed to align the team around the proposed designs, discuss the requirements and technical limitations, and make some decisions. Our weekly meetings became the primary space for presenting new designs, sketching ideas, and discussing challenges.
b. Group chat channel
As we moved forward with the implementation, we also needed to make some decisions more quickly while still keeping everyone in the loop. For ad-hoc discussions that could not wait until the next meeting, we created a dedicated group chat channel. Discussions that turned out longer than expected would be moved to the weekly meeting. I also used this channel to announce when new specs were ready for review.
c. Kanban board
As with any large project, timing was critical. Getting the specs done in time for developers to pick them up on upcoming sprints was one of the product manager’s main concerns. To add transparency to my workflow, I created a Kanban board where I organized my items into three columns: to do, in progress and done. To each item, I would add a short description, the priority level, and a link to the specs.
d. Project wiki page
As the amount of design specs multiplied, it became increasingly hard to find links that had been shared in the past. Icons were also spread out across several development tickets and some details of the process were forgotten on sparse wiki pages. We needed a master source for all these elements. A wiki page was the obvious solution. It worked as a home page where both team members and other employees could easily navigate to find general information, links to specs hosted in other tools or wiki pages in the same tool, and downloadable icons.
Takeaways
Intentional vs. accidental communication
You may be thinking, “I’ve used most or all of the tools above. What’s new?”
You are right, there is nothing very new about this. However, designers are often so focused on the content of their specs that they might forget to think about how they deliver their design documentation. In that case, they may end up with an accidental organization pattern that may confuse, distract, or annoy people rather than support them to do their best work. That’s why it’s important to think about organizing your work and documentation, and setting your coworkers up for success, as a separate and critical part of your project. Creating explicit rules to connect the fragmented pieces of information into a system for internal use may not be so common to product teams.
Your team members are also your users
One of our core values at SurveyMonkey is “listen to customers” and we usually think about them as the ultimate users of our designs. However, if we empathize and think of our team members as users of our deliverables we can help improve collaboration. Listening to their needs and trying to understand how we can make their lives easier is not optional work. It is a critical part of a designer’s work and we need to do it with the same attention that we dispense to our designs. The best designs in the world, if not communicated efficiently, may remain just drawings. Having an engaged team significantly increases the chances of our designs being understood and accurately implemented.
There is no one-size-fits-all solution
That goes without saying. Each project and team will have different needs. For example, my team on this project was located in the same office. Remote teams may need more robust systems to guarantee that information does not get misinterpreted or lost. Needs also change depending on the project stage. Being attentive to the signs that new issues should be addressed is important. When in doubt, ask your team members, they may give you great insight into what can work best for them.
To be honest, creating this system was a lot of manual work! It was definitely the right thing to do and I’m confident that it has significantly improved the quality of our final product. But the fragmented nature of the tools that we use in our daily work doesn’t make it easy for us to create these connected structures. On the contrary, they impose barriers that are very hard to break. My hope is that in the future, applications make this work easier so that we can focus more on fixing other complex design problems.
