How our small design team collaborates with developers

neXenio is a software company based in Berlin with a focus on improving today and tomorrow’s digital workplace. We create tools that help businesses collaborate in a creative, efficient and secure way. In this article, we would like to share how our design team started from a small inexperienced team working on a day to day basis to a better organized and more confident team. Especially, we would like to share how designers learned to communicate and to work seamlessly with the developers.

As one of the first designer in a Software company surrounded by many developers, you might experience discouraging challenges. With a little work though, you might become able to overcome your daily problems and improve your collaboration with the developers.

For example, you might be frustrated by the following:

• The designers’ work is commonly considered as aesthetics and therefore, you are almost constantly asked to make things “pretty”, only after they’ve already been built.
• You have too many stakeholders so you are overwhelmed with external requests like “Can you quickly send designs for feature X” or “Please create an umbrella icon in orange”.
• Because there is less time for structuring and organizing, your work becomes unstructured and your files messy.

These frustrations are normal and part of reality. In the early years of neXenio, our small team of designers was mainly composed of interface design students working halftime. Each of us had their own study schedule and activities outside of work. Therefore, our time was scarce and precious.

In order for us to become more effective, consistent in what we do and up to date with the developers (ideally even ahead of them), we took the time in order to improve our designer-to-developers-communication and -workflow.

Designer-to-developer communication

When developers take care of implementing a feature, it is essential that they understand the intentions behind the user story, the designs, the process the users go through, their experience, etc. Just sending them a rough note and a JPGs isn’t enough.

To make sure we don’t miss opportunities to discuss things between developers and designers, we use weekly meetings called Jour Fixe. During the meeting, we discuss upcoming, ongoing and completed topics. We make sure these meetings are concise (30 minutes max) and focus only on high priority tasks. We try to clarify directly what should be improved right away and schedule tasks that will be done in our normal schedule — and very important — we dismiss ideas not worth pursuing.

In our experience, the Jour Fixes are pretty efficient. They help developers and designers to remain aware of each others’ schedules and ongoing tasks and to prioritize more tactically.

Designer-to-developer workflow

While communicating on a regular basis helps, it isn’t possible for us to discuss every change and requirement. It is necessary for us to be able to follow the ongoing progress of either designers or developers at any time without leaving our work desk. This is where our custom workflow comes into play.

The designer workflow consists of a set of rules that enables us to organize ourselves, to improve our productivity and to work in the same way, thus warranting high-quality standards. It is inspired by the developers’ Agile workflow with ease of collaboration in mind.

We use an adapted version of the Kanban process in order to visualize and organize our work. We use JIRA, a project management tool, to configure our Kanban board. As noticed in our Jour Fixe meetings, our tasks can be categorized by their urgency in three groups, each of which we configured as a horizontal lane:

• Blockers are tasks that need direct involvement and that are started even if other tasks are currently in progress. These are rare and to be avoided. This might happen if we want to catch a promising customer opportunity or if we misunderstood each other’s expectations on an urgent issue.
• Long term tasks are the main tasks that make the products better in the long run. They are usually planned long in advance and may contain multiple polishing loops.
• Short term tasks, on the other hand, are tasks that would never be made if we waited for the long tasks to be finished first. Their priority is too low to become blockers but we still don’t want to eliminate them because they still make sense, though only if we start them soon. We only use a max. 20% of our time on those tasks. That way, we don’t lose ourselves investing too much time in them and ensure that the more important long term tasks are worked on. These tasks are essential to our collaboration with developers, as they give us an opportunity to address urgent and small design requirements for developers to work with.

Using this categorization helps us to confidently distribute the right amount of attention on different tasks. It serves as a general prioritization. Inside these lanes, each task is visually prioritized among others.

To visualize the progress of each task, we use the following columns:

• Waiting:
  When tasks depend on external factors and cannot be worked on, the task is moved to waiting.
• Open:
  Upcoming tasks that are waiting to be started are placed in this column. The other, more distant tasks are placed in a Backlog.
• Progress:
  One important part of the designer’s progress is to get input, feedback, and reviews from everyone involved, especially from the developers. Together, we discuss topics like implementation details, how to provide additional information that will help the developers later on, if we need to split up the task into various developer task and in which order to implement the features. Tickets remain in the progress column as long as actively worked on.
• To Review:
  Every task has to get reviewed by at least one other designer. As soon as a task is ready to be reviewed, it gets moved into this column. Like Kanban, we consider reviewable tasks as impediments. We think it is really important to get reviewable tasks out the way rapidly. That way, the developers can start working on them as quickly as possible. Consequently, the designer team feels more productive when tasks are moving to the done column!
• Reviewed:
  The reviewed column indicates to the task’s assignee that her/his task has been reviewed and can either be moved to done or put back into progress.
• Done:
  The task has been reviewed and was handed over to the developers!

The developer team uses Scrum with 2 weeks sprints and configured their workflow in their own way. Their way does not always work with ours. They don’t define their tasks in the same way and don’t focus on the same aspects as we do. To make sure we have a compatible workflow, we create design- and developer-tasks around the same goals or features separately. Ideally, we first do the design-task focusing on the user experience. Once done, one or many developer-tasks might emerge from it. In many cases, a developer-task already exists and so design-tasks are created to ensure that, for instance, the newly created feature does indeed look and work in favor of the end-user.

In order to make sure that these tasks are linked together we use JIRA’s linking feature. We also configured custom fields on developer-tickets to indicate whether designs are needed, already available or waited upon. Additionally, we comment on each other’s ticket in order to communicate the location of the design files, give a small textual design input, discuss the scope or intention of this task very often.

Impact

Back then, we used to work on whatever was required from us on a day to day basis. Started tasks were often abandoned in favor of the newest most important ones. Each designer worked her/his own way and the result was a potpourri of ways and flavors. Developers, designers, and other stakeholders would run back and forth to one another to gather information while forgetting midway what the main goal was about. In short, it was ineffective and the quality suffered.

Using a balance of good communication skills and a well-adapted workflow, we were able to improve the work of both designers and developers. We became more productive, confident, consistent and our work’s quality increased.

Each of us knows where to catch up with ongoing work and knows exactly what others (developers included) are working on. Now, User Stories are designed before being developed thus avoiding unnecessarily doing the same twice. Most importantly, we gained the trust of each other, which increased our motivation to work together and to do things right.

We still face many challenges every day and there is definitively a room for improvement. Yet we started with a non-optimal situation in which design had only a little importance and transitioned together, as the whole neXenio-team, to a state where design is valued a little more every day.

Thank you for taking the time to read. If you share similar challenges, please share them with us and tell us what solutions you came up with. If you liked this article or have some thoughts, let us know in the comments, give us a clap or say hello at info@nexenio.com.

PS: We are currently hiring designers to strengthen our team and to integrate design into our culture even further. If you want to join our team and help us grow, apply at jobs@nexenio.com.