The start of development has always been a challenge for me, because explaining UX work to developers is hard.
Traditionally, I’d walk everyone through a prototype, summarize a roadmap, explain features, and more. And once I finished going through all of that, I’d still get a lot of questions about the app—and then a ton of follow-up questions.
At 10Clouds, our flow from the designer (me) to our developers was inefficient. We needed a new approach. And I needed to figure out how to effectively communicate with the team without extensive documentation on my end.
Related: 3 ways to improve collaboration between designers and developers
Keeping it lean
Image from Inside Design: Betterment
Some techniques exist, such as use cases, sitemaps, and task flows. They’re designed to help, but it would be best to use a couple of them for proper documentation. And, honestly, it’s hard to update them in an agile environment.
Lean UX is against extensive documentation because team collaboration should be at the center. The problem happens if you rely only on mockups—you’ll end up explaining the same things over and over again.
“Flow helps maintain consistency in design and speed up development.”
If you want to invest time into an artifact, it should engage the whole team
by improving communication and keeping everyone on the same page.
Flow redesigned
I needed a new tool to help our team flow stay lean, agile, and effective. I started by writing down the things I needed to communicate, looking to outline the project without getting into too many details.
Then I created a flow diagram as a base, and started mapping the key views. Only then did I move on to adding details: drawing mockups, testing different fidelities, writing down features and listing the data to show.
Here’s the finished flow:
This version just felt right. I shared the flow with our developers and braced for an extensive Q-and-A. Instead, they got it right away—we all felt awesome about it, and it’s worked wonders for us.
Designing in flows
So what makes this flow work so well?
Designers focus on users, but in a team environment, the system perspective is just as important. Developers usually have to imagine the whole system before they can start planning their work. They need to know how big the app is, how complex the views are, and what can be reused.
Typically, all of that has to happen before you start prototyping.
“Designers focus on users, but developers need a system perspective.”
There are a few things that can help a team deal with it:
- A low-fidelity representation of each view shows its complexity. Will there be a grid view? A table? Are there any tabs? You can present all that with a simple sketch. At this point, it will be enough to decide if the design is going to take the whole sprint to implement, or just a small part of it.
- List all information that will be visible on the screen. The data you show affects the database structure, filters, and search criteria you can use. It’s much easier for the team to imagine the desired outcome of their work if you list everything at the outset.
- Annotate arrows to explain the navigation. Links between views are another crucial element of the flow. Arrows help you show the structure of the app. Annotating them also describes which features will be available.
Even though I focused on developers, this diagram supports the whole team. Project management can see where the team is in the process, and UI designers know how much work they have left.
Oh, and did I mention that UX work is much easier, too? No more missing links or forgotten views.
Image from Inside Design: TED
Wrapping up
The flow diagram has become a standard approach for me when communicating with the team.
And it’s not only about communication. Flow helps maintain consistency in design and speed up development. It’s an essential part of the entire design process at my company—and maybe it could also help yours!
Read more posts about team communication
Kamil is a UX Designer at 10Clouds.
