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.
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:
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”.
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.
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.
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!
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.
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.
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.