Why agile-organized product teams become so unorganized & how you can create a better workflow
A better product development workflow: how we turned conversations into documentation
As a product designer, my workflow is incredibly messy. Files with random names, numerous docs, and I hope you never have to look at some of the Figma projects I use for brainstorming. I’ve been working at an early stage start-up (4 employees when I joined) for the past nine months. At the beginning I could be in my element, working within my own flow and making decisions quick.
However, within the last three months, our team has now grown to 15 employees. Instead of quick zoom calls or text/Slack messages to the founder and engineers, we now need to have full on meetings and longer conversations. I realized that our workflows were getting more and more unorganized — we were wasting more and more time.
So what was the problem?
Aligning everyone across platforms is just too hard…
It became harder to update both the mobile and web teams about small changes made to designs and the work it took to actually hand off designs became more and more difficult as well. We had to make countless Github issues, mention the related engineers on Slack and had a whole document of tasks written up, but even then small tasks were missed. We tried using various task boards but action items would get pushed down and ultimately all these issues caused a lot of confusion.
We thought things would get better if we organized and tracked everything on Google docs — design tasks, engineering tasks, a new doc for every new feature we wanted to design filled with thoughts from people on the team. However, this quickly became super unorganized as docs started becoming longer and harder to read. On top of that we would have various discussions over Slack, in meetings, and on Figma comments where decisions were made but later overturned in new conversations because no-one remembered these threads and what was decided. Tracking down these decisions was near impossible sometimes, and when we couldn’t find them, we had arguments over what we should do. Not a good feeling. And more wasted time.
Creating a new strategy
The “master” document
It wasn’t that we didn’t have the design bandwidth to do the real design work, but that the structure and process of our documentation was bottlenecking our ability to get stuff done.
So, I decided to think about how to mitigate these issues. At first, it was setting up a template for workflow on Figma but that just made us as designers more efficient/organized. The main issue still was making sure that engineers and our PM knew what we were working on and all the changes that occurred. I thought it would be helpful to create a master document to keep track of these things with links to Slack threads, associated Figma files, Github issues — basically if there were important things worth noting I added it to this doc and it grew incredibly long within a few weeks.
Adding organization
I thought it might be useful to do this for every major feature. Have all the Slack discussions we’ve had with the PM and engineering for feedback/scope all on one document. Then we would add more as we ideated. Then once we were ready to hand-off I put screen shots of the final designs with a link to Figma and then all the Github issues afterwards. Soon, we had fully built out documentation for all the new features we were making, composed simply of relevant events pertaining to each feature. A single log was useful, but organized logs let us scale this process.
I know, it looks rudimentary. In spite of the manual work involved, our workflow as a team was just plain faster. No referring to outdated decisions, or forgetting ones that mattered. Every discussion we had in a meeting, over Slack, or in Figma, felt like it had a tangible takeaway rather than getting lost in the mix. We’ve shipped features faster than we ever have.
Takeaways
Documentation for designs are two-fold. First, you have to document the end-result for handoff and presentation. We always do this, because that’s the only way it gets shipped. But before that, you document how you got there. Working on a team, “how you got there” changes from Slack conversations, Figma comments, meetings, ticket updates, interview notes, user test results, etc. Without this piece, it’s easy to forget many of the whys behind the design and keeping everyone aligned on those.
If you have a central place to keep all of this, it makes the chaotic product journey so much clearer. It makes handoff easier because you can prove and trace every decision back to its origin. And it makes new features easier to reason about and add, because you have the solid foundation to build on.
What documentation processes do you adopt in your product/design work? How much time do you spend doing it?
I’ve been working with my friend on a tool, Looped, that lets you aggregate all these important updates in a single place, without the onerous, manual copying, pasting, and grooming. If you’ve experienced issues like I did or want to try out a solution, we would love to chat and get your feedback on what we’re building. Fill out this form!
Or
Email: jdzheng@stanford.edu
