If you want to build a product, you can’t do it by yourself. You need a hard-working and fully devoted team. Unfortunately, sometimes there are tensions and misunderstandings between members. It’s important to know how to deal with them and help people with their workflow. I will look closer at the relationship between UX designers and developers. What can we do to improve this cooperation, how can we build understanding, and what are the profits for business and product?
Every designer should know that no design can be done alone, it’s always the result of teamwork. After the design phase, come the development phase and the testing phase. Understanding that every team member is responsible for the final product is crucial if we want to deliver good and valuable products to the market.
What affects the cooperation between designers and developers?
The cooperation between UX designers and developers doesn’t always work the way it should. The main problems identified by developers are:
no communication with developers before or during the design process,
no explanation of user flows or how the application should work,
great exported assets and screens in Zeplin/InVision but no description of what the behaviour of the flow and elements is,
lack of documentation,
solutions that are hard to implement,
errors and edge cases not thought through.
Problems identified by designers:
the developer doesn’t want to implement the proposed solutions,
the designer is already in another project, and they must return to one they’ve already closed because some issues are not understandable for developers,
the delivered solution is different than the one proposed by the designer from the UX and UI point of view.
What to do to avoid those problems?
Constant communication before, during and after the design process.
As mentioned by many developers, they need consultations with designers. But designers need consultations with developers too. Time and technical constraints always influence the design. That is why designers don’t design in a vacuum, and they must ask whether some ideas are even possible. Developers are also masters of edge cases. It’s highly possible that they will spot something that a designer missed. It’s a natural good thing. Through consultations and UX reviews, we can identify those cases and deal with them better.
In Netguru, we really value efficient team cooperation, and we care about the products we deliver. That’s why we put a lot of work into making our cooperation work best. Apart from daily standups with clients, we also have internal team standups, which make our cooperation even more efficient. We can take that time to run a UX review, discuss blockers, problems, and everyone’s progress.
Moreover, for each project, there is a separate Slack channel to which we add every team member. We can consult each other at an instant – we don’t need to wait for a daily standup to discuss important issues. But we don’t stop there. We have a whole separate Slack channel for developers and designers. We created it to help designers consult their decisions from the point of view of implementation. Designers can always share their work, ask if the proposed solutions are possible to be implemented and compatible with the technologies used. This way of cooperation really helps in delivering amazing products!
An open environment and a culture of open feedback in a company drives quality discussions and makes room for improvement. The business and the project can only benefit from it. A delivered product or service is entirely thought through, edge cases and errors are identified and resolved, and the solutions are up to date with the current technology. So, as we can see, it’s worth it to take care of the relationship between UX designers and developers. They should work as a team rather than separate units.
Project handover: sharing is caring
The project handover should cover more than just an explanation of user flows and a presentation of screens. A designer should also share findings from their research. It’s not a waste of time if we work as a team, so everyone should be involved. The knowledge about users builds empathy, shows that the provided solution is for real people. By presenting personas, customer journey maps and other deliverables from the research phase, we build awareness that we are here to solve user problems and respond to their needs with our product. Developers will then understand a design decision better and, sometimes, a feature that may seem strange/unnecessary to them can be very beneficial for the end users.
The information about the market, competition, business, and KPIs gives a better context, helps to understand what we want to accomplish by building the solution, what our goal is, and what we want to change in the market. This kind of handover expands the knowledge, brings the team together, and makes everyone care more.
Even when our communication is efficient, and we have shared all the insights that we produced, we share a common goal, and we are on the same page – the designer still needs to deliver documentation. This way, the developers won’t have to ask questions about every detail or ask designers to explain a design decision. There are two types of deliverables which, in my opinion, work perfectly for the cooperation between UX and development: wireflows and prototypes.
Wireflows: diagrams and flows for better understanding
Wireflows are a combination of wireframes and flowcharts. The definition found at Nielsen Norman Group says that “wireflows are a design-specification format that combines wireframe-style page layout designs with a simplified flowchart-like way of representing interactions”. Flowcharts were created in the design world as a way for encouraging more efficient project communication and creating better documentation. Why are wireframes and flowcharts not enough?
Wireframes show what the product looks like, what the content is, and where the key elements of an interface are. That said, a wireframe is static, and it’s hard to capture by using wireframes alone what the rules for interactions are, how the layout should change, and what the behaviour of interface elements should be.
Flowcharts are good for complex workflows – they describe the product’s behaviour and the user task flow. But all these complex flows are presented without any context and content, so it can be difficult to understand them sometimes.
A combination of wireframes and flowcharts will produce a great solution allowing you to map all the flows and behaviours of a product. We can show how a product will work, what to expect when a user clicks a button or how an action can be undone, and what the steps for each use case are.
How can building wireflows enhance the cooperation between UX designers and devs? Designers can:
prepare the documentation use case after use case, screen by screen, and explain the user journey step by step,
add notes to specific screens or parts of those screens,
spot edge cases, errors, and missing or incorrect flows.
Correctly created wireflows are easy to read and understand, and they work perfectly as a communication tool. Wireflows can reduce the developers need to understand designs and guess what should be implemented. The delivered product is free of wrongly implemented solutions and missing functionalities. The work of designers and developers proceeds faster and more calmly, rather than in a mood of nervous debates and endless discussions of missing designs.
You can build wireflows in Sketch or by using one of several tools. Personally, I really recommend the overflow app, by proto.io. It’s still in beta, but I think it works really well. You can upload wireframes or UI designs directly from Sketch or Figma. There is an option to add device skins, and you can put each use case on a separate board. You can also export your work to .png and .pdf. On top of that, there is a presentation mode, which works amazing – when you tap the interaction arrow, the application will refer you to the corresponding screen.
Prototypes: what the product feels like
Prototypes are another way of explaining user flows and journeys. A prototype shows the interactions between screens – it is a mock-up/demo of what the product will look like and how it will behave. Prototypes are mostly used for user testing sessions.
User testing on prototypes is a real money saver for businesses. It’s better to find errors during the design stage rather than in a product that’s ready and developed. But as it turns out, prototypes they are also appreciated by developer teams. So if prototypes have been designed during the process, make sure they are shared with developers – they will appreciate it. The main advantages of prototypes are as follows.
Prototypes, just like for wireflows, help designers to spot missing interactions, flows, edge cases, and errors.
By building interactive prototypes, a designer can show how products and features will behave and what the transitions between screens are.
As for the UI Design and Interaction Design, there are also many advanced tools for UI, Motion, and Interaction Designers (such as Framer, Framer X, Principle, or InVision Studio) which allow building very complex interactions and animations. A designer can show how specific elements and features should behave, e.g. how a popup should be displayed, or what the behaviour of swiping is.
A huge benefit of using prototypes is that a project is easier to understand when you can interact with it. Other benefits and possibilities of using prototypes are similar to those of wireflows. They improve communication, make developers’ work easier, help to deliver products quicker, and reduce the number of mistakes and errors.
From the business perspective, by implementing a proper workflow, good communication, and insights sharing, we reduce the number of misunderstandings and conflicts within the team. Also, the documentation is key. Instead of attending countless meetings or preparing complex written documentation, you'll be better off if you spend this time on creating wireflows or prototypes. A picture is worth a thousand words! Prototypes and wireflows will make everyone work more efficiently. Products are developed faster and with minimum to zero design debt, and all edge cases and errors are spotted and taken care of. By using this kind of documentation, we reduce time and money wasted, and we ship high-quality products. We recommend this kind of a workflow because it really helps us create amazing projects!