WWDC2017 Session 809

Transcript

>> 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.
[ Audience Laughing ]
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 ]