Improving collaboration through organised work
How can designs be organised to improve collaboration between designers and developers? A look into the file structure I created to improve ways of working for a cross-functional team.

What I worked on

  • Design Ops
  • Information Architecture
  • Design System
  • Documentation

The results

  • Defined clear workflows to decrease designer to developer handoff time.
  • Increased visibility of designs across all business areas and enhanced support for design decisions.
  • Created scalable components to ensure consistency across products.
  • Demonstrated iterative change in our designs for research and development funding.
Helping design and engineering work better together so we can tackle bigger problems.

Questions like “Where’s the latest design?” were being asked too often, especially in our fast-paced environment. The aim wasn’t to implement rigid processes or limit creativity, but instead help the team achieve their goals faster with less frustration (and fewer meetings!).

The Product
Balancing visibility, effort and speed with the team’s ways of working.

When designing the workflow, some important factors were anticipated:

  • People naturally prioritise speed
  • Structure can be interpreted in different ways
  • The way the files were set up would integrate with the existing processes of engineers and other business areas, guiding people’s understanding of how to access designs.

For a new design-to-engineering workflow to be successfully adopted, the team’s needs and preferences had to be taken into consideration.

We need a system that is easy to use, allows for quick iterations, and maintains our brand consistency across platforms.

A strong foundation is the key to building anything that lasts, so to help guide my thinking some core ideas were established:

  • Files should be clearly named and located, so there is organic exposure to relevant work and no hunting around.
  • Files should have the ability to scale with each product.
  • People should be empowered to work autonomously and deviate from the recommendations - one size does not necessarily fit all.
Information architecture

Each product became a project, and within those projects were files representing each feature, each with pages showing different flows. As we closed in on a solution, work was organised into these central areas to document decisions.

File templates

To demonstrate how the structure worked, I migrated our existing design files into the new structure, created a template file for future use, and scheduled a walkthrough to discuss how we would prepare for developer handoff.

The beginnings of a design system

Our designs were always evolving as screens were updated and components adapted to new forms - this showed our commitment to continuously improving a unified product. With the ability to reference a ‘source of truth’ for each product, we could iterate quickly without risking changes to the foundational library. There was no chance of 'looking at the wrong thing' because there was only one place to look.

In practice

The new structure has been in place for 3 months now, and it’s going well so far. The design team and engineers have for the most part followed the system, and people are collaborating across different business areas instead of keeping work hidden within their own circles. I believe this will achieve the impact we aimed for, and it will continue to be refined as we receive feedback.