Bridging The Gap — Produce and Communicate Design Decisions to Developers

Slide 1

Slide 1 text

Bridging The Gap Produce and communicate design decisions that are essential to code @ImRayana | Rayana Verissimo Ladies That UX — Amsterdam June 2018

Slide 2

Slide 2 text

Ladies That UX — Amsterdam @ImRayana Thank you for coming

Slide 3

Slide 3 text

Ladies That UX — Amsterdam @ImRayana Rayana Verissimo UI/UX Engineer @ImRayana Backbase Design Systems "

Slide 4

Slide 4 text

Ladies That UX — Amsterdam @ImRayana Design Coding

Slide 5

Slide 5 text

Ladies That UX — Amsterdam @ImRayana

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

“Collaboration”

Slide 10

Slide 10 text

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
Part 2: • Building a common language with Modular/component design • Exercise • Wrap Up

Slide 11

Slide 11 text

How we work Chapter 1

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Ladies That UX — Amsterdam @ImRayana Wireframes and prototypes can be very expensive assets

Slide 19

Slide 19 text

Ladies That UX — Amsterdam @ImRayana …and they require constant follow up.

Slide 20

Slide 20 text

Ladies That UX — Amsterdam @ImRayana Time Fidelity

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

Ladies That UX — Amsterdam @ImRayana We know this is . Why does it still happen?

Slide 25

Slide 25 text

Ladies That UX — Amsterdam @ImRayana

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

Ladies That UX — Amsterdam @ImRayana Are we like-minded people? Exercise 1

Slide 31

Slide 31 text

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?

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

Ladies That UX — Amsterdam @ImRayana Designer and developer are thinking in a way that makes sense to themselves. That leads to misinterpretations and friction.

Slide 34

Slide 34 text

https://thedesignteam.io/how-to-conduct-engaging-design-reviews-11e60adba412

Slide 35

Slide 35 text

The Sydney Harbour Bridge under construction in 1930. Picture: State Library of New South Wales.

Slide 36

Slide 36 text

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 :)

Slide 37

Slide 37 text

Design with the developer in mind Chapter 2

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

https://cdn-images-1.medium.com/max/2000/1*XzSpeIlt_zYHK5GEgdmigQ.png

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

Developers are just designers of code.

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Ladies That UX — Amsterdam @ImRayana

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

It doesn't hurt to say: Our first job is to design with the user in mind.

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

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 (?)

Slide 49

Slide 49 text

Bridging The Gap Chapter 3

Slide 50

Slide 50 text

Ladies That UX — Amsterdam @ImRayana You cannot communicate if you do not understand where the other person is coming from.

Slide 51

Slide 51 text

http://bradfrost.com/blog/post/this-is-the-web/

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Things you should be asking your developer:

Slide 54

Slide 54 text

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. &

Slide 55

Slide 55 text

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.

Slide 56

Slide 56 text

https://developer.telerik.com/featured/comprehensive-guide-styling-file-inputs/

Slide 57

Slide 57 text

Slide 58

Slide 58 text

https://www.reddit.com/r/firefox/comments/2i9nes/thank_you_firefox_for_being_pretty_much_the_only/

Slide 59

Slide 59 text

Ladies That UX — Amsterdam @ImRayana Cross Platform Typography

Slide 60

Slide 60 text

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.

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

This table is outdated, but you get the point ;)

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

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 *

Slide 66

Slide 66 text

https://netbasal.com/angular-cli-and-global-sass-variables-a1b92d8ca9b7

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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?

Slide 70

Slide 70 text

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.

Slide 71

Slide 71 text

http://nikonow.com/ux-production/

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

This JS does not represent the component in display ;)

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

Things you should be doing that will help:

Slide 76

Slide 76 text

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. -

Slide 77

Slide 77 text

https://marvelapp.com/styleguide/components/form-elements

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Ladies That UX — Amsterdam @ImRayana Study the foundations instead of tools.

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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. ♿

Slide 85

Slide 85 text

Bad UX = Bad accessibility Better UX = Yay accessibility! https://www.nngroup.com/articles/form-design-placeholders/

Slide 86

Slide 86 text

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.

Slide 87

Slide 87 text

http://bradfrost.com/blog/post/interface-inventory/

Slide 88

Slide 88 text

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.

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

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.

Slide 93

Slide 93 text

Next up: Modular Design Building a common language + Exercise

Slide 94

Slide 94 text

15 min

Slide 95

Slide 95 text

Building a common language with components Chapter 4

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

Hm… Component?

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

Ladies That UX — Amsterdam @ImRayana Components let you split the UI into independent, reusable pieces, and think about each piece in isolation

Slide 100

Slide 100 text

https://www.invisionapp.com/blog/improving-team-communication/

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

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)”

Slide 103

Slide 103 text

Ladies That UX — Amsterdam @ImRayana –Stephen Hay “We’re not designing pages, we’re designing systems of components.”

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

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)

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

How to approach component design

Slide 108

Slide 108 text

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.

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

Component creation process

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

No content

Slide 114

Slide 114 text

No content

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

https://blog.zeplin.io/introducing-zeplin-2-0-components-and-a-ton-more-goodies-7c09dacc1f48

Slide 119

Slide 119 text

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)?

Slide 120

Slide 120 text

Ladies That UX — Amsterdam @ImRayana

Slide 121

Slide 121 text

No content

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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.

Slide 125

Slide 125 text

Ladies That UX — Amsterdam @ImRayana Breaking down the interface into modular components Exercise 2

Slide 126

Slide 126 text

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.

Slide 127

Slide 127 text

Findings

Slide 128

Slide 128 text

Unit (Design) Testing

Slide 129

Slide 129 text

Ladies That UX — Amsterdam @ImRayana • Visual quality • Sufficient states & variations • Responsiveness • Content flexibility • Functionality • Accessibility • Browsers & devices compatibility QA Checklist for Unit testing

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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.