Bridging the Gap — produce and communicate design decisions that are essential to code

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.

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

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.

This chart ranks the deliverables by the percentage of UX professionals who reported producing them either “often” or “sometimes”. Wireframes and prototypes were most commonly produced, followed by flowcharts, sitemaps, and usability/analytics reports.

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.

This chart shows the percentage of survey respondents that reported each type of deliverable as being effective for communicating with developers and engineers.

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.

https://uxplanet.org/designers-developers-collaborative-design-process-for-innovation-c931206ed2ac

“At this phase in particular where the final artefact — your product — doesn’t exist yet, provides a bunch of opportunities for collaboration.”

TL’DR

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

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

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.
Example form element: https://marvelapp.com/styleguide/components/form-elements

#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
How the web works: https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/How_the_Web_works

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

https://www.nngroup.com/articles/form-design-placeholders/

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

Summary 💪

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.

About the Author

Like this post? Stay up to date with me on MediumTwitter and LinkedIn.

Deployments with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have the project integrated with a Continuous Integration server, where we run the tests and report back to GitHub pull requests with the results of the test run and the coverage, we can deploy our project and make it available on the Internet.

We will do so with Heroku. I have chosen Heroku because it allows me to perform these experiments for free.

If you want to jump into the code, this is the tag for this post.

Continue reading …

Continuous Integration with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have some containers in place for development, we can integrate with a CI server. I chose Scrutinizer CI because of the code analysis it makes, the fact that it is also a CI server it’s a plus. However, as a CI, it has some limitations, which I will talk about later on when integrating with Heroku, so we will most likely move to another CI engine later in the future while keeping Scrutinizer only for the code analysis but, for now, this is all we need.

To set up the CI, we will:

  1. Containerize an environment to run the tests in the CI
  2. Configure Scrutinizer
  3. Add the scrutinizer badges to the README.md
  4. Integrate Scrutinizer with GitHub

If you want to jump right into the code, this is the tag on GitHub.

Continue reading here

The week of security at Werkspot / Instapro

Last week we organized the week of Security. A week dedicated to increasing the security awareness of our employees. When it comes down to security you might think our developers and product owners are pretty aware of the risks, but the interest and results show different. This post is about some activities we organized and what we learned in order to improve the security awareness within Werkspot/Instapro.

Gamification

To get started we thought about a way to get everyone motivated. A great way to have everyone involved was adding a competition component. Everyone could earn “Security coins” for each challenge. The one with the most coins at the end of the week could win one of the amazing security prizes. The winner would receive the Security Gnome!

Dedicated Slack Security Channel

At Werkspot/Instrapro we are big fans of Slack. To get started we asked everyone to join our security channel. This way we can communicate certain security risks and no matter whether someone is working from home, at the office, or be commuting, all of us are pretty quickly up to date.

Surprisingly this resulted not only in people joining the channel, but started to share security issues and helping each other out. Pictures of unlocked machines, keys at desks and paper at printers that were left behind were mentioned in this channel.

Daily security tips & posters

To keep everyone engaged in this week of security, we put up some simple posters about the do’s and don’ts on security. Related to this we send daily tips on how to handle phishing emails, multi-factor authentication (MFA) and awareness of your social activities in relation to security.

Phishing emails and follow upphishing.png

By Tselmuun.mn (Own work) [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)%5D, via Wikimedia Commons

Receiving spam is something we all receive in our inboxes on a daily basis. To train our employees we use Phishme to send Phishing emails and support the ones that do click on the link by providing training.
Phishme is providing plenty of scenario’s and templates for catching a recipient on matters of urgency, emotions or even “great deals”. We decided to send emails about losing your last year’s vacation days as well as tax-related messages. In multiple languages, we provided training material so people were still able to read what they could improve. Within a couple of months, we will do the same exercise and see if we improved the awareness.

Show how to crack passwords

It’s great to inform people about the risks and warn them about the way they choose passwords or don’t make use of MFA, however, showing how hackers actually could resolve your password is making the risk more real.
We invited the whole company to join a session where we showed the different ways of brute force login on a website, social engineering for retrieving the password and a live demo of using the tool Hashcat to decrypt passwords.

With a database of 20k encrypted passwords within minutes, we decrypted a couple hundred. Most of the people were amazed by seeing a plain text password coming out of a hash that actually worked to log in to a real website.

Final words

The week of security is, with a small amount of effort, a great way to improve security awareness in any organization. Even as a tech company there is enough to learn and enough material available to increase this awareness. My main takeaway is, provide enough information, make it rewarding to join and show some real-life examples of how certain security issues happen.

And the winner is…

Here at Werkspot, we like to work together with educational partners. As part of our innovation network, Strategic Product Design (Master) students of Delft University of Technology worked on design cases. The projects of these students were a little different than usual. Students are used to working in the waterfall approach. The cases here at Werkspot were coached differently: They did three sprints according to the agile methodology and Scrum framework. Within those sprints they adhered to the lean approach. Multiple experiments were conducted, ranging from interviews, paper prototyping and smokescreens via email campaigns. One can discuss what makes an MVP an MVP; what is sure is real end-users generated insights to form the concepts and strategies on.

Two hours before the pitching starts the students start to shuffle in. A mixture of excitement and nerves can be seen on each of their faces. Each of the groups prepared a 5-minute pitch on the concept they worked on for 10 weeks. After a short energizer which filled the meeting room with loud youthful noises we went through all slide decks. Everyone was well prepared and ready as a duck. One student asked: “How many people can we expect?”. When I estimated fifty, her eyes opened wide with delight and anxiety: “Wow, that’s more than I expected”. When the students arrived upstairs, one could easily spot who was going to present of each group: wiggling on their feet and drinking a lot of water. The bar was opened and Werkspotters started to gather around. Time for the first pitch.

Pitch 1: Offerty streamlines communication

The first pitch was done by 3xA Design (each grouped named themselves). They envisioned that Werkspot should help in facilitating easy and open communication between the service professional and the consumer. Their concept was Offerty, an app that gives an easy to use overview of the jobs they are working on. Consumers can receive updates about their job as the SP works on the job.

Screen Shot 2018-02-05 at 16.39.38.png
Offerty allows for easy communication between the service professional and the consumer. Click the image for a demo.

Pitch 2: First aid for theft

The second pitch found an interesting insight during their research: Service professionals are all afraid their equipment gets stolen. The app EHBD (‘Eerste hulp bij diefstal’, Dutch for first aid for theft) aims to get rid of the hassle after a theft. Easy communication with their insurance, a digital overview of their tools and an overview of what info you need to supply to the police. Click here to see a demo.

Screen Shot 2018-02-05 at 16.44.22.png
Theft is a very prevalent topic under service professionals

 

Pitch 3: Chatpro engages in conversation

One of the cases focused on creating a more delightful experience for consumers. Describing their job can be hard. Customers feel misunderstood about the job that they want to get done. Chatpro’s team proposed a strategy of layering on various interaction methods, ranging from an improved form, a Werkspot Expert and AI supported chatbots to enable a conversational UI.

25028885087_4b7a18e5a8_k.jpg

Pitch 4: Werk+ enables a community

Werk+ was the fourth pitched concept. They found that trust and quality are hugely important for consumers to use our platform. Their proposed vision was to enhance the feeling of community to enable this trust. An interactive map with social media integrations would enhance the feeling of community.

Screen Shot 2018-02-05 at 16.52.23.png

Pitch 5: Werkplan visualizes the job

The last pitch was done by Bananabrand. Their research showed that service professionals like to feel appreciated. A consumer-first oriented app allows the consumer to ask for advice on more specific details in the entire job. This is a standalone app, yet allows for a direct job posted on Werkspot. This way the consumer is better informed and the service pro can offer advice where needed.

Screen Shot 2018-02-05 at 16.55.50.png

Werkplan wins the audience award

50 minutes down the road and the first award ceremony was about to take place. The audience gets to vote on their favourite concept. Voters take out their smartphone and rethink which concept should win. As the votes started to pour in it soon became clear that Werkplan won the audience award by a landslide. A warm applause and cheering sounded from the audience and the team moved forward to collect their award (an engraved hammer).

28120054389_8c10f63d18_k.jpg
Team BananaBrand claims their audience award!

And the jury award goes to…

The jury, consisting of Ronald (CEO), Kris (CSO) and Jaap (CTO), retreats to a meeting room. While the door shuts slowly, the sound from the audience gets softer and becomes inaudible. The jury expressed their appreciation of the proper presentation skills but comes down to business right away. Two concepts were closely tied to their potential and the link with Werkspot stood out.

39867897882_58fc21f5a1_k.jpg
Ronald (CEO) discusses the pros and cons of each concept before announcing the winner..

The jury walks out of the meeting room. For one last time that afternoon I passed the microphone to Ronald. The audience went silent and all the eyes were aimed at Ronald. He goes over each of the pitches. As he announced the runner-up, the winning team looks excited and confused. Later one of the members will explain: “I was not sure whether we won or not.” When Ronald said the words “Which makes us come to the winner, Chatpro”, cheering followed. Based on their strong integration plan and direct integration potential, Chatpro snatches the jury award from their competition. They have shown that they understand the problems a consumer faces and offer a technically feasible solution. Well done!

39190087654_5c7be3d865_k.jpg
The Chatpro team happily claims there award

After one and a half hour, the formal part is over. Teams are happy the semester has been put to an end. They happily grab some drinks from the bar and discuss their concepts with the Werkspotters even further. Some of the students went on to discover the nightlife of Amsterdam. All I can say is that as an innovation manager and as a teacher I can recommend this kind of collab to anyone.

Written by Jeroen Coelen. I’m an innovation manager at Werkspot and a part-time teacher at TU Delft, focusing on design strategy and entrepreneurship. 

Werkspot @ WomenHack

At Werkspot, our Engineering team is looking for great talent to help us hack and do awesome stuff using your UX/Development, and Data Engineering Skills. We believe a happy and productive team is the one where members come from diverse backgrounds.

In technology jobs, there’s a large gap in representation of Women. We are striving to get more women at Werkspot, especially in our Product and Technology teams.

Last Thursday, I attended the WomenHack recruitment event on behalf of Werkspot. WomenHack organises these events around the world to help companies recruit women.  The event was hosted by TomTom, and it was kick-started by one of the founders of TomTom, Corinne Vigreux.

We were happy to join as a sponsor and to provide information about what we do at Werkspot. I met several enthusiastic and ambitious women – UX Designers, developers, hackers, project managers, and scrum masters. I got some promising CVs and we are looking forward to talking to them!

Do you like what we do at Werkspot and want to be part of our great team? Look at our Careers website for our current openings!

Kick-Ass Friday #0

We at Werkspot believe in bringing out the best in every person, discovering ways to stimulate creativity and become strong autonomous groups able to help take our company and products to the next level. 

In this spirit, we started the Kick-ass Fridays initiative.

Every other Friday, at Werkspot everyone within our multidisciplinary tracks is encouraged to spend the day working on a short project or initiative to stimulate everyone to explore alternative ways to create value for our users. 

On 19th January, we had our Kick-Ass Friday #0 (Yes, we start the numbering with 0, as Dijkstra intended!) in which our cross-functional teams huddled together to hack on some whacky ideas. The team gathered a lot of ideas from minor annoyances to big improvements in all facets – code, product, devops, and other fun stuff.  On the very first day of this initiative, we ended up these ideas/demos from Werkspotters!

  • Consumer Flow Improvements – to make our product easy to use
  • Improve UX for the mobile app based on SP feedback – Fancy Swiping animations!
  • Make it easier to find meeting space at Werkspot using a slack bot, you know the challenge every office space faces 🙂
  • Better UX – Werkspot logo in 3D as a loading Indicator, because 3D is everywhere
  • Accurate monitoring for DB Backups to improve Signal to Noise Ratio of our alerts
  • How strong are passwords really – a review of password cracking tools to show the weakness of … weak passwords.
  • A tool/easy method to measure how proud we are of our product
  • Improving Not Found (404) pages, hopefully, you’ll never find them 🙂
  • Increase Customer Satisfaction and decrease refunds by increasing trust to share phone number on our platform.

The day ended with music, pizza, and drinks as usual. We will have these Kick-Ass Friday’s every other Friday from now on.

Do you like what we do at Werkspot and want to be part of our great team? Look at our Careers website for our current openings!