Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Bridging The Gap — Produce and Communicate Design Decisions to Developers

Bridging The Gap — Produce and Communicate Design Decisions to Developers

Event: https://www.meetup.com/Ladies-that-UX-Amsterdam/events/250936387/

Integrating design into agile is a challenge faced by many teams. In development-centric companies, the gap existing between what is designed and what is shipped often fails to be ready for the end-user - even though the work of designers and developers should complement each other.

To help build sustainable and scalable products, designers need to think besides visual deliverables and be ready to engineer and maintain a shared design language, document design patterns, responsiveness, accessibility, versioning flow. Moreover, designers need to understand technical constraints and help developers understand and implement the designs, creating a collaborative culture of design and code. Accomplishing this isn’t easy, but isn’t rocket science!

In this workshop, Rayana will be concentrating on a couple of these areas: Design Requirements, Design Specs, and Unit Testing. Rayana will show you practical ways in which a little bit of knowledge in these areas can unlock the full potential of your design to be ready for development. You’ll learn how to create useful design documentation and to start thinking of ways you can improve collaboration with developers and solve UI problems in more creative ways.


Rayana Verissimo

June 28, 2018


  1. Bridging The Gap Produce and communicate design decisions that are

    essential to code @ImRayana | Rayana Verissimo Ladies That UX — Amsterdam June 2018
  2. Ladies That UX — Amsterdam @ImRayana Thank you for coming

  3. Ladies That UX — Amsterdam @ImRayana Rayana Verissimo UI/UX Engineer

    @ImRayana Backbase Design Systems "
  4. Ladies That UX — Amsterdam @ImRayana <!DOCTYPE html> <html lang=“en”>

    <head>Design</head> <body>Coding</body> </html>
  5. Ladies That UX — Amsterdam @ImRayana

  6. There’s a lot more to design than just “design”

  7. None
  8. http://www.dignited.com/wp-content/uploads/2014/05/I-heard-hes-good-at-coding-l.jpg

  9. “Collaboration”

  10. Ladies That UX — Amsterdam @ImRayana Agenda Part 1: •

    How we work & why we struggle • Design with the developer in mind • Things we should ask & do <br> Part 2: • Building a common language with Modular/component design • Exercise • Wrap Up
  11. How we work Chapter 1

  12. https://apiumhub.com/tech-blog-barcelona/ux-design-process/ The Design Process

  13. https://www.nngroup.com/articles/common-ux-deliverables/ Most Frequently Produced Deliverables

  14. https://www.nngroup.com/articles/common-ux-deliverables/ Most Frequently Produced Deliverables for Developers and Engineers

  15. https://www.smashingmagazine.com/2016/06/picking-the-best-prototyping-software-for-your-project/

  16. Ladies That UX — Amsterdam @ImRayana Developer: Impossible. Can’t do

  17. None
  18. Ladies That UX — Amsterdam @ImRayana Wireframes and prototypes can

    be very expensive assets
  19. Ladies That UX — Amsterdam @ImRayana …and they require constant

    follow up.
  20. Ladies That UX — Amsterdam @ImRayana Time Fidelity

  21. https://cdn-images-1.medium.com/max/2000/1*oGiihjDWThgd3_RJx5FQyA.png • Organisational silos • Physical separation • Lack of

    trust • Different mindsets Roots of non-collaborative design process
  22. None
  23. None
  24. Ladies That UX — Amsterdam @ImRayana We know this is

    . Why does it still happen?
  25. Ladies That UX — Amsterdam @ImRayana

  26. https://en.wikipedia.org/wiki/Blinkers_(horse_tack)#/media/File:Horses_2.jpg The “horse” designer/developer • Wears blinkers • Looks only

    in a forward direction • Can end up running off course unless they are made to remain focused
  27. Ladies That UX — Amsterdam @ImRayana In non-collaborative processes we

    do not always include people with different perspectives and we fail to communicate, creating frustration and friction.
  28. None
  29. Ladies That UX — Amsterdam @ImRayana We need to have

    a conversation with our teams and follow up on execution of our work before the code is submitted to production and the job is considered “done” de facto.
  30. Ladies That UX — Amsterdam @ImRayana Are we like-minded people?

    Exercise 1
  31. Ladies That UX — Amsterdam @ImRayana Describe the element •

    Form groups. Each person writes on a post- it what this component is to you (3 min). Next, the group chooses the most adequate description (5 min). • When we’re done, each group shares its final description (3 min each group). • Discuss: How different was the thinking in your group?
  32. Ladies That UX — Amsterdam @ImRayana Designers • This a

    Material card component. • It’s a News widget. • It’s a container of information. Developers • It’s a container with a 3px border radius, a light black box shadow and a white background. • A component that renders a given component into a card border with shadow.
  33. Ladies That UX — Amsterdam @ImRayana Designer and developer are

    thinking in a way that makes sense to themselves. That leads to misinterpretations and friction.
  34. https://thedesignteam.io/how-to-conduct-engaging-design-reviews-11e60adba412

  35. The Sydney Harbour Bridge under construction in 1930. Picture: State

    Library of New South Wales.
  36. Ladies That UX — Amsterdam @ImRayana TL’DR • Include developers

    in early stages of discovery. • Don’t wait too long to share your prototypes. • Prototypes can be expensive - know when to spend time on them. • Designers have a shared language. Developers can be very technical. Build bridges, not walls :)
  37. Design with the developer in mind Chapter 2

  38. Ladies That UX — Amsterdam @ImRayana Design with the developer

    in mind is about: • Working as a team, not merely completing a step in a process. • Empathising with your development team. • Including developers in the design process. • Creating a great product that is the sum of the design and development efforts.
  39. https://cdn-images-1.medium.com/max/2000/1*XzSpeIlt_zYHK5GEgdmigQ.png

  40. https://twitter.com/boagworld/status/999231722054135810

  41. Ladies That UX — Amsterdam @ImRayana The ✨Ideal✨ Process™ Is

    collaborative and transparent. Includes people from different areas in every step. Helps everyone to be more informed, invested and empathetic with users from the start.
  42. Developers are just designers of code.

  43. https://twitter.com/jmspool/status/836955987860914176

  44. Ladies That UX — Amsterdam @ImRayana

  45. Ladies That UX — Amsterdam @ImRayana We already think like

    developers! Developer-friendly ideas, like Brad Frost’s Atomic Design breaks down each interface into logical building blocks. We can use this mental model to describe in a practical manner how users should interact with each individual block, and how these interactions affect others elements on the page.
  46. It doesn't hurt to say: Our first job is to

    design with the user in mind.
  47. Ladies That UX — Amsterdam @ImRayana Fight for great UX

    % • Ask your how you can help get things done. • Investigate whether there's a way to create a similar effect with less development effort. • When an argument can be made either way about whether an item or element benefits the user, choose the path that makes the code more reusable, consistent, or clean. • Invite the developers to usability testing, show the real value for a real user.
  48. Ladies That UX — Amsterdam @ImRayana TL’DR • Designing with

    the developer in mind is about collaboration. • You still have to fight for the user. Don’t take a ‘development centric’ approach as correct. • Involve people and they will understand the value. • We are all designers (?)
  49. Bridging The Gap Chapter 3

  50. Ladies That UX — Amsterdam @ImRayana You cannot communicate if

    you do not understand where the other person is coming from.
  51. http://bradfrost.com/blog/post/this-is-the-web/

  52. Ladies That UX — Amsterdam @ImRayana This chapter is divided

    in two sections: 1. Things you should ask your developer
 2. Things you can do to improve your design deliverables so that they make more sense to code
  53. Things you should be asking your developer:

  54. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer Are there any limitations for the product? Why: User interface design as discussion about feasibility, progressive enhancement, and responsive layouts. • Present sketches on early stages to understand content hierarchy and layouts, and how things can progressively improve in different devices. • Know what kind of information you have to work with, the data, API. • Keep in mind limitations of HTML5, CSS3, or whatever language of your choice. &
  55. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer What browsers do we need to support? Why: Not all browsers are equal. • Predict how elements will look without the added effects in legacy browsers and provide solutions (progressive enhancement). • Certain components’ controls cannot be customised with CSS.
  56. https://developer.telerik.com/featured/comprehensive-guide-styling-file-inputs/

  57. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer What browsers do we need to support? Why: Not all browsers are equal. • Predict how elements will look without the added effects in legacy browsers and provide solutions (progressive enhancement). • Certain components’ controls cannot be customised with CSS. • Understand that typography and colours render different in different browsers. • Reference: https://caniuse.com
  58. https://www.reddit.com/r/firefox/comments/2i9nes/thank_you_firefox_for_being_pretty_much_the_only/

  59. Ladies That UX — Amsterdam @ImRayana Cross Platform Typography

  60. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer Will the product be built using a front- end framework? Why: Knowing the framework will help make decisions and set-up deliverables the right way. • Set baseline for grid and breakpoints (@mediaqueries) • Many frameworks come with built-in design elements like buttons, forms tooltips, etc. • Defined global values: padding, column width, gutter width etc. • Official documentation will help find out if a component has dependencies.
  61. None
  62. This table is outdated, but you get the point ;)

  63. https://www.sketchappsources.com/free-source/1303-bootstrap-grid-template-sketch-freebie-resource.html

  64. Ladies That UX — Amsterdam @ImRayana On custom breakpoints •

    Check with developers before customising the existing grid or breakpoints if you're using a front-end framework like Bootstrap. • Recommendation is to follow web standards that are in use rather than customising unnecessary functionalities. • Have a conversation about margins, paddings and gutter values.
  65. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer How are properties being reused in the CSS? Why: Visual properties are always shared in the CSS, knowing where helps you keep a consistent UI. • Modern CSS preprocessors allow reuse of properties for color, pixels, borders… • Important to keep consistency across components. • It allows easy customisation of an app’s UI (think white-label products). • Learn more: https:// www.creativebloq.com/web- design/what-is-sass-111517618 *
  66. https://netbasal.com/angular-cli-and-global-sass-variables-a1b92d8ca9b7

  67. http://www.sketch.help/articles/the-power-of-symbols

  68. https://www.sitepoint.com/using-source-maps-debug-sass-chrome/

  69. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer How assets should be prepared? Why: Devs have preferences too. • Do they prefer you slice, prepare and save all assets into an organised 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?
  70. Ladies That UX — Amsterdam @ImRayana Things you should be

    asking your developer 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.
  71. http://nikonow.com/ux-production/

  72. https://medium.com/ux-power-tools/the-ux-designers-best-companions-for-sketch-2d6cd3c10534

  73. This JS does not represent the component in display ;)

  74. None
  75. Things you should be doing that will help:

  76. Ladies That UX — Amsterdam @ImRayana Things you should be

    doing for your developer Learn the medium you’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. -
  77. https://marvelapp.com/styleguide/components/form-elements

  78. Ladies That UX — Amsterdam @ImRayana –Brad Frost “We need

    teams that have enough understanding and empathy for each other's work, that value working together instead of complaining about the other side of the silo. And yes that means designers knowing enough about how their medium works as that will only improve the conversation and lead to better quality and less frustration.”
  79. Ladies That UX — Amsterdam @ImRayana The Web Language Consider

    studying a few of those 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
  80. HTML, CSS and JavaScript are the basic building blocks of

    the Web. How the web works: https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/How_the_Web_works
  81. Ladies That UX — Amsterdam @ImRayana Study the foundations instead

    of tools.
  82. https://www.envano.com/2016/09/move-over-adobe-flash-html5-is-here-to-stay/

  83. Ladies That UX — Amsterdam @ImRayana Awesome sources W3Schools: https://www.w3schools.com/html/default.asp

    Mozilla HTML docs: https://developer.mozilla.org/en-US/docs/Web/HTML Mozilla CSS docs: https://developer.mozilla.org/en-US/docs/Web/CSS Box Model: https://developer.mozilla.org/en-US/docs/Web/CSS/ CSS_Box_Model/Introduction_to_the_CSS_box_model Free Code Camp: https://www.freecodecamp.org
  84. Ladies That UX — Amsterdam @ImRayana Things you should be

    doing for your developer Keep accessibility in mind from the start • Some visual decisions we make hurt overall web accessibility requirements. • Research what can be customised in the UI before deviating of its original shape. • Something changed in the code because of a design decision can hurt your users. ♿
  85. Bad UX = Bad accessibility Better UX = Yay accessibility!

  86. Ladies That UX — Amsterdam @ImRayana Things you should be

    doing for your developer 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.
  87. http://bradfrost.com/blog/post/interface-inventory/

  88. Ladies That UX — Amsterdam @ImRayana Things you should be

    doing for your developer 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.
  89. None
  90. None
  91. None
  92. Ladies That UX — Amsterdam @ImRayana TL’DR • WOW! There’s

    so much we have to know to be kick-ass designers! • Find the balance for 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.
  93. Next up: Modular Design Building a common language + Exercise

  94. <break> 15 min

  95. Building a common language with components Chapter 4

  96. Ladies That UX — Amsterdam @ImRayana This chapter will cover:

    1. What components are 2. Benefits 3. Creating a component 4. Exercise 5. Checklist for testing
  97. Hm… Component?

  98. Ladies That UX — Amsterdam @ImRayana What is a component?

    • Generic term for any pre- defined object that you intend to use in multiple pages. • In order to be reusable, they must be standardised in appearance and function. • Each component will render reliably regardless of the context it’s used in. Nadal Soler
  99. Ladies That UX — Amsterdam @ImRayana Components let you split

    the UI into independent, reusable pieces, and think about each piece in isolation
  100. https://www.invisionapp.com/blog/improving-team-communication/

  101. None
  102. Ladies That UX — Amsterdam @ImRayana –Dennis Kardys “Modularity is

    the key to creating a flexible design system. For a system to be modular, it must have interchangeable parts (components)”
  103. Ladies That UX — Amsterdam @ImRayana –Stephen Hay “We’re not

    designing pages, we’re designing systems of components.”
  104. None
  105. Ladies That UX — Amsterdam @ImRayana Benefits of a component-based

    design • It allows for reuse. • It accelerates development. • It ensures user experience consistency. • Optimizes the requirements & design process. • Can be translated to design deliverables (sketch, style guides)
  106. None
  107. How to approach component design

  108. Ladies That UX — Amsterdam @ImRayana Modularizing your design •

    Eliminate discrepancies and shape each component into a standardised model. • Be lean, removing any page- specific component customisation that doesn’t benefit the system as a whole.
  109. None
  110. Component creation process

  111. None
  112. Ladies That UX — Amsterdam @ImRayana Evaluate: • Grab headings,

    text fields, radio buttons, carousels, accordions, tabs, images, icons, video players, graphs, etc, etc. • You’re not trying to capture every single instance of a component, but rather uncover distinct treatments of a component (like a button with a bevel and right-facing caret vs another without any bevel/ caret). • Step 1
  113. None
  114. None
  115. Ladies That UX — Amsterdam @ImRayana Isolate and elaborate: •

    The designer collaborates with a developer to isolate core UI elements so that they can elaborate on their structure, appearance, and behaviors. • Isolating a component from its original design helps ensure that it is decoupled, while still being connected to the overall design. The result of these steps will result in a specification for a new component to be coded. Step 2
  116. None
  117. Ladies That UX — Amsterdam @ImRayana Document decisions: • Functional

    specifications define what happens when you interact with a component. • General guidelines for use and behaviour are included. • This short description can be used as a UI Story in Scrum to map and plan the development of a component in your product. Step 3
  118. https://blog.zeplin.io/introducing-zeplin-2-0-components-and-a-ton-more-goodies-7c09dacc1f48

  119. Ladies That UX — Amsterdam @ImRayana In order to build

    and test components, developers need to know: • Do you expect it to be dismissable? • Do you expect it to be repositioned (i.e. on window resize)? • Do you expect to be placed on top, right, bottom, left? • Do you expect the same behaviour on mobile and desktop devices? • What possible variations can this component have (color, background, content, interaction)?
  120. Ladies That UX — Amsterdam @ImRayana

  121. None
  122. None
  123. Ladies That UX — Amsterdam @ImRayana A UI Story should

    include: • Component name • A short description of what it does • Acceptance criteria • Responsive behaviour • Accessibility • Dependencies How to structure a UI Story
  124. Guidelines • Clicking outside the dropdown area closes the element.

    • Dropdown should be the topmost element onscreen when open. • Only one dropdown is visible onscreen at a time. • When possible, allow users to close one dropdown and open a new one with one click. • The height of a dropdown is not constrained. • Must provide a separator for inner sections. • A header can be added to label sections of actions in any dropdown menu. Alignment
 By default, a dropdown menu is automatically positioned 100% from the top and along the left side of its parent, otherwise it will display right. Disabled actions
 Displaying actions as disabled, rather than removing them, let the user know they exist under the right conditions. Description
 A simple dropdown component. Dropdowns can display a list of choices on a transient context. Dropdowns are triggered upon interaction (click) with another item, such as a menu, button or link.
  125. Ladies That UX — Amsterdam @ImRayana Breaking down the interface

    into modular components Exercise 2
  126. Ladies That UX — Amsterdam @ImRayana Componentization • Form groups.

    Discuss about how you would break down the interface into pieces. • Next, the group chooses one component to work on. Answer development questions and sketch possible variations. • Document decisions. • When we’re done, each group shares its findings.
  127. Findings

  128. Unit (Design) Testing

  129. Ladies That UX — Amsterdam @ImRayana • Visual quality •

    Sufficient states & variations • Responsiveness • Content flexibility • Functionality • Accessibility • Browsers & devices compatibility QA Checklist for Unit testing
  130. Ladies That UX — Amsterdam @ImRayana • The best way

    to test is to have an interactive version of your component (HTML/CSS) • You can ask your developer to put together static markup of existing components on a HTML page (or do it yourself), and link the latest version of the CSS to that page. • You don’t need to test it in context with the application. QAs can do that for you. Where to test
  131. Ladies That UX — Amsterdam @ImRayana • Testing begins when

    a developer signs they’re ready for a final review. • Check with your developers when can you be included in the review process. • You can ask them to share an environment or screenshots of the coded component. • Incorporate testing as a clear step or sub-step that’ll prevent an item’s release if tests aren’t passed. When to test
  132. Ladies That UX — Amsterdam @ImRayana • Designers and developers

    that wear other hats as needed, including QA. • We hold a developer accountable to submit components that they’ve already run through the checklist. Who should test
  133. Ladies That UX — Amsterdam @ImRayana TL’DR • Developing your

    UI with a component-based approach can make your processes more efficient and economical. • It facilitates reuse, and provides transparency into the requirements and design process. • It helps us create a common language between design and development. • It provides a way for better testing our designs.
  134. Wrap-up

  135. Thank you! @ImRayana rayanaverissimo.com