From the lab


← Back to all Labs

Insight

Things developers wish UX-designers knew about web development

To prepare for a lecture with UX and requirements engineer students, we asked for experiences and insights from our colleagues about the developer’s point of view.

Friday 24 April

To prepare for a lecture with UX and requirements engineer students, we asked for experiences and insights from our colleagues about the developer’s point of view. What do developers wish more UX-designers knew when it comes to (web) development? Well, in short:

A lot of work should be done before development starts

This might seem obvious but a surprising amount of times the target audience is not consulted in any way. We don’t know what they want, on which level they use a system, on which device they access the interface, etc. Sometimes the users don’t even exist - or are presumed to be everybody.

We also want to know about all the stake holders and their requirements. Knowing from the beginning that department X needs to able to implement Y will help planning for a more robust system than throwing it in as a dependency later.

Knowing these things also affects estimation, which in itself is a process that should be done in a thoughtful matter to avoid biases, i e “The Anchoring Effect”.

Involve developers early on, preferably at the beginning

Developers can be an informed ally in making tech dependent decisions and provide useful input. The possibility to discuss ideas, remove and add functionality already in concept and wireframing stages is very valuable and leads to high-quality development.

Iteration and testing features triumphs over big “finished” design deliveries

As important as it is to involve developers early on, it is to have the designers included to the very end. Setting aside time to talk about features and changes is crucial.

Working with iteration means getting features out for testing early and then perhaps tweaking them multiple times. It’s more effective to make changes this way, in small steps throughout the project, rather than to change parts of a big finished project. It's very rare that the end result is exactly the way it was designed in the first version. Iteration and testing is a process that comes with that realisation.

Small things can take surprisingly long time to develop, and vice versa

It is super hard to know what takes time and what doesn’t, if you’re not a developer (we don’t even know ourselves all the time!) So try asking one. And include them early in the project for estimation!

Custom designs and super detailed requirements do not always give the best results

Please don’t ask us to develop custom features that hijacks native behaviour or breaks sensible standards for the user. Don’t break the Internet! :)

Also, it's usually better to focus on describing the vision and goals, use cases, stories and scenarios, rather than the way to get there. Leave the technical “how?” for the developers.

Be organised and work through your material

Structure layers and assets. Use naming conventions that makes sense. It makes it easier for developers and helps create context. Decide on a single source of truth that is updated when changes are made rather than have multiple locations with different versions of things.

Don’t forget about states and animation. Usually every interface needs visual guides and information about: loading, hover, click, updates and errors.

Consider learning about and using design systems.

Conclusion

In any project with a cross-functional team it’s important that the members has at least some amount of knowledge and understanding of each other's work. According to the developers we asked, the most common issues in the developer-designer-relationship seem to be related to involving developers too late, not having the possibilty or time for iteration and designers not having the time to work with the project to the end.