Communication Between Designers and Engineers

Whether you're a designer or engineer, we all want our apps to look and feel amazing. We want our code to be flawless, our assets to be pixel perfect, and our store ratings to be five stars nothing less.

But let's talk about reality.

As a designer you're focused on creating delightful interfaces and experiences. As an engineer you're focused on making sure you code works and nothing breaks. As a result the process becomes slow and everyone feels frustrated. It's friction we don't need. In the next 10 minutes we're going to look at four things that will really help make difference. So let's get started.

The first is using the same terminology.

This saves time, eliminates confusion, and increases credibility with your team and clients.

Let's look at some examples of how using different terms amongst team members can create confusion down the road.

All right, pop quiz time. By a show of hands, which of the following is the right term for this piece of UI -- Is it a pop-up? Popover? Modal? Wow you guys are good. And the right answer is none of them.

The correct term is UI Alert Controller or more currently called an Alert. All right, another show of hands. Which of the following is the right term for this bar -- Is it a Header? Top Tool Bar? Navigation Bar? The actual term is Navigation Bar.

All right and what do we call this bar? Is it a Drawer? Tool Bar? Bottom Navigation Bar? The right term is Tool Bar. All right last one, show of hands. Which of the following is the right term for this control? Is it a Switch? Is it a Toggle? Is it a On-Off Slider? No? The actual term would be Switch.

So these are just some of the elements that have been called different things by different people. I am sure most of you have experienced moments where you have had a performance stream of mental translations when someone asks you to implement a Toggle and the modal trigger a pop-up. Adopting mutually understood terminology is so important to eliminating confusion and frustration.

It's like you said cup, when you really meant this kind of cup.

You want to agree on terminology that doesn't require additional brain cycles to interpret down the road.

So here are some quick activities that you can try with your team to reach that goal.

Take 30 minutes with your team or client to do an app postmortem, just focusing on terms.

Make it fun, turn it into a Pictionary game. Put things up on a whiteboard and spend 20 seconds doing flash reactions to it.

And for the more formal minded, create a report showing all the breakdowns due to terminology confusion.

Developer to Apple.com is a great resource for referencing standard terminology whether in the Human Interface Guidelines or in the API Reference Documentation.

All right, the second thing I want to talk about is having one source of truth.

Ever been in a situation where you've had to pull mockups from a server, stings from a Project Wiki and then doing like a last minute asset swap send via email or coming back to an old project and not knowing which is the right version to open. Hashtag designer life. What if you and your team or client could agree before hand a single place where all of the approved deliverables can be accessed. This would ensure that everyone knows where to go to check out the necessary assets.

Unfortunately designers don't have similarly universal options as engineers currently do with their IDE's and Version Control.

There's an increasing number of solutions that have come in the last few years. So work with your designers to find one that integrates with their tools and yours.

All right, thirdly I want to talk about having very thoughtful focus.

Let's be real. There's an inherent desire to start customizing your UI so you can stand out from your competition. But have you stopped to consider the big picture first? When designing and developing an app, you're creating a system and systems have a lot of complexity where everything is interrelated and interdependent. It requires all of us to think deeply into all the use cases, balancing that against your time, skill, and other system resource constraints. It helps if you start from a place of familiarity. Just as most of you are more familiar with cooking using a non-stick pan, rather than something more specialized like a tandoor oven, starting with standard patterns and resources you get for free in the SDK helps to speed up the entire process. Here's an example of a standard table.

Starting with a standard table view with this accompanying disclosure indicator accessory, would free up time to work on ensuring that the implementation is stable. This also ensures that the app will work with accessibility features in the OS, which is a huge plus for many people.

Then when you want to start creating Custom UI, you'll be in a more empathetic state of mind to ask is it worth the effort? Here are some activities I want you to do before going down any path.

Thoroughly consider all the intended and etch use cases. Write them down. Better yet do this together with your team or client.

Find out what resources with the OS or your tools that come for free and leverage that as a starting point and build accessibility considerations up front. This will ensure even more people can enjoy your app. All right finally I want to talk about show and tell. Or rather show more than tell. Designers can be guilty of throwing static mockups inspects over to engineers, especially in a time crunch. Or engineers can blindly implement the specs without seeking clarification.

Then when the app is being reviewed by the team, there's invariably complaints from the designer that implementation didn't match the intent, or frustration from the engineer that the spec wasn't detailed enough to fill in the mental gaps. More often than not, demonstrating with a video or a small interactive prototype can be extremely valuable in communicating the intent or better yet, sparking a conversation on constraints, possible solutions, and next steps.

Here's an example of an animation spec for transitioning into a full screen sketch on the Notes app, the designer could be delivering to an engineer.

Showing graphical representations of the curves, the related parameter value pairs or better yet, the exact API reference, coupled with a video of the design animation will ensure that the implementation will certainly match the intent.

Designers, you can do this. There are powerful prototyping tools out there like Principle, Flinto, or even Apple Keynote that are really easy to use, so I highly encourage you to try them. And if you want to gain extra credit ability of the engineer, try using Xcode. See how engineers use it to bring your designs to life.

Diving in doesn't even require any coding. You can open Xcode, select any app option, track your assets into the asset catalog to see for example how your app icons will be implemented. Or try the storyboard feature to create simple flows. Hint -- you can import your static mockups in here to create interactive prototypes. Use the object liability to see how built in controls work and what they're really called.

And look at all these states and properties for the table view accessory that UI Kit is providing for free. Using the same tool helps build empathy, keeps you informed, and thereby build credibility. It can also initiate conversations that can be helpful to improving the app that you're both working on.

So here are some activities I want you to try with your team.

Set short face-to-face times and run through your prototypes with each other.

Use that time to tweak values or use the opportunity to explore alternatives.

And schedule feedback sessions while you're in context. For example, grab your designer or engineer teammate while your project is still open and before you're about to check in your work. Quick timely communication reduces errors and mitigates potentially bad situations down the road when your app is in your users hands.

So in summary, here are the four things to start working on -- agree on the same terminology, decide on a single source where everyone knows where to post and check out deliverables, have a thoughtful focus on use cases, resource capabilities and accessibility and demonstrating with dynamic prototypes rather than static screenshots.

Doing these four things will really help with infective communication. You'll get clarity on what needs to be done and you'll gain credibility with your team, client, and users.

Thank you. [ Applause ]