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.