How can we improve our UX/UI practice by borrowing some of the development’s points of view? How can we create useful design deliverables? How might we improve communication with developers to solve design problems in more creative ways? And ultimately how might we make devs ❤️ love working with us?…
On June ’18 Ladies That UX Amsterdam had the pleasure of having Rayana Verissimo give a workshop about Bridging the Gap between design and development. These are my takeaways from the workshop:
How we work and why we struggle
As the years pass, what we UX-ers do for a living gets more complex and new tools are created. We have to choose and master the right tool for the right kind of project.
From crafting your deliverables the right way to a specific audience, to learning how you can better work with people in different roles, from users to developers, all this is the foundation for your craft.
“There’s a lot more to design than just ‘design’ ”.
The journey from an idea to a great product requires clear communication and close collaboration between design and development teams. We need to be equipped with all possible knowledge to make that a reality. Even with the shared understanding, there’s still a visible gap between those two roles that are so important for creating products.
We have the chance to get closer, especially now that we live in a world full of design systems, style guides, and guidelines — us designers aim for reusability, consistency and clarity.
The ‘unfortunate workflow’ from designer to developer
The design process has several stages. It begins with understanding our users, what they want, the current problem and what’s wrong with the existing solution. After understanding, we jump to sketching and generating a bunch of ideas before narrowing them down into the design stage.
The ideas that survive will be designed and mocked down from low to high fidelity before prototyping. The more fidelity we add to the prototypes, the more time is spent refining them to look like the final application.
Sketching and prototyping are essential for what we do. A chart by the Nielsen Norman group shows that almost 90% of designers produce static wireframes as deliverables.
When it comes to communicating ideas to developers, interactive prototypes were chosen as being the most effective. Style Guides are also becoming increasingly popular as a design/dev deliverable because it’s focused strongly on structural details and interaction specifics that are critical for implementation purposes.
In most processes, when the prototype is what we want our design to look like, then we are ready to move forward to the development stage. This is when we meet developers with our mockups, explaining why they were designed the way they were.
There might be a chance developers start to criticise the ideas, asking questions, suggesting new ideas and saying that something will take ‘AGES’ to implement.
As a result, we need to re-iterate our designs, include ideas and limitations that we heard from engineers and spend more time working on the mockups…
You wasted your time working on a solution that is not ideal and your developers are sad. Everybody is sad. I’m sad to tell that story…
The problem with this approach …
Is that developers are usually not included in ‘OUR process’ from the beginning, understanding the why behind the design decisions. Wireframes and prototypes are very expensive assets.
“At this phase in particular where the final artefact — your product — doesn’t exist yet, provides a bunch of opportunities for collaboration.”
- Include developers in early stages of discovery
- Don’t wait too long to share your prototypes
- Prototypes are expensive — know when to spend time on them
- Designers have a shared language. Developers can be very technical. Build bridges, not walls 🙂
Design with the developer in mind
In order to make our lives easier, we have to design for development. This means finding the solution that produces the best user experience with the least amount of effort.
A design that looks great on Sketch but takes too much effort to be implemented or breaks the codebase every time a developer needs to implement a change does not deliver great design.
That’s why design systems are so successful — they allow us to design in a systematic, modular way, and this is extremely valuable for how a product is coded. Designing with development in mind is about working as a team, not merely completing a step in a process.
Just like you need to empathise with your users, you should apply the same mindset towards your development team.
Designing together helps everyone to be more informed, invested and empathetic with users from the start.
Remember that developers are just designers of code and ultimately everyone is working towards the same goal — whether it seems like it or not.
We cannot bridge the gap if we’re not open to let other people influence our jobs.
It’s not to say our processes should be led by development. It’s a two-way street. In more mature teams, developers think with the designer in mind. We have frameworks to help achieve that, such as the Atomic Design by Brad Frost.
But it doesn’t hurt to say: Fight for great UX 💪
Always keep in mind that when a design decision has a clear benefit to the user, it should be developed (or at least considered). Don’t let a developer talk you out of it if it’s absolutely a better user experience.
Use whatever facts and sources you can to explain your position, but most importantly:
- Ask your developers how you can help get things done before flipping out or giving up on your design.
- Investigate whether there’s a way to create a similar effect with less development effort. There’s always a workaround. You can work with the bare-minimum and plan improvements for future iterations of a feature.
- When an argument can be made either way about whether an item, design element, or feature benefits the user, choose the path that makes the code more reusable, consistent, or clean. Again, design systems are accelerators to our craft.
- Invite them to usability testing, show the real value for a real user.
Things you should be asking your developer
#1 — Are there any limitations for the product? ✋
Why: User interface design as discussion about feasibility, progressive enhancement, and responsive layouts.
The first step we have to take is to predict UI and UX limitations that may (and probably will) arise during development.
- Present sketches on early stages to understand content hierarchy and layouts, or how can things progressively improve in different devices
- Know what kind of information you have to work with, the data, API
- Keep in mind / ask about limitations of HTML 5, CSS3, or whatever language is being used
#2 — What browsers do we need to support? ☝️
Why: Browsers read web pages differently. We can influence, but we cannot control the user experience.
Knowing which browsers you support can help you understand some default behavior of the interface, if animations are supported, and also dig into the amount of customizability that will be needed in the code to apply our design changes.
- Predict how elements will look without the added effects in legacy browsers and provide solutions (progressive enhancement)
- Certain component’s controls cannot be customized with CSS
- Understand that typography and colors render differently in different browsers
- Reference: caniuse.com
#3 — Will the product be built using a front-end framework? 🛠️
Why: Knowing the framework will help us make safer decisions and set-up our deliverables the right way.
There are many popular frameworks available that take a lot of the tedious work out of the design and development process. You don’t need to figure out things by yourself.
- Set baseline for grid and breakpoints
- Many frameworks come with built-in design elements like buttons, forms, tooltips, etc
- Defined global values: padding, column width, gutter width…
- Official documentation will help find out if a component has dependencies
#4 — How are properties being reused in the CSS? 🤹
Why: visual properties are always shared through the CSS, knowing where helps you keep a consistent UI
- Modern CSS preprocessors allow reuse of properties for color, pixels, borders, etc.
- Important to keep consistency across components.
- It allows easy customization of an app’s UI (think white-label products).
- Learn more: creativebloq
#5 — How should assets be prepared? 🎁
Why: Devs have preferences too.
- Do they prefer you slice, prepare and save all assets into an organized folder?
- A layered source file that they extract the images from themselves?
- PSD? Sketch? Invision? Zeplin?
- Do they have the same version of the software/access?
- How can you group and name the layers to help them find and isolate the assets they need?
#6 — Should the assets be accompanied by a handoff document? 📖
Why: You might need to provide extra details.
- Handoff documents should be simple and easy to read.
- Talk about the granularity of details necessary for development.
- Sometimes tools that provide annotation and code inspect are not the best choice.
- You can choose to deliver a visual style guide.
Things UX can do (to bridge the gap)
#1 Learn the medium we’re designing for
- When designing a mockup you should be able to see how it can be built from a developer’s perspective.
- For example, an input field is created using an HTML tag and styled with CSS.
- You don’t need to know how to write this code but you should know the basics of how form inputs are generated.
#2 Consider studying a few of these topics
- Learn how HTML tags are nested and rendered in the browser
- The basics of CSS and how it differs from HTML
- How CSS properties are used to create effects like box shadows
- Which elements can be created using pure CSS vs. which elements require images
- How breakpoints work in responsive website layouts
#3 Keep accessibility in mind from the start
- Some visual decisions we make hurt overall web accessibility requirements.
- Research what can be customized in the UI before deviating from its original shape.
- Something changed in the code because of a design decision can hurt your users.
Some visual decisions that we make hurt overall web accessibility requirements. Always make sure you are covering basic accessibility guidelines in your prototypes.
For example, placeholders in form fields are harmful to accessibility.
Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments.
Also, not all browsers allow placeholder text to be styled using CSS, this is a difficult issue to mitigate.
According to NN/g, the best approach for it would be placing the label and hint outside the form field so they are always visible to the user.
#4 Be consistent
- Align everything nicely along the grid, or introduce any other kind of visual order.
- Use a consistent color scheme throughout the app.
- Keep the navigation consistent across all screens.
- Re-use the same elements for different situations. For example, design a sample notification and color-code it for different situations.
Inconsistent design generates inconsistent code. Code and design define performance. Also, we know the value of consistent design. Consistency makes users feel comfortable, saves time and money, and let us focus on innovating in other solutions. 🏆
#5 Break your design down into pieces
- You can break large designs into small, cycle-sized pieces that focus on UI Components and incrementally add elements to the overall design.
- Remove the components from the app context.
- Define acceptance criteria for each component.
- Document non-functional requirements.
We tend to deliver our final designs as a stack of slides. Maybe you deliver them on Invision, Zeplin, whatever tool… Maybe it’s something the developer can click through and those links will kind of reflect the user journey for that feature.
It’s quite fine but not excellent because our prototypes are normally built in a very complex way.
Looking at how agile teams work, we can break large designs into small, cycle-sized pieces that focus on UI Components and incrementally add elements to the overall design.
When you show the component in context over and over again it kind of loses the context of all its details, so focus instead on interaction states. You want the developers to be able to focus on this single problem instead of overwhelming them with the whole interface.
Everything is covered and it works pretty well for everyone.
By breaking designs apart, we have the opportunity to investigate, prototype, and usability test design chunks, carrying the progressively built design forward until it is complete and reviewed with the developers. Then, we pass the finished design to the developers for implementation.
“This example shows an interaction of a dropdown component that allows selection of multiple items. The UI shows all the states, default, hover, disabled. One thing you might notice it’s missing here is all the context of the app around it.”
WOW! There’s so much we have to know to be kick-ass designers!
- Find the balance between how you deliver assets to devs.
- The web is complex, but learning the foundations of web design can only help us, HTML/CSS are essential.
- Focus on solid learning — tools get deprecated.
- Use a modular/component-based approach to design.