Helping designers and developers collaborate.

The Project

For this project, completed as part of DesignLab's UX Academy capstone projects, over the course of three weeks I designed a working design prototype as a minimum viable product to test out concepts and functionality.

The application is called FlowFirst - a user flow map collaboration tool.

My idea is that designers would be able to create user flow maps using this application, and it will provide collaborators a way to step through the flow and ask questions or give feedback.

For the MVP, I designed just the step-through and collaboration tools to begin with.

In the fully built version of this application, there would be a way to upload or create user flow maps, but for this initial viable product, I wanted to focus on the collaboration functionality to test its usefulness.

The design prototype consists of a set of screens showing how step-throughs and commenting work on an example user flow map.

Research, design and usability testing work was performed solely by myself.


Smooth designer/developer collaboration is crucial for effective and efficient product development.

As a former software engineer myself, I wanted to design something that would help with collaboration between designers and developers, specifically focusing on one part of the design process - user flow mapping.

Example user flow map
A section of an example user flow map.

My hypothesis is that user flow maps are tools that are useful to both designers and developers. They help focus designs around user journeys, and provide a step-by-step visualization of product behavior.


Online research and user interviews were conducted with the purpose of answering the following guiding question:

How might we improve collaboration between designers and developers at an early stage in the design process?

Preliminary research was conducted among articles published online regarding designer/developer collaboration.

Key snippets:

...By the time the development team is provided with the various handoff documents, the message isn’t quite the same, and they must interpret any specs they receive. Context is lost, and intent is often misinterpreted. The end result is often a set of features that don’t fully serve their intended purpose...”

“Designers who rely on over-specifying their work, without working through potential edge cases or limitations often find themselves frustrated...”

...Harish Narayan agrees: “Designers and developers need to communicate and share work early and often. It’s best to elicit as much feedback from developers and consider platform constraints as early as possible to reduce misconceptions or gaps in understanding.”
"...The reality is that we should be thinking less about screens, and more about features — and features happen mostly behind the screen.

The real challenge starts when developers start poking around and asking questions about our designs, and when quality assurance analysts start thinking about use cases we couldn’t foresee...That’s the moment of truth: the point where most teams can draw the line between good and great designers."
"Digital design is a living, breathing thing that evolves over time...Ideally, you want everyone working together from the start of the project. It’s a much more iterative and enjoyable way of working."

User interviews were also conducted among a random group of developers and designers.

The interviews were conversational, with questions focused around understanding the way they interacted day-to-day, some of the common issues they faced when interacting, as well as ways they overcame those issues.

Key summaries from interviews:

  • While all participants stated that they generally had a smooth collaboration process, most participants could still note at least a few times when they had delays as a result of miscommunicated requirements, technical and otherwise.
  • All design-focused participants noted that they found it helpful in mitigating such issues to involve developers in early design meetings, as they often had technical knowledge that allowed them to identify issues early on in the process.
  • Development participants I talked to also said they appreciated being included in the design process, as it helped them gain more context for what they were building, more than just screenshots or design systems.

Defining the Design

Both preliminary research and user interview results seem to affirm that user flow maps could be a good early design entity for designers and developers to collaborate around.

They strike a balance between specificity in intent and flexibility in implementation, are easy to update based on feedback, and give developers a better context as to the ultimate goal of their product.

Design should emphasize collaborative functionality, encouraging detail and granularity without becoming restrictive, and being easy to understand and use for both designers and developers.

I created dual personas, representing a pair of collaborating designers/developers, to focus my design around:

Dual User Personas

There are numerous methods of drawing up user flow maps, but to give more detailed structure to the maps in my application, I decided to define four kinds of nodes that could be used in flows:

  • Start and end nodes, which define the beginning and the end of the user journey being described.
  • Page nodes, which describe an application location the user might find themselves in, and the actions they can take from that location.
  • Decision nodes, which describe a decision the user would be making, usually couched as a yes/no question.
  • Action nodes, which describe an action the user would take to get to the next step or location.

Each node would allow the user to focus or zoom in on them, and open up more detailed information about the node, as well as commenting and other collaborative functionality. One would also be able to step through the flow from any node to subsequent connecting nodes.

From Wireframes to Design Prototypes

As previously mentioned, for the purpose of creating an MVP to test the application idea, I focused specifically on designing out the step-through and collaboration functionality.

In the full application, there would be a way of creating/uploading user flow maps, but for these designs, I used an already created one to build the functionality around.

I designed my initial wireframes mobile-first, for a more focused and efficient design:

Wireframe - Top Level
Top-level view of the flow.
The start node.
A decision node.
A page node.
A page node w/ comments.
An action node.
Wireframe - Start NodeWireframe - Decision NodeWireframe - Action NodeWireframe - Page NodeWireframe - Comments

I then moved to a more desktop-friendly design, building a working Figma prototype.

Top-level view of the flow.
The start node.
A decision node.
A page node.
A page node w/ comments section.
An action node.
Design - Top LevelDesign - Start NodeDesign - Decision NodeDesign - Action NodeDesign - Page NodeDesign - Comments

Usability Testing

Usability testing was conducted with the objective of answering the following guiding questions:

  • Are both designers and developers able to understand and use the interface?
  • Do both designers and developers find the interface a useful tool that helps them ask interesting questions and generate useful feedback?

Tests were conducted separately with a developer participant and several designer participants, with the tests tailored to each role.

The methodology for each test was as follows:

  1. Start the participant on the Figma prototype. The prototype contained an example user flow map that was deliberately set up to be over-simplified and missing important details, to prompt question and feedback.
  2. Both designer and developer participants are asked to go walk through the flow, and asked if they understood the flow and how to use the interface to navigate it.
  3. (For developer participants) The following questions were asked:
    - What questions would you ask the designer of this flow?
    - What missing use cases or ambiguous interactions would you need clarification on?
    - What new nodes or steps, if any, would you suggest?
  4. (For designer participants) The following questions were asked:
    - What questions would you have for either the designer of this flow or a collaborating developer?
    - Do you have any suggestions for how the flow could be improved?
    - Are the way the nodes set up in this flow overly specific or restrictive?
    - Here are some suggestions developers came up with (and here we supply the suggestions received from the developer in their test) - would you find these suggestions welcome or helpful?
  5. Both designers and developers should be asked how useful they would find an application of this sort.

Usability Testing Results

Both designer and developer participants reported that the flow was understandable, and the interface intuitive and usable for stepping through it.

The developer participant was able to identify the locations in the flow that had ambiguous or missing details, and even suggest new nodes and pages in the flow. He noted that he found it an interesting experience to view one of these user flows, and he appreciates the higher-level overview of an application given by the flow.

Though the designer participants had some feedback as to flow clarity and commenting and collaborative functionality, on the whole they responded positively to the way the nodes were laid out and structured, and thought they struck a good balance between detail and flexibility in their requirements.

They also responded positively to developer suggestions, saying that they were welcome and they would be open to suggestions to update and flesh out the flow.

They did suggest, however, that they might not wish for developers to have the ability to directly edit the flow, but otherwise collaborative suggestions would be helpful.

Iterating on the Design

Link to Prototype, showing iterated designs.

Iterations consisted mostly of improving navigation and affordance, and fleshing out the commenting functionality.

Next Steps and Thoughts

Given more time, I would have liked to build out the other important parts of the application, namely user/collaborator profiles and flow creation.

In particular flow creation would likely be complex enough to almost be a separate project in itself, with distinct use cases and user journeys.

Though I had some difficulties getting enough developer/designer participants for research and testing, I was pleased to see that indications are that both sides of the development process would find this application to be a useful tool.

I myself would love to have had more interaction with the early design process when I was a software engineer, and I am happy to be able to work on something that could potentially be personally useful to me and my peers.

Grant Q. He
grhe@grantqh.comLinkedIn Icon