JOHN ATHAYDE: All right. Thank you guys for
coming.
My name is John Athayde and
I'm gonna talk today about working better
together,
mixing lean UX with Agile development
and user-centered design.
Last time I was in Chicago to do
Rails stuff was in 2006.
That guy right there. A little less scruffy.
But somebody pointed out
last night that this looks like
it's the crew for Obi and Courtney's band
hanging out.
I come from an architecture background of
the building
variety, and a lot of the stuff I'm gonna
show you today comes from a couple different
places.
One is from my freelance work over the last
fifteen years, which is meticulous. A lot
of this
stuff is from the almost three years I spent
at LivingSocial heading up the internal UI
for all
of our internal apps. And then recently I've
been
doing work at a new start up called Cargo
Sense with Rich Kilmer and Bruce Williams.
I also wrote this book. It's a little out
of date, but there's some good stuff in it,
and Prag Prog has a forty percent off ticket
right now if you guys are interested in any
Rails or Ruby ebooks.
So. Experience matters. Experience is really
anything that you,
as a user, are going to see when you're
working with a tool, a book, anything. I mean,
go back to 1983, these were our two main
experiences that we had. So it's changed a
lot
since then, but it's still something that
you can
think of. There's a very big difference in
how
I'm gonna work with these two different platforms.
Experience is also something you see in everyday
life.
The one on the left, just not working as
well as the two on the right. You're gonna
turn it upside. What's going on? Think about
this,
too. You ever go to an ATM and you
just cannot get the sun angle right, and you
can't see the screen? That's a bad experience.
Or
doors. The handle would imply pull. Horizontal
bar kind
of implies push. But here, you have to put
a label on it.
Now, you can apply this to a lot of
things you've probably worked on, where it's
so unintelligible
that it has to be overly labeled and overly
documented. Because the experience is not
clear.
And this is always a fun one, you know.
But why do exterior doors go out? Well, Chicago,
Illinois, in fact, Iroquois Theater. 1903,
600 people died
in a fire, because they tried to get out
of a building. The doors opened in, and they
crammed up against the doors and couldn't
get out.
We're gonna talk about that here in a little
bit. But that's something to think about why
those
doors work that way. Why is that experience
that
way.
So, when we talk about UX, what is UX?
We're gonna define that real quick. It was
created
in the early 1980s usability broadly, to refer
to
what was a number of vague and subjective
attributes
of a product. And it's user-friendly characteristics
is what
they call them.
And this marked the beginning of a shift,
from
a phase that we're focused on the features
into
a term that was becoming more concerned with
the
various facets of how people worked with those
features.
So the International Standards Organization,
ISO, this is in
ISO 9241, is that usability is the effectiveness,
efficiency
and satisfaction with which specified users
achieve specified goals
in particular environments.
Pretty dry. Pretty generic. Jakob Nielsen
gives us a
nice little five point thing. You can love
or
hate Jakob Nielsen, but he is kind of one
of the big human factors guys of software
development.
So he says that it is the promptness with
which users learn something, the efficiency
that they attain
making use of it, how easy it is for
them to remember how to use it, how error-prone
that is, and then the level of satisfaction
they
attain from using the system.
And so it comes back to, a lot of
these things are applied because they're the
experience of
many years. And many mistakes.
So going back to the Iroquois Theater fire,
architectural
building codes changed a lot in the early
1900s.
They actually started to come into, really
started to
be happening between the San Francisco earthquake
and events
like this. You really started to see them
say,
you know, we should say that you legally have
to build a building this way. So now you'll
notice any commercial building, the exterior
door will open
out, or it will break away.
So, you'll notice on revolving doors that
you can
actually kind of break away. Like, if you
cram
into a revolving door, those doors will give
with
enough force.
So that's, you know, over time we've learned
these
things. We've applied them, and they make
the experience
better and safer for everybody.
So, let's get into looking at designs specifically
around
software. So there's various processes and
methods, and I
want to kind of compare and contrast some
stuff
for you real quick. The first is waterfall,
which
I'm sure most of you have heard or experienced
at some point. Large deliverable documents,
excessive documentation.
But this comes from projects in engineering,
like, in
traditional engineering and architecture,
where the design is finished
and approved before you start building it.
And, this
is something from a project management tool,
like Microsoft
Project or something like that. It's called
a Gant
chart. The red is the critical path. Things
that
have to happen in a certain order and have
to be finished before the next step can be
completed.
Now, any delay in there can really mess up
the whole timeline of a project. And, this
is
what typical waterfall processes look like.
You define the problem, you come up with a
design that solves that problem, then you
build that
design, you test that, and you deploy it.
And
this is usually the entire enchilada. We are
not
even gonna go into like, this is, you, shrink
this down really small and it is kind of,
in a way, agile, but we're gonna not even
bother talking to engineers. We're going to
go spend
six months writing up requirements.
Then the design engineer, the design guys
are gonna
go for three months and work up all these
designs and have a 300 page document that
they
turn over to engineering, who then builds
that.
So, you know, that's just one of these little
things here. And that can take a long time.
And while you're doing this work, the business
and
the world is changing. So the likelihood of
you
building the wrong thing and being two years
behind
the power curve in this process is high. And
it all comes down to, this was all about
deliverables.
So it has, if I was running a design
agency, I want to maximize the deliverables,
because that's
maximizing the amount of time I'm gonna be
spending
working on building this stuff for people.
Wire frames,
big, you'll see these documents where they
have the
whole screen laid out and everything is specified
by
pixel, and instead they could have just made
a
prototype and, and had been testing it already.
Instead
of having to say, well, this is twenty-one
pixel
Verdana. No. Go. Just put in CSS. Build it.
Go.
You'll hear people fight against that they're
not waterfall,
and the developers will say, hey, we're agile.
Well,
the developers may be agile, but each cylo
is
still throwing things over the wall, or over
the
trenches as some people will call it.
So, within product, they are kind of churning
on
their stuff. And then they go talk to design
and they have a hand off. And then design
works on their stuff in an iterative fashion.
But
they're not iterating together. So this is
still waterfall.
Product talks to customers, and the developers
don't get
to talk to customers. Now there's, when you
start
having all those separations, you know you've
got a
problem.
So, instead of relying on this, like, mythical
design
hero to come in and say here is the
solution that will solve all your ills, we're
gonna
start talking about the misappropriated but
adequately named lean
UX. So it's really about design facilitation
as opposed
to, here's my beautiful design that you will
build.
So, when we talk about lean UX, it's really
a three part process. It involves design thinking.
It
involves agile, and in the traditional agile
manifesto mentality,
and it pulls heavily on the lean startup book
from a couple years back. So design thinking
came
out of a idea, which is a big product
ideation. I hate that word, but it's what
they
do. They come up, they create products.
And the CEO came up with that. And it's
innovating, based on direct observation, about
what people want
and need. So, instead of going in and actually,
like, thinking and saying, what if, what if?
They
actually go and start talking to real people
and
finding out what they want, finding out what
they
need, and then coming up with solutions that
fit
those problems. And, they use sensibilities
and methods to
match these needs with something that's actually
a viable
market product.
Part two of that's agile. Melissa Perry posted
this
a couple days ago. She's a big UX person.
And I think this is probably, when every manager
says agile, what every developer thinks is
going to
happen. And it's the, that was your training.
And
pretty much whenever I hear some manager say
this
and it's obvious that they don't really know
what
they're talking about, I kind of just feel
like
this, and it's just. No. We're not gonna do
that.
So agile should be. Everyone pretty familiar
with this?
Or at least have heard about it before? This
is from 2001. And it really talks about these
four principles. And it's really in response
to the
software development of the time and how things
were
being built. But I think it really applies
a
lot more to kind of orienteering. And I'm
talking
about map-reading and land navigation when
I talk about
orienteering.
So, the good old boy scout method, you know,
with sitting there and trying to figure out
how
you're gonna get from point a to point b.
So, in orienteering, the first thing you need
to
do is find out where you are. Then you
shoot an azimuth and choose your target. You
say,
this is the angle I'm gonna go to get
there, and there's a target that I am going
to walk to. You move to that target and
you repeat. And you keep doing this.
And it's not just about getting yourself from
point
a to point b, but it's about leading a
group of people all in the same direction
and
sometimes doing complex things. So, when you
talk about
agile, Dave Thomas sums it up this way. You
find out where you are. You take a small
step towards your goal. You adjust your understanding
based
on what you learned, and you repeat.
Which also comes down to the lean startup
mentality
of build, measure, learn. And you're gonna
repeat that
process. So it's not the measure in the sense
of, which of these forty blue shades is the
right button, but measure in the bigger sense
of,
is this, when we have a design idea, we're
gonna try and solve this problem. Does this
actually
solve the problem or not? And we're gonna
measure
the efficacy with which it solves that problem.
So this is kind of the UX process inside
lean, and this can really be applied, it's,
it's,
to the whole thing, cause it's not that design
is separate from development. Everybody's
working together. Everybody's involved.
So instead of having your designer go off
and
come up with something, designers, developers,
product people are
all working together through these steps.
So we're gonna come up with a concept, we're
gonna do a really quick prototype, just get
the
idea enough that we can work with it and
show somebody, and we're gonna validate it,
and then
we're gonna learn from that and we're gonna
repeat
the process.
So the formal definition of lean UX here is
from the lean UX book, and you know it's
trying to bring the true nature of a product
to light faster. And there's a couple tools
that
really assist in this space to help us with
that. One of them is personas.
So you can have personas that are kind of
formal, like on the left, or you really, really
kind of laid back like on the right. And,
this is really along the lines of BDD. So
if you're doing, you know, as a user, the
system admin, we'll give him a name. Give
her
a name.
Go ahead and make that a person, pin them
up on the wall, talk about them like a
real person. It really takes it out of this
theoretical, you know, well here's a, you
know, Q&A
admin that's doing blah blah blah. Give them
a
name, a personality, and it lets you care
about
them in a different way than this theoretical
person.
You can also have a little more, like, formal
documents. These were things that we wrote
up when
we did customer support. We rebuilt their
system at
Living Social. So we didn't draw up something,
but
we came up with, kind of, like, here's the,
the point. So we want to talk about, and,
you know, it's the name, what's the name of
the person. Like, the title. Cause there's
a lot
of, in, in bigger companies, a lot of titles
start to really define roles effectively.
The duties, the goals, the fears, the aspirations.
You
know, what are their computer skills. It really
matters.
Cause if you're dealing with experts, you're
gonna build
a different system than if you're dealing
with a
computer novice.
Means of communication. How do they like to
talk.
Do they use IM. Are they are email? Would
they rather pick up the phone and call you?
Again, it's gonna effect the way you design
the
system.
And instead of sitting there and making big
documents,
you break out paper or you break out the
whiteboard. This is a flow diagram for a project
I was working on at home. And, took me
ten minutes to sketch it out and kind of
figure out the flows of what I wanted to
do. This was for reviewing creating materials.
This is something we did for email. We were
handling multi-city emails at Living Social.
That is the
design. We took that, we went right to code.
You do a lot of sketching. I prefer to
use architectural trace paper. This twelve
inch roll of
fifty yards long. You can lay it over another
sheet, very easily, like you see here. That's
one
sheet laid over another. So I can get elements
that are repeating very quickly. If I want
a
modal I just draw the modal and then, boom,
there you go. You can talk about it.
So, then I can pin these up on the
wall or they can sit there on the table
and just talk about what's going on. And it's
not, I don't like this font. I really don't
like that green or, you know, is this gonna
be this big? No, it's just a sketch. And
you can hand the pen to the person. Everybody
can scribble.
Ryan Singer, I think, has a lot of great
examples of where they even do copy and it's
little, just, lines. It's, there's no formality
to it.
It's, this is a block of copy. This is
a headline and it's a squiggle. And that's
great
because you don't feel like, oh I need to
be an artist.
So, applying these things, I've done this
a couple
different ways and we didn't know what we
were
doing. One of these things that we did a
lot with the info ether days is that we
did working in parallel. So, our first client
meeting
would go something, you know, like this. We'd
all
be in the room together with the client, and
I'd be sitting there working on flows while
somebody
like Rich or Chad were actually pulling out
domain
objects, and actually teaching the customer,
you can say
model. We actually wouldn't sit there and
try and
make up a new language for them.
We'd teach them what a model was, we'd teach
them what the domain meant. And we'd actually
get
them into our head space. And so we'd come
out and build and we'd have usability and
functionality.
They already were committing to the Git repo,
and
we had a bunch of sketches either on a
whiteboard or on paper about how that flow
is
gonna work. Sometimes we even had diagrams
of page
layout.
So it's really about sketching and building
simultaneously. These
are some sharets I did for the State Decoded,
which is a, a Night Foundation opening government
project.
These little things on the left are an inch
square. I was trying to come up with some
early ideas of how the, the main landing page
would look, would lay out. And so just, there's
very little detail there. It's like, maybe
copy here.
Maybe headline here. Here's a feature images.
Here's some
other images. And, you know, I'd like, I liked
the third one I did, so then I developed
that a little better. But you can see it's
literally squiggles. There is nothing there
of copy outside
of the name.
And then that goes, and I took that into
photoshop to get something a little more formal,
cause
I didn't have any brand build around it yet.
Any, any, you know, kind of vibe. And so
we took that and did this and then this
went to build out. While this was happening,
while
the Jquith who's now running the Open Data
Institute
was building this code in PHP, with no idea
of how my frontend was gonna look. And we
married them up later. But we knew the functionality.
We had agreed upon how things were gonna work.
And, so sometimes this comes down to prototyping,
and
looking at things from a big picture level.
And
a couple of things you can do. If you
don't know your end users, one good way to
learn really fast is to do what's called a
mental model. Indie Young is a UX person.
She
was at Adaptive Path for a long time and
now she's out consulting. And it's really
about identifying,
like, this would be somebody's morning mental
model. Prototypical
morning.
Excuse me.
So. It's, it's drawn organizing factor to
figure out
what the users are doing before you type any
code. Or before you even draw on the design
mock-up. And it's a visualization of your
research data.
So if you know what's going on, you don't
need this. But if you have no idea what's
going on and you really don't know your users,
or you, you're on a system that's been around
for awhile and people are complaining that
it doesn't
solve their needs anymore, this is a great
exercise
to find out what those needs are.
You can also do stuff with, just kind of
big picture ideas. When I first started doing
the
design at Living Social for our internal tools,
they
kind of said, just come up with, you know,
combine all these things together, go talk
to people.
Come up with kind of like, an ideal world.
And so I put together about six mock-ups that
were about at this level, and I took them
and we presented them to Aaron Batalion, who
was
the CTO. And engineering was already moving
towards, we
had already started breaking up our monolithic
app at
the time, and they were moving towards a service-based
architecture. So we kind of had an idea of
what we were doing, but we hadn't really finalized
it yet.
And Aaron Batalion just looked at me very
seriously
and said, you do realize that's eighteen months
of
work. Like, what I had put into six screens.
And, so yeah. But what was great about this
was we had an idea of what could happen.
So then we were able to talk about that.
Pull things out, break things apart, and things
evolved
from this. And over time we started working
on
different projects solving different problems.
Like, this was our
scheduler prototype that we built.
And you start putting these in front of people.
So we went down to our actual people that
were scheduling deals and we did usability
testing. Now,
usability testing is hard, because you often
can end
up in this situation where you're trying to
be
all chipper about it and the person's just,
like,
this is awful. This is horrible. It's great.
I
love it. Yeah, that's wonderful.
So we started recording things with Silverback.
And with
Silverback, what you do is you end up getting
a screen like this. And so this is one
of our live tests we did, with Jean O'Reilly
who is one of our senior scheduling people.
And
basically, instead of all of engineering sitting,
that was
working on this project sitting around her,
making her
feel uncomfortable, we had one person talking
through some
stuff with her. Just getting first impressions.
How would
you do this? Very leading questions. You,
you want
the door wide open.
But, you basically get all her clicks, and
you
can see how often she's doing select all and
things like that. But it's really interesting
to see
how somebody starts interacting with something
they haven't seen
before. And this records her video down in
the
bottom with the, from just the camera on the
mac, and you also get audio.
So we could then sit there and review these.
Each one was a twenty, thirty minute session,
working
through various questions. And we took those
back and
then iterated on things.
Sometimes you're working in such a big problem
that
you have to kind of do the rewrite. So
this was our customer support tool that we
rebuilt.
It was originally Sales Force. They were working
in
Sales Force. This is backed by Sales Force.
But
this is a backbone project on top of a
Rails app, and it's super complex. And it's
two
screens. So they have two nineteen inch monitors,
this
is the left and this is the right.
Now, all these things that we were doing,
we
had done so much shadowing. We knew all these
pain points, all these things they hated,
but building
all this, again, this is one of those took
a year to kind of get to this point.
So what we started doing is that we went
in and fixed the pain points when we could.
Instead of waiting to build that perfect screen,
we
went on the production system and fixed that
one
little interaction that was driving them nuts,
and then
we'd go and do the next one and go
and do the next one at the same time,
while we're building.
And so this is really comes down to kind
of a, a better way of doing things is
almost, I call just in time. So you start
with a big-picture design process. Then you
apply that
design. You codify it into a living styleguide.
So
this is a code styleguide, not a print document.
And you revise as you go.
So, with the just in time kind of project,
you know, UX joins at some point. It may
be the very beginning, it may not be. And,
you know, you're starting there. You just
kind of
get your legs, get a feel for where you
are, and you do it in a really intense
design push at the beginning. You do a big
spike. You get your overall design stuff happening.
You
get your design language established. And
you are right
in on tickets.
And, so some of that stuff we did, we
built at Living Social for our internal lab,
something
called Wilde. If any of you say Ed Lang's
lightning talk before lunch, they, he was
talking about
the system they used for the, the customer
facing
side. This is all the internal tool stuff.
So we built this as a Ruby gem that
people could pull down and install, and it
immediately
gave them all of the set up parts to
build apps with.
So instead of having to worry about, do I
put this here, do I put that there? They
immediately had kind of a framework for an
interface
to build their applications. It also had built-in
documentation.
So all of this stuff they could go in
and find out how to use these different things.
We took parts of Bootstrap, we took parts
of
Compass and Bourbon, and we kind of brought
all
of this together into a big scss framework
with
our own design elements.
So, some of these, like, this is very much
derivative of the Bootstrap styles for alerts.
As well
as some of the buttons. We would change up
and make, we did some different things with
buttons,
but a lot of this stuff is very derivative,
cause we were taking things and saying we
like
these pieces but we don't want the whole enchilada.
And as you're going, new design elements come
up.
So about a year after we first built Wilde,
we built this timeline element for our sales
staff.
And this is actually a UI built on top
of Sales Force, believe it or not. This is
completely backed by Sales Force.
But this timeline element, we were able to
extract
out the CSS and html and make it available
for people building other apps. So now if
somebody
in another app wanted a timeline, they could
pull
this code in and they didn't have to go
and reinvent it.
This also helps because users who are used
to
one style, if they switch to another app,
it's
not a whole different world. It's not a whole
new interaction paradigm.
I've done a lot of consulting, and so a
lot of these clients are these kind of long-running
projects. I've worked on one banking client,
for example,
since 2008. All on their internal tools.
And what happens is, we've done a lot of
these kind of big picture design things with
them,
but it always comes down to little interactions.
So
instead of sitting there and saying, let's
go rebuild
our document manager, we say we're just gonna
sketch
what documents look like. Here's two states
of a
document, and now we're gonna build that.
And so this is the kind of deliverable that
they get. It takes me five to ten minutes.
I sketch it out. I send it over. They
build it. I come back in and style it.
And this helps, when you have that living
style
guide, we break everything up into scss files,
and
we do a big import and merge it all
together. So we now have all these components.
So
things that are used everywhere become components.
Things that
are one-offs get placed in areas.
And then you have variables and you have a
whole bunch of stuff. So some of this stuff,
again, is derivative from Bootstrap. Some
of it's derivative
from Compass. We kind of shifted now to being
reliant upon Compass because we've realized
we were including
ninety-five percent of it. So we stopped,
kind of,
chicken and egg and just said, we'll take
the
whole thing.
My current situation is Cargo Sense. And I'm
working
with Rich Kilmer and Bruce Williams, and I
call
this the mad dash. This is, Cargo Sense is
a logistics company. We're taking off the
shelf node
variable tech sensors, which are bluetooth
four, and we've
got an iPad app written in Ruby Motion. And
then we have a web application.
And so we use the data in logistics shipping
to detect takeoff and landing press, with
pressure changes,
and we use data to figure out temperature
excursions.
So, pharmaceutical needs to keep insulin within
this temperature
range, and then we can tell if it's been
out for five minutes, we raise an alert. Things
of that nature.
So this is the story of a shipment. This
is a timeline, again. You know, so it's a
very, it's, some of these design elements,
you've, you,
you created ten years ago. You're gonna be
like,
yeah, I did this. So we can reuse that
kind of concept.
But it's these simple four parts again. Big
picture
design. We came up with an overall brand,
look,
and feel. We started applying it and we codified
it into a living styleguide. In this case
it's
called Kevlar and not Wilde. And we revise
as
we go.
Most of our things, this is a Bower package,
instead of a Ruby gem, because we're working
in
Angular. But it supports, I mean, you could
use
it to support anything.
And a lot of these things, these are designs
that, these are relatively high-fidelity sketches.
These go over
to Bruce or Rich. They comment on them, and
then, if we need to for marketing purposes
or
things before we have built that we're gonna
go
for sales purposes, I'll do these kind of
mockups.
So a lot of this stuff is coming down
to really fast and really, just, kind of,
seat
of your pants pulling stuff off. But when
you
have a small team, you can do that. And
a lot of these design elements, like some
of
these things, like the, the right hand side
or
the header were definitely, you know, Bruce
at three
in the morning saying, I'm making an executive
decision.
This is what it's gonna be.
Now, Bruce happens to be a very talented designer
as well as a full-stack developer, so that
definitely
helps the situation. But you can do a lot
of these things where there's not this formal,
well,
we're following lean UX. It's just kind of,
you're,
this is, we're kind of using these principles
to
make a better process.
So, what are the issues with all of this?
One of the issues is called design drift.
Design
drift is something that happens over time
with any
kind of creative endeavor. You start off,
this is
one of our early designs we did at the
top, and then here's the customer support
tool at
the bottom.
So we started off with a fixed-width, with
margins,
you know, tall header, and we started realizing
that
people were maximizing their screens and having
huge, wide
columns, and we were not effectively using
the space
allotted.
So we went to pushing everything out to the
side, and filling the whole thing up. And
we
really shrunk the header down super small,
and we
collapsed a lot of things away. These are
expert
users. We can do training. We don't have to
have them understand it right out the gate.
Another problem you're gonna hit is if you're
working
with a traditional UX or design team, and
they're
used to having design deliverables and throwing
things over
the wall to you, you're gonna have frustration.
Ladders
dot com, when they rolled out this, the, the
head showed up to this on his desk. His
designers had had a meeting and wrote down
what
they were pissed off about, and this is it.
And it's too many projects, devs making bad
design
decisions, no time to actually come up with
concepts
and ideas, and when we do nobody builds them.
We come up with a great experience and then
you don't build it or it never ships. All
these things are problems that I've heard
and sometimes
I've said.
And so some of the solutions are really, like,
you know, celebrate releases. Like, if you
do a
release on Friday, get the designers involved,
get them
to push. Get them to go hit the enter
key, you know. Do whatever. Have balloons.
Whatever you
want to do, you know, that, that works for
your team. And make time to dream.
I know this sounds really, like, fluffy and
whatever,
but really have time to go and be able
to spitball and say what if and what happens
when I say this, or what happens when a
user does this or, you know, wouldn't it be
cool if the whole system was, you know, purple
instead of red. Whatever.
Kind of figure that out.
Another issue is, if your project management
office or
your product people aren't on board, it will
fail.
It will fail hard. It will fail in glorious
fashion, because it's difficult to see in
the dark.
And what ends up happening is that PMO is
thinking, we're agile, so we have to work
in
sprints and we're gonna do SCRUM, or we're
gonna
- and they get so focused on this process
that they've created.
So we're gonna build this complex thing, but
we're
just gonna wing it. Or, you know, I want
you to focus so I'm only gonna tell you
what we're working on this sprint. And then
the
biggest lie in software development, we're
not gonna tackle
that until phase two.
And you end up with this. So you don't
know where you're going. You end up wandering
all
over the place. it's like forty years in the
desert. And instead of saying, hey, we're
gonna try
and go to this point and we might kind
of do this on the way, but that's what
we're trying to get to, they just say, no,
no, we're just gonna make these, these few
steps
here. Without any big vision, it's really
hard to
get everybody rolling in the same direction.
Another problem is forgetting the users. We
said user-centered
design. So how do you deal with, you know,
your users. And how do you bring them in.
And lots of times, when you first shadow somebody
working on a system, you go ahead and you
have that moment where, Cary Elwes in the
Princess
Bride says, Dear god, what is that thing?
And it ends up being, you have to watch
out for that great rewrite. Cause you're like,
I
can rebuild this whole system. The design's
gonna be
amazing. And you're, it's eighteen months
of work. So,
what we talked about earlier. This is the
modification
of the just in time project.
So we do existing system fixes at the same
time that we're doing big design fixes on
the,
the new system that we're gonna roll out to
replace or things that are gonna roll out
in
time. We go in and just make code fixes,
real time.
Just pair up. Sit down with the, you've got
a developer and a designer, and you sit down
and you say, that's ugly. And the designer's
literally
typing in css and changing stuff, and the
developer's
doing support on Ruby methods or things of
that
nature that need to change in order to make
something work better.
Here's a good example of that. We took. This
was a screen out of our admin system, the
right hand part and it originally was a very
complex system for turning on or off somebody's
email
subscriptions. And we stole some css from
somewhere that
basically made it look like an IE, like this
little checkbox. Little toggle. And this was
a mockup.
But we took that little piece, built that
in
code, and deployed it into production. And
it was,
like, oh my gosh. It's great. We, we understand.
We can see it, visually, what's happening
now.
So, this is something that's important that
you need
to involve subject matter experts. If you
have these
users, you need to go find them. If they're
in, in your office, you just need to go
sit next to them. What is the problem? Why
are you upset? What's your pain point? What
makes
your life miserable?
And if it's something where you're doing,
like Living
Social, we had customers outside and inside.
So we
would go to customer support, say what are
your
top ten complaints that you're receiving.
What's the stuff
you spend all the time on.
Is it people can't find information? Are they
having
a hard time with their credit card? What's,
what's
going on. Take that back to engineering. Here's
some
quick wins. And people will go ahead and knock
those things out.
Another thing to talk about is that user testing
is hard. In all of these systems, the one
thing I've always failed with is that it's
really
hard to formalize user testing and make it
part
of your testing. So, often, I'll end up with
this, you know, this great thing that we've
run,
and then we go and do a user test
after two months.
Ideally, you're doing a very small user test
every
week. One, two people. Not much. And the easiest
way to do this is to go guerrilla. And
you can do this anywhere. You can do this
at a Starbucks. You can get somebody that,
you're
sitting there, if you're working on something
and it's
like, hey I wonder about this interaction.
Hey, what do you think about this? And leading
questions, again. What are your leading questions.
What would
you do here? How would you do that?
Multiple devices, you always get issues with.
Responsive design,
right. You have to plan time for this, because
now it's not just an iPhone. These are just
this Samsung Galaxy sizes. Do you even have
all
of these? What, and this is, ten pixels here,
ten pixels there, really can start to break
designs.
So you gotta determine your break points.
You gotta,
you have to make this part of your process.
You have to say, OK, we're gonna handle responses,
and we built this feature, and now we're gonna
take two weeks and make sure it works on
this, these devices.
And you can emulate a lot of this in
Chrome now, which is great, but, you still
gotta
plan for it. It just doesn't happen.
So, what should we do? How do we take
all these projects and these issues? And this
is
kind of my, my charge to you here. First,
you need to gear up, and it's pretty simple.
Raid the office supply stash, and that's about
it.
Get a whiteboard, get a table. You got your
phone in your pocket. This is all you really
need.
Stop using agile. Start thinking about agility.
Dave Thomas
has a great, great article here that he just
posted about a couple weeks ago. Agile is
so
abused and so buzz word-y now, that you say
it, and managers who don't understand better
are like,
oh, that means we don't have to worry about
documentation. Great.
No, no, no. That's not. We, we're gonna work
in an agile fashion. Oh, no, no, no, no.
You gotta just say agility. Stop using agile.
Just
drop it from your vocabulary.
Measure everything. If you don't even know
what you're
gonna measure, just put Google Analytics on
it and
turn all the switches on. Just get data in
there. Because you're gonna go back and say,
what
were people clicking on? What were the paths
they
were taking through the system? And, especially
if you're
doing e-commerce, you can start seeing, checking,
like, figure
out your checkout flow and then you can document
that. Cause then you can go through and say,
hey, we get thirty percent abandonment on
this step.
Let's go back and look at that. What's going
on?
Love your users. Often, I know we get frustrated.
Cause we're like, they just don't get it,
blah,
blah, blah. Oh my god. You know, my parents
can't even do this. What's wrong with them?
And
it's really about you're, you know, we're
trying to
serve them. We're trying to make their lives
better
with the tools we build.
So, in doing that, we want to secure quick
wins. Whenever you can secure a quick win,
you
can build something fast, you can do it at
night when you go home and you've got ten
minutes and it's something you know you can
ship,
do it. Ship it. Get it out the door.
No more silos. Get rid of design as a
team. Get rid of engineering as a team. Everybody's
on build. Project managers. Everybody is on
one team.
And if you have a product, get that, get
a micro team. And it's made up of all
these people. Sometimes these roles are not
clearly defined.
Sometimes an engineer is also your product
and your
project manager.
I argue often that everybody should be QA,
but
sometimes you need a formal QA person who's
really
an expert at doing Selenium or something like
that
and can drive those automated tests.
But design, frontend, engineers. Everybody
sitting together, working together,
even if you're remote. Collaborating every
single day. Developers
are not excluded from design meetings. Designers
are part
of retrospectives.
Pull request workflow. Bruce and I do this
at
Cargo, since we start off empty pull requests,
to
discuss big ideas. And you start pushing against
the
pull request with that branch. And then if
it's
good, we pull it in. If it'd bad, we
leave it out.
Reusable design solutions. If you've got something
that you're,
you're generating, if you can reuse it, do
so.
Developers, learn UX. It's not scary. It's
not this,
like, I have to use photoshop. Go read some
books on usability. Defensive Design for the
Web by
37Signals is over ten years old, and every
single
word of it is still very applicable. Most
of
Jakon Neilsen's stuff. Rock, It's Not Rocket
Surgery, I
think. Steve Krug is a great author. Just
go
read some of these books.
You build things that work. You should know
why
they work, how they work, and how they work
efficiently. Likewise, go get your designers
to learn how
to code. If your designer doesn't understand
html and
css, at least, how can they possibly design
for
that medium? It's like a print designer not
understand
what happens when the ink hits the paper.
You
would not, it would not happen. Designers
need to.
They don't have to do the code, they need
to understand the code, though.
And forgive. Ann Patchett has a book called
the
Get Away Car. It's a practical memoir about
writing,
which is funny. I didn't realize David was
gonna
do this whole thing on writing when I, I
pulled this. My wife sent me this quote that
Andrew Sullivan pulled out, but the real short
of
it is, I'm just gonna read this real quick.
"Stop here for a few breaths and think about
this, because it's the key to making art and
very possibly the key to finding any semblance
of
happiness in life. Every time I have to set
out to translate the book, or story, or hopelessly
long essay that exists in such brilliant detail
on
the big screen of my limbic system onto a
piece of paper, I grieve for my own lack
of talent and intelligence. Every single time.
Were I
smarter, more gifted, I could pin down a closer
facsimile of the wonders that I see. I believe
that, more than anything else, the grief of
constantly
having to face down our own inadequacies is
what
keeps people from being writers. Forgiveness,
therefore, is key.
I can't write the book I want to write,
but I can and will write the book I
am capable of writing. Again and again, throughout
the
course of my life, I will forgive myself."
This doesn't just apply to you. This applies
to
your coworkers. This applies to your interactions
with everybody.
So build the app you can build today. Because
you can sit there and say, this process is
too hard. This is too complex. We'll never
get
this done. It's gotta start from somewhere.
And so, please try and climb the mountain.
I
know it's not easy, but you'll eventually
get there,
and it will be a better world for it.
Thank you very much, and. Appreciate it.