In this work-in-progress post I'll cover the problem of handing over design to development in web domain. The problem is relatively similar in other domains as well. The difference is mostly in tooling.
Transforming design into development to achieve the intended outcome is one of the most challenging problems in software development. While various solutions and approaches exist, none are without obstacles. The problem space encompasses technical, interpersonal, organizational, and conceptual dimensions.
Temporal types of handovers
A design handover is a phase in the development process where designers transfer the relevant design information, assets, and specifications to stakeholders responsible for implementing the design.
Type
Description
Challenges
One time
Often pre-agreed deliverable format
Content is explained and discussed fully in one or few sessions
Lack of follow-ups from the designer.
Adds pressure to prepare appropriate questions to cover all cases
Periodical
Pre-agreed deliverable format
Often limited in scope
Often guided and triggered by some agile process step
Rarely enough time to challenge design in wider context
Items are viewed in isolation
No handover
Designer also codes
The latest state of the design is typically in the code, but can move left if needed
Designer needs to know how to code
Types of alignment approaches
Type
Description
Challenges
Manual
Custom CSS is written based on visual references
Up to the developer whether to pick any CSS library
Requires skills from the developer
Guiding
Custom CSS is written based on visual references
Agreed library with loose coupling. e.g. Material UI, but development and design uses separate references.
At first seems easier than "manual" approach, but still equally hard to get right in the end.
Component lock-ins lead to design compromises: of the shelf components are not appropriate, but custom components is not desired due additional workload.
Enforced
Fixed libraries with strong coupling. e.g. Tailwind based components generated from Figma.
Development and design uses same references.
Requires extensive tooling
Requires learning of additional DSL
Relies on non-standard non-transferrable solutions and skills
Uninformed vs. informed views in context of UX design
Sometimes communicating design to development faces challenges that originate from the people themselves. The underlying reason for uninformed views might be the lack of experience or knowledge, stress, conflicting interests or plain ignorance. Uninformed views tend to be held by people who are not actively engaging with design work or problems. Sometimes they are held by the designers themselves.
Uninformed view
Informed view
UI is just a task that can be done by anyone quickly
Quality UI requires skills, time and effort.
UI details are about fine-tuning colors
UI details are about fine-tuning colors.
UI details ranges from human cognition to aesthetics to technical state changes and everything in-between.
Design is just a recommendation
The level of UI fidelity in details can be agreed case-by-case.
Lack of deliberate design is still a design decision – albeit an unintentional one.
Every decision — even the last minute tweak in development — requires justification.
Design is never debatable
Any design can be challenged.
Perceived quality of the UI is agnostic to the stage of the project: bad UI is bad regardless of the background story.
Limitations and challenges during the development are not a concern for the user.
Our customers and users do not care about fancy UI, they want to get stuff done.
Design is not about visually fancy UI. Design is about solving problems.
Expectations towards everyday user interfaces are built granularly. Those expectations affects how any UI is experienced, regardless of the context.
Developer and user have different motivation and incentives.
A confusing or unattractive UI leaves unprofessional first impression. This is valid even if YOU don't see the problem. Someone else might.
Superior UI can differentiate your product and attract customers who value ease of use and the potential increase in productivity.
UI is not worth spending too much time on, users will learn how to use it
Intuitive interfaces decrease the need for extensive training, documentation and support, saving time and resources for everyone, including developers, customers and users.
Even after learning a complicated UI, users may operate less efficiently than they would with an intuitive design, affecting productivity.