[? music ?] [Incorporating Lean UX into Agile Garren DiPasquale]

[Blend Conference 2013]

All right. Hey!

Welcome everybody!

Welcome to Integrating Lean UX into the Agile process.

[Garren DiPasquale Bank of America] I'm Garren DiPasquale.

I am a freelance consultant.

I currently consult for a very large financial institution.

I'm not supposed to say who they are.

You guys can figure it out.

Yeah.

I also do consulting for—like start-up companies, small business, and now do some speaking, as well.

You guys can follow me on Twitter—aduroguy.

I don't really tweet much, but it's a status thing, right?

There's a lot to cover here.

I really struggled to put—to get this into 45 minutes.

So forgive me.

We're going to have to skim across the top of how you do this and how you actually implement this on your Agile team.

How many of you here are on an Agile team?

Okay.

How many of you here are designers?

How many of you are developers?

Okay. Good. All right.

So we're going to kind of have to skin through the top, unfortunately.

We can talk afterwards.

You guys can ask me—we'll try to leave some time for Q and A so we can get into a little bit more detail

because I had to kind of just—you know—pick the highlights what I think.

Mostly I'm going to be talking from the experience that I have working right now at the team I work on.

I am the lead user experience architect on our Agile team.

We run 4 Scrum teams.

There are only 2 UX designers and 2—one of them is right here, actually—sitting right here.

John, wave at everybody.

Hi, John!

Then we have 2 UI developers, as well, and we kind of make up a core team of 4 UX/UI developers.

We're going to be talking about incorporating Lean UX, specifically, to get this done.

But before we get into that, we're going to kind of look at the history a little bit of where this Lean UX thing comes from.

But then we're going to move from just incorporating Lean UX to talking about actually embracing Agile as a designer

instead of just coping with it because I know that most of you in here probably feel like we're just coping with Agile.

That's kind of why we're here, right?

This Lean UX thing is becoming a big conversation in the UX community.

Jeff Gothelf has been doing a lot of work speaking about it and kind of coined the term.

As we mash these 2 things together—this Agile and this UX thing together—

we're starting to have to kind of try to figure this out.

So really what we have is we have these 2 disciplines.

We have user experience design—right—that businesses and corporations see valuable to their processes.

As things become and systems become more complicated and as software becomes more complicated,

we need user experience design to really just cover this all-encompassing space.

We have these people—that's what they do now.

That's their job is to holistically think about this and keep us aligned.

Along with that, the companies are also embracing design thinking,

which really, when I talk about user experience design, I talk really about design thinking.

I mean there's user experience design like we just saw on that graphic,

but I'm talking about it from like a big D perspective—from design thinking perspective.

No show notes, so this is—guys, I'm going to have to do my best here.

As companies embrace this design thinking more and they see it as valuable in the marketplace today,

we've got—on the one hand we've got them doing—we've got them embracing this design thinking.

I took this quote just straight from IDEO.

I think there's a lot of definitions of design thinking.

I felt like this one really resonated in me for the most.

"Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people,

the possibilities of technology, and the requirements for business success."

We're going to come back to this kind of later on, and we're going to kind of look at this

because I think that when we talk about embracing Agile as designers,

we're going to see how Agile can really allow us to do high-level design thinking and really bring together

the technology and business and human center design together.

This is just straight from their website—kind of sums it up, right?

Desirability, viability, feasibility—so at the middle of this diagram you have what they feel like is innovation.

On the other hand, we have Agile.

Companies need to be able to actually implement the software.

They need to be able to actually create the software.

They're having issues with that.

They're having issues with implementing software in these large corporations,

and Agile comes along and it's created by software developers as this methodology to help deliver software better, faster—

better for developers, better for the business.

It moves from this iterative process that software developers were working in.

It moves it into a linear process—sorry.

It goes from linear to iterative.

As a designer, I think this is where we get stuck.

It's not really meant to ask why.

It's intended to solve how.

Agile is not about saying why are we doing this or why should we do this.

It's about how do we do this.

How do we do this well?

How do we do this quickly and effectively and efficiently?

A lot of us are very frustrated with that because as designers we get paid to ask why.

Why should we be building this?

Why should we be doing this?

From the Agile manifesto just real quick—

individuals and interactions—I'm assuming that most people in this room understand Agile—know Agile—

we're not going to get too deep into it.

But individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

Agile says that they value the things on the left more than they value things on the right.

That doesn't mean the things on the right aren't valuable.

So what's a company to do?

We want user experience design because it's important to us,

and we want Agile because it's working for us.

So we'll just stick them together.

We'll put all these people together.

We'll mash them together.

Done!

Everybody gets along.

Great, right?

Unfortunately, it's probably a little bit more like this.

That's how most of us feel that the mash-up has been.

Right?

So before we criticize it too much,

I want to talk really briefly about the way—the way we've been doing things—right—the other way of doing things.

We're all very familiar with this process—waterfall process.

We're going to be kind.

We're going to call it the linear process.

Waterfall kind of has a bad name, so we're going to call it linear.

We're used to this—define, design, develop, test, deploy.

We really work in this define and design space,

which is really comfortable for us as designers because we get to do what we really love to do.

We get to do it in a controlled environment.

We get to do a lot of design up front.

In the design phase, we might be doing lots of research.

We get time to do this.

It's valued by the company.

This big design—this big design phase is valued.

Then what we do with it after that is really not our concern.

How it gets developed—no.

That's somebody else's job.

The problems with linear design is the design doesn't get implemented right

or it doesn't get implemented at all.

We do all this design up front.

We spend all this time, and it never really sees the light of day.

Customers never see it.

Our users never see it.

When they do see it, it's wrong because it got developed wrong—got developed incorrectly.

There's obviously circumstances where it goes okay.

It's been done this way for a long time so it's not imperfect always.

But I think we've all experienced seeing a lot of our work go to waste as designers because we spent 9 months to a year

on a project and by the time it actually got to the customer or the user,

it wasn't anything like we envisioned.

It wasn't our design.

It's wrong for the market despite our user research a lot of times.

So we'll do a bunch of user research but really by the time it gets out to the market,

it doesn't meet market realities.

Again, our design is not really for anything.

It doesn't offer anybody any value.

It misses feedback late.

It will give you a lot of feedback early in the process, but there's not a lot of feedback late in the process.

By that time, we've built up a lot of momentum, and we're trying to get the thing out the door.

There's really not time at that point.

You can't change the design at that point anyway.

You've done so much work up front that even if you got feedback, at this point,

no—it's going out the door this way.

So we have a lot of feedback early in the process but not enough late in the process.

It doesn't react to change quick enough.

In our marketplace and as things have gotten—

I mean, we've not had smart phones for that long.

I mean if you just think back—just try to think back before we had iPhones.

It wasn't that long ago.

The market moves really fast now—really fast,

and you can't spend 9 months to 12 months designing a solution for market that by the time it gets there the market's gone.

It's changed.

In short, we're going to hit the iceberg.

Leonardo DiCaprio freezes to death at the end.

So we're going to put them together, right?

We're going to do this together.

We're going to stick them together because that's what—that's the choice we have.

Right?

Whether or not you guys have made that choice to actively do Agile—I have.

I don't know how many people in this room have chosen as a designer—I know a lot of developers love the process.

But as designers, I don't know how many people are actively choosing to do Agile projects.

I love Agile projects.

I love doing design and Agile projects,

and I'm going to to try to convince you guys why you should love it too.

So we're going to incorporate Lean UX into Agile.

We're talking about Lean UX, specifically.

It's not the only way you can incorporate.

But we're going to use it as our method to incorporate the 2 together and make 1 cohesive process.

I'm putting the emphasis on incorporating because before the Lean UX book came out just recently,

the term was sort of in-flux, and Jeff Gothelf himself said that he called it Lean UX because he was trying to do UX and Agile,

but UX and Agile was already kind of a phrase.

He felt like you could do it outside of Agile, and you can do it outside of Agile.

You can do Lean UX in Waterfall.

You can do Lean UX for start-ups.

You don't have to do it with—it does not have to be paired with an Agile methodology.

However, now really when he talks about it and most people talk about Lean UX,

they're specifically talking about it in Agile.

It's pretty much—they're one for one now.

What is Lean UX?

There's a couple quick misconceptions.

The first one is it's a UX of one—that I'm only one designer and I have to be lean.

That's not the most common one, but I've heard that before.

Some people have felt like that was what it meant—that it's UX of one.

That's a whole other problem.

There's a lot of books and a lot of great stuff on that.

Leah Buley has some good stuff on Lean UX of one.

If you have that issue, there's a lot of good stuff out there to encourage you guys on how you can do UX as one designer.

On the project that we do, I started out as the only UX designer.

It has its own—it comes with its own inherent problems itself.

The other main misconception is that it's UX Lite.

Right?

So we're going to—we're going to do the light version of UX.

We're not going to do the research.

We're not going to do all these tools that we have in our toolkit.

We're going to do the leanest version of it.

We're just going to sort of kind of do sort of UX and make it fit into the Agile iteration.

What it really is about is getting rid of waste.

When we talk about getting rid of waste, we're talking about this from the Toyotaism lean manufacturing.

This all comes from lean manufacturing processes and methodologies.

We're going to go over this real briefly.

We're not going to spend a lot of time on this.

There's not enough time to get into all lean manufacturing—we're going to try to get as quick as we can to Lean UX.

But we want to look at this real fast because you'll start to see some parallels that come out of lean manufacturing

and then go into lean start-up.

The first one is reducing waste.

That's the biggest one about—I think Lean UX as designers—is reducing waste—

getting rid of as much waste as possible and getting to the efficient stuff we do as designers.

Just in time inventory—Toyota uses this to create parts that are just in time to create cars.

So they try to keep the least amount of inventory on hand,

and they try to create the things in line.

Continuous flow manufacturing—the same thing.

The idea here is to try to make one car at a time—only one car at a time.

That includes from creating the engine and having the engine show up on time, etc.

Measurable results and scientific methods—so these are KPIs—things like that.

So lean manufacturing, and then there was this kind of lean start-up movement.

It started in 2007-2008.

Eric Ries is—great books.

If you guys haven't read them, I suggest them.

I gave some away the last time I spoke.

I don't have any today—sorry.

"The Lean Startup," "Running Lean,"—I think there's another one now.

There's—I think there's an additional one now, as well.

They keys to lean startup—again—reduce waste, customer feedback.

This customer feedback loop in there.

Again, the continuous deployment process, right?

So moving into being iterative instead of linear, right?

So I want to continue deploying my design—getting it out to market as fast as possible,

getting out my business ideas to market as fast as possible instead of a bunch of design and then a release

and then a bunch of design and then a release.

Then validated learning and scientific methods again.

This is just using scientific methods to do design.

There's a lot of design thinking in lean startup.

It's mostly influenced from design thinking.

Then they introduced this build-measure-learn loop.

This starts to become the key to lean startup.

This will be the key to doing Lean UX—these small build-measure-learn loops.

When they talk about this, they're talking about this in really small batches.

This is build, measure, and learn as quickly as possible with the smallest thing as possible—

building the small thing—the minimum viable product in lean startup.

It's build what I have to build to get it out there and measure it.

Then I can iterate on that over and over and over again.

Then Lean UX.

This is—primarily, the thought leader on this is Jeff Gothelf, which I'm probably butchering his last name.

He's got a book out now, "Lean UX."

It showed up at my door yesterday.

I skimmed through it trying to make sure that I wasn't full of crap.

He came up with a lot of these processes from reading "Lean Startup" and talking to Eric Ries and whatever,

while he was at The Ladders.

He was the user experience director at The Ladders.

At The Ladders, they decided that they were going to do Agile.

They didn't tell any of the designers.

They just showed up one day and said, "Hey, we're going to do this Agile transformation project."

"We're going to have a boot camp."

"We're going to train all of you guys on how to do Agile."

"We're going to stick you together, and everybody's going to be great, and we're going to make awesome stuff faster."

"And it's going to cost us less money and everybody's going to be happy."

He's got some great stuff online about how they felt about this.

His team put together this document of—like why Agile sucks.

Then—like handed it to them.

They have all this funny—so go out there and Google it.

It's pretty good.

They hated it!

They hated it!

Because he—they had this issue—right—where it just did not get along.

They could not get this stuff to get along.

So what he starts to do is he starts to think about—okay—how can we make this process work?

Some of the keys to Lean UX are design is a hypothesis.

We'll get into this a little bit more, but it starts to get us to human-centered design where we don't make assumptions,

or if we make assumptions, we test those assumptions as opposed to doing genius design where we just assume that we know

exactly what our user wants.

We don't test it.

We just stick it out there.

Build the simplest thing first.

Again, that MVP.

Build things small.

Collaboration—we'll get into this when we talk about implementing.

Again, this build-measure-learn loop.

We're going to see how we break this down into the Agile sprint.

We see the build-measure-learn loop.

Everything is an assumption in Lean UX.

It's very key to doing Lean UX.

All your designs are assumptions,

and you're going to test everything as much as possible.

We'll get into how feasible that is because we don't get to test everything—not near as much as I'd like to.

But there's still some ways to kind of test internally and to validate some of your assumptions.

So as it starts to break down, Lean UX has this process where we go from concept to prototype.

We validate internally.

Then we test externally.

Then we learn and we iterate on that—over and over and over again.

We're going to apply this to our sprints—our Agile sprints.

We're going to move away from this process where we try to do all that up front and then deploy,

and we're going to move it into this iterative sprint model.

So implementing this on your Agile team.

This is not mini waterfall.

All right.

So if you try to take everything you do now and cram it into 2 weeks,

which is what a lot of us have tried to do before in the past, you're going to fail.

It's not going to work.

You cannot take the user experience in the design process and just cram it into 2 week sprints and try to do that.

That's what they tried to do first at The Ladders.

That's what most companies try to do at first when Agile is introduced to their—to their shops.

The design team says, "Okay. We're going to do everything we're doing now, we're just going to do it really, really, really, really fast."

"And we're going to have whiteboards, and that'll make everything better."

Right?

If you don't embrace moving away from what we're used to as designers and working in these linear paths

and moving toward an iterative design process, it's not going to work.

The first big key of integrating Lean into Agile or Lean UX into Agile is getting your mindset set to we want to do things iteratively

and kind of break some of our old habits of trying to do everything linearly.

Stop passing everything over the wall.

We're going to look at implementing in the room, within the sprint, and then last—

Lean UX doesn't cover this too much, and I'm going to cover it briefly—is just how do we also do holistic design within Agile.

Lean UX primarily is talking about within the sprint.

The book briefly goes into some stuff on how to handle is holistically.

I have a couple tools that we use at work to keep us on track holistically.

So in the room.

Start with cross-functional teams.

Now in Agile, we already have cross-functional teams.

It's part of the Agile manifesto.

Right?

It's about building these cross-functional teams where you have all these different people, all these different players.

What we're going to do is we're going to leverage that as designers.

We're going to start to become design facilitators instead of just designers,

and we're going to facilitate our cross-functional teams to help us do design.

We're going to get everyone involved in the design,

and this is huge.

Design workshops—design studies—whatever you want to call them—not just for the designers.

Bring your devs into it.

Bring your TAs.

Bring your business into it.

Everybody can't always attend.

People are busy coding.

People are busy doing their work.

At a previous company, what we did is we just did open-door design workshops.

So we would kind of have a cue—we would have some key designers that were going to facilitate the workshop.

We would figure out who was going to do what.

Then we would sort of send out an invitation to anybody that wanted to come.

We got really good response from that.

We would get some BAs in there.

We would get some developers in there from time to time.

We would get a good group.

Everybody couldn't make it every time, but—you know—we'd get a good mix of people.

I couldn't come this time, but I can come next time—that type thing.

So we want to get everybody involved in the design process.

Developers have good design ideas.

Business people have good design ideas.

We need to start facilitating that design amongst our team,

and it's going to help us build more of a cohesive team as the design being owned by the team.

In Agile, the team is central.

We want to start—we want the team to start to own the design, as well.

We're going to promote cross-functional pairing.

So this is—you know—I don't know if you guys—anybody do pair programming?

Any developers in here do pair programming?

So we do cross-functional pairing.

How many of you guys pair with your designers?

All right—2 people—awesome!

We want to encourage things like cross-functional pairing.

So this is design and developer sitting down together and working on the problem together.

This is really great because I can design—like a pixel-perfect design,

and then I give it to the developer and he's like, "Dude, we can't do this."

"We have IU-7 support, man."

You know?

So we sit down now at the machine together a lot of times and work through those problems in real time.

Because I can make those decisions as a user experience expert and the architect in the room—right—as the developer tells me

the constraints that we have that maybe I didn't consider.

So we'll sit down, we'll open of Firebug, and we'll just start tweaking the—we'll just design in the browser.

When we get something we like, he'll copy the code over, I'll take a screen grab,

and we'll attach that to the story, and we've done the design.

The work is done already.

Then we'll just go implement that.

We want to break down these silos.

The cross-functional team is important to breaking down the silos.

We want to get out of "I'm a designer. You're a developer. You're a BA. You're this."

We want to start being more inclusive in our roles and—I mean—we can't—

I can't—I'm not going to be the BA.

I am the designer.

I'm not going to be the BA, but I can take part in some of the things that they do and have empathy for what they have to do.

I can have empathy for what the developer has to do.

The developer can learn empathy for what I have to do.

As we do that, the team starts to build together, and it starts to own the design as a team,

instead of me being the designer and you guys being the developer because that's horrible.

That's a terrible environment.

I have that environment because we're always mad at each other.

Right?

The developers are always mad at me because I design things that are too hard.

I'm always mad at them because they never develop anything that I want to design.

Right?

So we're going to break down the silos, and we're going to stop passing things over the wall.

I'm going to stop just giving them stuff and saying—like—go do your job.

Yep?

[male] —BA?

Business analyst—sorry.

I've been at the financial institution a little too long.

I'm starting to pick up a lot of acronyms.

Get out of the building.

We do this as designers.

We have this as one of our tenets—

get out of the building, do contextual inquiries—those type things.

But this is really meant as a team—everybody get out of the building.

We have gone on trips.

We've gone down and seen our users, and we go together as a team.

We take developers there, designers down there—everybody goes down there and sees the problem.

When you see the problem you can have empathy for the user and now my developer has empathy for the user.

Now he's starting to become a user experience expert.

He's starting to say, "Well, that sucks for them."

"I was down there and that really—like we should do that better."

Then they start to have ideas on how we can do that better.

Design rockstars down't work well.

So if you are a design rockstar—some people really are, and they're really good at it.

It's probably not the best environment for you.

You're going to—you're not going to probably meld well with the team very well.

It's going to be difficult for the team, and you're going to end up just creating silos and kind of creating the separation again.

So if you're a design rockstar and you want to keep being a design rockstar, you probably want to move out of Agile.

We'll get into why you don't want to be like that in a minute.

But anyway, design rockstars don't work very well.

Shared understanding.

In the room shared understanding is really key to making this process work.

Agile room—right—just crap everywhere.

This is—I have no idea whose office this is.

Google images—I couldn't take a picture of our office, and it was midnight so—

But we got all of our stuff up on the wall.

We put all of our things up there.

It's more than just the—like the Agile board.

It's more than our Agile board—our day-to-day.

They call our room the clubhouse because we've got all kinds of crap on the wall.

We've got a picture or Ricky Bobby—all kinds of stuff.

We put sketches up on the wall, and we put tenets of our design up on the wall.

We put stupid quotes that we say in stand-ups that are ridiculous—put those on the wall, too.

We make it a fun place, but a lot of it is just getting this stuff out of your head and onto the wall.

Like externalize your work—get if off your machine.

If it's in a SharePoint, nobody's looking at it.

Right?

Get it up on the wall.

Print it out.

Make a sketch—whatever.

Get those things up on that wall so that everybody is seeing what you're thinking.

Everybody has—when we do sketches, we put them up on the wall afterwards.

They go stale.

They're up there forever.

We end up throwing them away eventually, but we externalize that work.

We get it up on the room so that everybody can have that shared understanding.

Then discussing and sharing the vision.

This seemed really simple, but I put it in here because I take a lot of time out of what I'm doing to just get in discussions.

I'll be over there doing whatever and somebody will start talking about something and I'll overhear it.

They'll kind of look over and see if I'm paying attention.

Then I'll drop what I'm doing and go and get involved in this discussion.

Those, quite honestly, drive our holistic vision probably more than anything else—

just getting in discussions together, in the team room, talking about things.

It's my opportunity then to share the holistic vision again, to remind people of our vision again,

to say, "No, we don't want to do that, and this is why."

There's discussions that I'll miss, and they'll make decisions without me.

I don't get that input.

I don't get to be the advocate of the user in those discussions.

A lot of it is just being available to do that and not putting yourself—not holding up yourself behind—in your cube or whatever.

We don't have cubes.

We're in big open rooms so you can't hide.

But just being willing to get in—and sharing and getting into discussions.

Within the sprint.

Iteration meetings.

Most of you here probably do scrum.

It's the most popular, especially amongst big corporations.

How many of you guys do scrum?

How many of you don't do scrum?

Extreme Programming?

What do you guys do?

Kanban—okay—all right—cool.

So it—this is not necessarily specific to scrum, but scrum kind of has a lot of meetings.

I'm not a big fan of meetings, but that's a different discussion.

If you've read this book "Rework," which is really great,

they pretty much say meetings are toxic—like never have a meeting.

I think it's unrealistic, but I'm not a big fan of them.

But we have grooming.

We have planning, and we have story writing.

We're active in all of these meetings.

In fact, we spend a lot of our time in these meetings.

It's unfortunate that really we spend sometimes too much time in these meetings.

But they're really important to our process.

We spent a ton of time in grooming.

It is pretty much our key opportunity time to help shape the stories, help shape the direction,

help keep things driven on a holistic vision.

We want to be part of planning, and we want to be as best as you guys can—if you can get in—

if you can move yourself into working with the business to write stories, that's excellent.

Some places will be a little weird about that at first, and it take some time.

But you want to get where you can write stories with the business and write your own stories.

This was a grooming meeting—5 hours.

That was like another 5.

I didn't go to it.

I'm not going to a 5-hour meeting—I'm sorry.

At some point, you have to push back, right?

So it can get a little out of hand.

But, again, it's really important you guys participate in these activities—these Agile activities because it's part of growing

cohesively together as a team, and you can do your own work, too—push back on meetings.

There's lots of great stuff out there on how to make meetings better and how to facilitate better meetings.

Look into that.

Try to do your best to work that out, but it's important.

Concepts and prototypes.

Lean UX pretty much relies heavily on concepts and prototypes,

and it was really where the conversation started with Lean UX was—it started with this whole kind of get out of deliverables business.

There's a bunch of blog posts on getting out of the deliverables business.

There's some pod casts with Jared Spool,

and that's what they kind of started talking about was getting out of this deliverables business.

It pretty much meant—like stop delivering 50-page wireframes with all in the annotations.

It is not your job as a designer on an Agile team to distill the story for the developer.

That's a lot of times what we end up doing.

Right?

I like developers.

Don't get me wrong.

Don't take this defensive.

I've worked as a front-end developer, as well.

Pretty much, if I don't have to read the story, I'm not gonna.

If you're going to give me a picture with all of the things that I have to do—like I'm gonna do that instead.

So if I can get you to give me better pictures with more stuff and I don't have to go through some stupid Excel document that's attached,

I'm going to do that.

So that's what you'll become.

You'll become the person that sits there all day long and figures out what all of the different requirements are for this story

and distills them into a nice wireframe with really good annotations so that you can hand it to the next person.

You become a communicator, and that's all you do.

You just communicate specifications to the next person.

We want to get away from that.

We want to do as much concepting and prototypes as possible.

We're going to look at iterating this process, but we start with sketches.

Stop wireframing.

Get out of the computer.

Start with sketches.

Get your early ideas as quickly out as possible.

You're doing those design workshops—right—like developers will do sketches.

Designers will do sketches.

Everybody can sketch.

It doesn't have to be good.

This is actually a pretty good one.

This is from—this one is actually from an Adaptive Path workshop.

This is a pretty good one.

There are much worse than this.

Mine are terrible.

Mine are—like hard to comprehend.

They're chicken scratch, right?

But they're enough that I can say, "This is my idea."

"Okay. We've got something we can go with here."

"Yeah, we kind of like that," or "Let's throw that one away."

"Let's try this again."

We're going to do a bunch of divergent thinking before we start to converge on one idea.

We do that low fidelity first—lowest fidelity as possible.

Then we start to iterate that fidelity.

So then I might have to move it into a wireframe.

I try not to, but we might have to move it into a wireframe to prove something out.

What we'd like to do is move straight from the sketches to prototyping.

It does not always work that way.

We can't always do that.

We don't always have the time.

When I prototype, I'm prototyping in HTML, CSS, and JavaScript.

I'm making—you know—I'm making mock software so that I can hand that to the next person and say,

"This is how I want it to work."

"When you click that, this is how long it should take."

"It should take this long for that thing to show up."

Because I have control of that.

Not of all of you guys in here have those development skills.

You can pair with your developer to do that type of prototyping if you don't.

You can things like Keynote Kung-Fu or whatever—do your stuff in Keynote.

Make it clickable, right?

The point of this is I want to be able to show this to the business.

What I can show you working is so much better than wireframes and annotations will be ever be.

I will miss an annotation.

I'll forget to annotate that that thing is supposed to show up this fast, etc.

There's so many minute interaction details that I can't cover in a wireframe.

But if I can show you how it works, that is—that's much easier for me to build.

I can see how it works.

I can see when I click on this it should do that.

When we're proving this stuff out to the business and we're handling new patterns,

we want to show them how we want it to work.

If I show them wireframes, they get—they're like why is that misspelled?

I'm like because I'm a designer.

I don't know how to spell.

What does that matter?

It's not going to be misspelled in the app.

They'll focus on things like that or—like what is lorem ipsum and things like—you know.

I can't make these pixel-perfect—

We want to prototype as often as possible.

Research and testing.

This is a huge one I think for user experience folks in Agile.

We feel like we don't get to do any research and any testing anymore.

We don't have the time for it because research—it does take time.

Good research does take time.

I'm not a researcher.

I know researchers, and they're like—I know research user experience people, and they're crazy about research.

It's awesome, but good for them.

One day every iteration.

One day every iteration devoted to research.

John can look at me and say I'm full of crap because we don't do this.

I would love to do this.

This is something that we're striving towards.

This is not something that you guys are going to get day one.

This takes time.

We're getting close to this now.

We've been—we're on the—22nd sprint.

I mean, we've been doing this for a while.

It's taking time to develop this process.

But we're getting much closer to this one day every iteration of nothing but user testing,

and it's super-simple.

Three to five people—no more than five people.

You won't have enough time.

It's test everything—test anything.

It does not have to be a formal usability test.

You could do just a user interview.

You could do some card sorting—whatever—just get anything.

Get your sketches in front of them.

Ask them their opinion.

Do some co-design with the actual users.

"Hey, how do you think this should work?"

"What are your thoughts on this?"

And sketch with them.

We don't have the opportunity to actually get face-to-face with users so we use web accent email.

I send a bunch of stuff to users via email.

I have key users.

When we met them in facilities or whatever, I got their email,

asked them if I could contact them, send them things,ask them questions.

So we have a lot of contact with our users just that way.

You could do email diary studies—things like that.

There is still opportunity to do the work that we want to do as user experience architects and as designers

that can fit in this framework.

We'll get to that in a minute, okay?

Yeah.

We'll have to cover a lot of these type questions.

I'm going to try to get through.

We have Q and A because there's a lot of stuff I can't get—we're just kind of going over the top of it.

But we'll get to that in just a minute.

I think.

Hold me to that.

Validate internally and then externally.

We do a lot of validation internally.

When I say we don't test, it's not actually totally true.

We don't get to test as much with our end users as we would like.

We, unfortunately, have to wait to we have the release, which we still have staggered releases because we have to go

with other software that's on Waterfall—blah, blah, blah, blah.

We don't get to go every 2 weeks like we'd like to.

But our releases are pretty close.

I think they're every 3 to 6 weeks now.

Our stuff gets out there pretty quick.

We get our feedback then.

Unfortunately, sometimes it's wrong and it's bad and our assumptions are wrong and we have to fix it.

But a lot of what we do is validate internally.

This is that—if you guys are customer-facing, this is lunchroom testing, etc.

My application is internal-facing so it's a little bit different.

But you can do lunchroom testing.

You can take things out in the lunchroom, show people paper prototypes, test it with people in your organization

that don't know about your project—those type things.

You can do a lot of that validation internally.

Validate within your team.

A lot of times we just throw stuff up on the projector and—like the developers will tear it to shreds.

They'll be like—you know—because developers know how to use things.

They are usability experts.

They use computers all day long.

We all—you know—you guys use Twitter or Facebook.

You use these services—Google.

You guys are very familiar with good UI, good user interface, good user interaction.

A lot of times we'll just throw it up on the projector, and we'll get feedback right in the room.

We get a lot of good feedback that way.

A lot of times we'll find things that are just—I way over-thought something or we'll get a really good suggestion to just do it simple.

Somebody will have an idea—like why are we going—why are we doing that so complicated?

Why can't we just do this instead?

There'll be kind of an aha—like, yeah, that's a good idea.

Because I don't know what I'm doing.

It gets this—starting to do this build-measure-learn.

We're starting—we're going to do that in the sprint over and over and over again.

We're going to build either a concept prototype—it might be the actual code.

We're going to measure that with research.

We're going to follow along with some—we'll talk about holistic in just a second.

We're going to follow along with some of our design patterns and some of our holistic design strategy,

and we'll kind of validate that what we're doing is right there in the measure.

Jeff Gothelf does—their Agile teams are problem statement focused, which I think is a really awesome idea.

It's the first time I've heard of it just recently.

Instead of their Agile teams being aligned to features and functionality, they actually align them to problems—

to the problem statement so the team is actually working on a problem statement.

That, I can see would really fit into this build-measure-learn loop because then I have this problem statement

and I can start to measure against our problem statement.

The example he gave at The Ladders was there was a connections team,

and the whole point of that team was to get people on The Ladders to connect more.

All right.

So their problem statement was we need—we're trying to get more people to connect.

Whenever they would do this build-measure-learn, they have something to measure.

Are more people connecting?

Not versus did we just build the code good or is our code coverage up, etc.

Then it doesn't leave just the design team in the business of validating and trying to measure and learn from.

It puts the entire team into perspective.

That's something that I'm actually going to take back from just putting this talk together and work on doing more where we work

and try to align us more to that problem statement because I like that idea a lot.

Lastly, holistically.

Last but not least.

This is the one that I spend probably most of my time as the user experience architect on our team working on—

trying to drive holistic vision inside of Agile.

Lean UX helps us a tone within the sprint, but there are still some problems with Agile that I've found

that make it really difficult to do big picture design in these little, teeny sprints.

The business tends to not want to let us think outside of that space.

They say, "Well, no, we're working on this this 2 weeks or this 3 weeks or whatever."

"What are you doing thinking about that?"

You're trying to argue, "Well, we've got to think about that."

"If we don't think about that then how do we know what to build today?"

Agile sort of—kind of—[audience applause], right?

If we don't think about that, how do we know what to build today?

Agile is saying, "Well, we'll just re-do it."

"We'll just fix it."

It's iterative, so we'll just—we'll re-build that.

You're saying, "I can't design this today if I don't know how that fits into that tomorrow."

So holistically we have some tools that we're using, and I think they're working pretty well.

We're doing a pretty good job, at least that's what people tell me.

Develop your design principles.

You can do this at any point.

You guys could go back tomorrow and do this so you don't have to do this at the beginning of the project.

A lot of you have design principles that are in your head and that you're using to do the design.

You've kind of got them up there and you're using them to lead where you're going.

Get together with your business, your product owner, your team.

Start to jot down what some of those design principles are.

Our document is 2 pages, and it's not amazing at all.

It's pretty simple.

It started out as a concept.

The business asked me to do a concept for what our application would start to look like holistically.

So we did the concept and everybody liked that.

This was just a presentation.

This wasn't like a—we didn't really do much design.

We did a little IA and some layout.

Then out of that came a bunch of principles that we got from doing—getting out of the building and seeing our customers

and seeing our users, and we were starting to see some of the problems and kind of really what we wanted to fix.

The business was saying what they wanted to fix as a company and how they wanted to be tomorrow.

We started to kind of meld those together.

We put this concept together, and the business was very happy with it.

I said—I took a little risk, and I said, "Well, can we make these our design principles that we design to?"

And they said, "Yeah."

We put it in our Wiki, and those are our design principles now.

Business has sign-off on them.

So when we start doing things, I cite these things all the time.

I'm saying all the time, "Well hey, look, we have design principles."

The business says that they want this—that they want this type of design and that doesn't match.

So what do we need to do as a team to fix that?

The team is really starting to get on-board with it.

They're starting to understand these design principles.

They're starting to do them themselves.

They're starting to call them out.

Developers will come to me and they'll point out inconsistencies when the application doesn't meet our design principles.

So we get key buy in, and we stick to them, and we cite them often.

They become our principles—our guidelines to work by.

Then we adjust them when needed.

It's Agile.

The project changes, the project moves.

You can't have design principles that are set in stone.

These did not come down from the mountain and give your design principles to your developers.

This is work together as a team to develop these design principles and get everybody on-board with them.

Then, when they need to be adjusted, don't be afraid to crack open the document, adjust them, and move forward.

Pattern libraries and style guides.

Super important.

This is sort of like our third UX person is these pattern libraries and style guides.

Without them, I don't really know what we'd do, and currently—the state that they are—these are not ours.

These are just quick examples.

Currently, the state they are is kind of scary.

I've got a lot of work to do when I get back to work on Monday.

But they're not just for designers.

This, again guys, look into pattern libraries, and there's a lot of really great stuff on how to do a good pattern library.

They're kind of tricky.

There's some strategy to doing them right and doing them wrong.

Key ones are they're not just for designers.

These are not just for the designers in the room.

These are pattern libraries for the entire team.

Again, in Agile, it's about the team.

It's not about designers and developers.

They have to have input into this pattern library.

They have to have ability to push back when there's a pattern that they think doesn't fit or they don't like the implementation behind it.

It's got to be team input into this pattern library.

It has to be accessible to everyone.

If you are like the master keyholder of the pattern library and you have to give people access to it

and—you know—go make them like—"Oh, I need access to the pattern library."

"Okay. Put your name in, and then I'm going to give you—like read only."

That's not going to work.

People are not going to use it.

Everybody has to have access.

People need to be able to edit it.

In Agile, trusting the people your work with is key.

So don't try to lock it down and try to control it and be the designer that owns the pattern library.

It needs to be curated and updated as often as possible.

We'll look in a minute where we attempt to do this.

Again, this breaks down sometimes, but I think we're doing an all right job.

How we curate and update the pattern library—we put code in our pattern library.

So we have our own UI guy.

He puts code in it.

When we have a pattern, we have the style for that pattern, we have the code for that pattern—pretty much everything you need to implement

that in the software, we try to put that in the pattern library.

We use Wiki to do it, unfortunately, because that's the software we can use.

There's some software out there, depending on how you guys are locked down,

there's some software out there that you can use to do pattern libraries.

How are we doing on time?

Okay.

Story maps.

This is a feature hierarchy of the backlog.

We have 4 different products running different directions.

There's like a thousand stories.

I need to be able to see all the stories that the business is writing.

It helps me key an eye on the big picture.

This is just an example.

So I organized it by feature.

I don't care about the prioritization of the business.

I care about the prioritization of features.

We can mark out the releases.

So when we look at the iteration, this is our iteration.

We start on a Wednesday.

I have no idea why.

We do our workshops and our design sessions—try to do them at the beginning.

Testing is scheduled for Thursday.

We'll do something low fidelity on a Friday.

The majority of the sprint will be for design.

Monday we document because we're getting ready for demo.

Tuesday is demo day.

We watch movies and demo.

Shoot.

I'm going to have to fly through this, guys.

I'm really, really sorry.

This is—I'm at 45 minutes.

Moving beyond incorporating Lean UX and embracing Agile.

I think we can embrace it.

Agile is human inherently.

It is human-based.

It's about people over process.

It's in the manifesto.

Cite that often.

Encourage that in your teams.

It offers us design constraints, which I think are really good as designers.

When we have no design constraints, we tend to not do a very good job with our designs.

If you give me a month to make something, I will use up all of that month,

and I'm probably going to do the best design on the last 2 days.

Forced deadlines are really great for designers—11th hour design.

I do good design in the 11th hour.

When I'm forced to have to come up with something creatively really quickly and I'm out of time,

that's usually when I do my best work.

I don't do my best work at the beginning of the sprint.

It gives us room for failure and, as a designer, I am—I love this.

Because it doesn't have to be perfect.

My design does not have to be perfect day one.

If I get it wrong, I'm not going to—like waste a million dollars of some company's money on a product that we spent 9 months

developing and then we put it out in the market and the design wasn't any good.

I have time to iterate that design and make—you know—there's room for my mistakes.

Team ownership.

It compliments and encourages good user experience.

This process really helps us do better user experience.

A lot of times we say we do human-centered design and we're not doing human-centered design.

We're going genius-design, and we're calling it human-centered design and really just nobody calls us out on it.

I'm guilty of doing that.

This encourages us to do human-centered design, to do this iterative loop, and to get feedback.

Responding to change over following a plan.

This process itself is iterative.

I can turn the design process towards the process itself.

I can use my design to make our process better.

I can figure out what works for our team versus another team.

It's not dogma.

Agile is not dogma.

It's Agile.

It's supposed to change.

You're supposed to be able to adapt it.

Change is okay.

Really, I think it culminates into this entire process—when you take Lean UX and you put it into Agile,

and we start facilitating design as designers, I think it's design thinking.

I think you can say about Agile and Lean UX, it's a human-centered approach to innovating to integrate the needs of people,

the possibilities of technology, and the requirements for your business."

Thanks, guys!