Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
UX Track: Incorporating Lean UX into Agile - Garren DiPasquale
48:32 with Garren DiPasqualeDesigning holistically within a short iteration agile environment can be complicated. Incorporating lean principals into your agile process can help you create better software that aligns to a holistic user experience strategy. We'll cover strategies from the lean playbook as well as other practical processes to move from coping with the agile process to embracing it.
-
0:00
[? music ?] [Incorporating Lean UX into Agile Garren DiPasquale]
-
0:01
[Blend Conference 2013]
-
0:04
All right. Hey!
-
0:05
Welcome everybody!
-
0:07
Welcome to Integrating Lean UX into the Agile process.
-
0:10
[Garren DiPasquale Bank of America] I'm Garren DiPasquale.
-
0:12
I am a freelance consultant.
-
0:14
I currently consult for a very large financial institution.
-
0:18
I'm not supposed to say who they are.
-
0:19
You guys can figure it out.
-
0:21
Yeah.
-
0:26
I also do consulting for—like start-up companies, small business, and now do some speaking, as well.
-
0:34
You guys can follow me on Twitter—aduroguy.
-
0:37
I don't really tweet much, but it's a status thing, right?
-
0:45
There's a lot to cover here.
-
0:47
I really struggled to put—to get this into 45 minutes.
-
0:53
So forgive me.
-
0:54
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.
-
1:00
How many of you here are on an Agile team?
-
1:04
Okay.
-
1:06
How many of you here are designers?
-
1:08
How many of you are developers?
-
1:11
Okay. Good. All right.
-
1:12
So we're going to kind of have to skin through the top, unfortunately.
-
1:16
We can talk afterwards.
-
1:18
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
-
1:23
because I had to kind of just—you know—pick the highlights what I think.
-
1:27
Mostly I'm going to be talking from the experience that I have working right now at the team I work on.
-
1:32
I am the lead user experience architect on our Agile team.
-
1:36
We run 4 Scrum teams.
-
1:38
There are only 2 UX designers and 2—one of them is right here, actually—sitting right here.
-
1:45
John, wave at everybody.
-
1:46
Hi, John!
-
1:48
Then we have 2 UI developers, as well, and we kind of make up a core team of 4 UX/UI developers.
-
1:56
We're going to be talking about incorporating Lean UX, specifically, to get this done.
-
2:01
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.
-
2:08
But then we're going to move from just incorporating Lean UX to talking about actually embracing Agile as a designer
-
2:14
instead of just coping with it because I know that most of you in here probably feel like we're just coping with Agile.
-
2:24
That's kind of why we're here, right?
-
2:25
This Lean UX thing is becoming a big conversation in the UX community.
-
2:31
Jeff Gothelf has been doing a lot of work speaking about it and kind of coined the term.
-
2:38
As we mash these 2 things together—this Agile and this UX thing together—
-
2:42
we're starting to have to kind of try to figure this out.
-
2:45
So really what we have is we have these 2 disciplines.
-
2:47
We have user experience design—right—that businesses and corporations see valuable to their processes.
-
2:55
As things become and systems become more complicated and as software becomes more complicated,
-
3:00
we need user experience design to really just cover this all-encompassing space.
-
3:05
We have these people—that's what they do now.
-
3:07
That's their job is to holistically think about this and keep us aligned.
-
3:16
Along with that, the companies are also embracing design thinking,
-
3:19
which really, when I talk about user experience design, I talk really about design thinking.
-
3:25
I mean there's user experience design like we just saw on that graphic,
-
3:28
but I'm talking about it from like a big D perspective—from design thinking perspective.
-
3:37
No show notes, so this is—guys, I'm going to have to do my best here.
-
3:45
As companies embrace this design thinking more and they see it as valuable in the marketplace today,
-
3:50
we've got—on the one hand we've got them doing—we've got them embracing this design thinking.
-
3:55
I took this quote just straight from IDEO.
-
3:57
I think there's a lot of definitions of design thinking.
-
4:00
I felt like this one really resonated in me for the most.
-
4:03
"Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people,
-
4:08
the possibilities of technology, and the requirements for business success."
-
4:13
We're going to come back to this kind of later on, and we're going to kind of look at this
-
4:17
because I think that when we talk about embracing Agile as designers,
-
4:22
we're going to see how Agile can really allow us to do high-level design thinking and really bring together
-
4:31
the technology and business and human center design together.
-
4:39
This is just straight from their website—kind of sums it up, right?
-
4:43
Desirability, viability, feasibility—so at the middle of this diagram you have what they feel like is innovation.
-
4:50
On the other hand, we have Agile.
-
4:53
Companies need to be able to actually implement the software.
-
4:56
They need to be able to actually create the software.
-
4:59
They're having issues with that.
-
5:01
They're having issues with implementing software in these large corporations,
-
5:04
and Agile comes along and it's created by software developers as this methodology to help deliver software better, faster—
-
5:12
better for developers, better for the business.
-
5:15
It moves from this iterative process that software developers were working in.
-
5:19
It moves it into a linear process—sorry.
-
5:22
It goes from linear to iterative.
-
5:26
As a designer, I think this is where we get stuck.
-
5:27
It's not really meant to ask why.
-
5:30
It's intended to solve how.
-
5:33
Agile is not about saying why are we doing this or why should we do this.
-
5:37
It's about how do we do this.
-
5:39
How do we do this well?
-
5:40
How do we do this quickly and effectively and efficiently?
-
5:42
A lot of us are very frustrated with that because as designers we get paid to ask why.
-
5:48
Why should we be building this?
-
5:50
Why should we be doing this?
-
5:53
From the Agile manifesto just real quick—
-
5:55
individuals and interactions—I'm assuming that most people in this room understand Agile—know Agile—
-
6:01
we're not going to get too deep into it.
-
6:02
But individuals and interactions over processes and tools.
-
6:05
Working software over comprehensive documentation.
-
6:09
Customer collaboration over contract negotiation.
-
6:12
Responding to change over following a plan.
-
6:15
Agile says that they value the things on the left more than they value things on the right.
-
6:18
That doesn't mean the things on the right aren't valuable.
-
6:20
So what's a company to do?
-
6:25
We want user experience design because it's important to us,
-
6:29
and we want Agile because it's working for us.
-
6:31
So we'll just stick them together.
-
6:32
We'll put all these people together.
-
6:34
We'll mash them together.
-
6:36
Done!
-
6:37
Everybody gets along.
-
6:38
Great, right?
-
6:39
Unfortunately, it's probably a little bit more like this.
-
6:42
That's how most of us feel that the mash-up has been.
-
6:46
Right?
-
6:48
So before we criticize it too much,
-
6:49
I want to talk really briefly about the way—the way we've been doing things—right—the other way of doing things.
-
6:55
We're all very familiar with this process—waterfall process.
-
6:58
We're going to be kind.
-
6:59
We're going to call it the linear process.
-
7:01
Waterfall kind of has a bad name, so we're going to call it linear.
-
7:05
We're used to this—define, design, develop, test, deploy.
-
7:09
We really work in this define and design space,
-
7:13
which is really comfortable for us as designers because we get to do what we really love to do.
-
7:17
We get to do it in a controlled environment.
-
7:19
We get to do a lot of design up front.
-
7:20
In the design phase, we might be doing lots of research.
-
7:24
We get time to do this.
-
7:26
It's valued by the company.
-
7:28
This big design—this big design phase is valued.
-
7:31
Then what we do with it after that is really not our concern.
-
7:36
How it gets developed—no.
-
7:39
That's somebody else's job.
-
7:41
The problems with linear design is the design doesn't get implemented right
-
7:46
or it doesn't get implemented at all.
-
7:48
We do all this design up front.
-
7:49
We spend all this time, and it never really sees the light of day.
-
7:52
Customers never see it.
-
7:54
Our users never see it.
-
7:55
When they do see it, it's wrong because it got developed wrong—got developed incorrectly.
-
7:59
There's obviously circumstances where it goes okay.
-
8:03
It's been done this way for a long time so it's not imperfect always.
-
8:08
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
-
8:16
on a project and by the time it actually got to the customer or the user,
-
8:20
it wasn't anything like we envisioned.
-
8:22
It wasn't our design.
-
8:26
It's wrong for the market despite our user research a lot of times.
-
8:32
So we'll do a bunch of user research but really by the time it gets out to the market,
-
8:37
it doesn't meet market realities.
-
8:38
Again, our design is not really for anything.
-
8:42
It doesn't offer anybody any value.
-
8:46
It misses feedback late.
-
8:48
It will give you a lot of feedback early in the process, but there's not a lot of feedback late in the process.
-
8:52
By that time, we've built up a lot of momentum, and we're trying to get the thing out the door.
-
8:56
There's really not time at that point.
-
8:57
You can't change the design at that point anyway.
-
9:00
You've done so much work up front that even if you got feedback, at this point,
-
9:03
no—it's going out the door this way.
-
9:05
So we have a lot of feedback early in the process but not enough late in the process.
-
9:10
It doesn't react to change quick enough.
-
9:12
In our marketplace and as things have gotten—
-
9:14
I mean, we've not had smart phones for that long.
-
9:18
I mean if you just think back—just try to think back before we had iPhones.
-
9:21
It wasn't that long ago.
-
9:22
The market moves really fast now—really fast,
-
9:25
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.
-
9:33
It's changed.
-
9:36
In short, we're going to hit the iceberg.
-
9:38
Leonardo DiCaprio freezes to death at the end.
-
9:43
So we're going to put them together, right?
-
9:45
We're going to do this together.
-
9:47
We're going to stick them together because that's what—that's the choice we have.
-
9:49
Right?
-
9:50
Whether or not you guys have made that choice to actively do Agile—I have.
-
9:54
I don't know how many people in this room have chosen as a designer—I know a lot of developers love the process.
-
9:59
But as designers, I don't know how many people are actively choosing to do Agile projects.
-
10:03
I love Agile projects.
-
10:04
I love doing design and Agile projects,
-
10:06
and I'm going to to try to convince you guys why you should love it too.
-
10:14
So we're going to incorporate Lean UX into Agile.
-
10:18
We're talking about Lean UX, specifically.
-
10:21
It's not the only way you can incorporate.
-
10:23
But we're going to use it as our method to incorporate the 2 together and make 1 cohesive process.
-
10:31
I'm putting the emphasis on incorporating because before the Lean UX book came out just recently,
-
10:38
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,
-
10:48
but UX and Agile was already kind of a phrase.
-
10:50
He felt like you could do it outside of Agile, and you can do it outside of Agile.
-
10:54
You can do Lean UX in Waterfall.
-
10:56
You can do Lean UX for start-ups.
-
10:58
You don't have to do it with—it does not have to be paired with an Agile methodology.
-
11:03
However, now really when he talks about it and most people talk about Lean UX,
-
11:07
they're specifically talking about it in Agile.
-
11:09
It's pretty much—they're one for one now.
-
11:13
What is Lean UX?
-
11:14
There's a couple quick misconceptions.
-
11:16
The first one is it's a UX of one—that I'm only one designer and I have to be lean.
-
11:25
That's not the most common one, but I've heard that before.
-
11:27
Some people have felt like that was what it meant—that it's UX of one.
-
11:30
That's a whole other problem.
-
11:33
There's a lot of books and a lot of great stuff on that.
-
11:35
Leah Buley has some good stuff on Lean UX of one.
-
11:38
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.
-
11:44
On the project that we do, I started out as the only UX designer.
-
11:47
It has its own—it comes with its own inherent problems itself.
-
11:52
The other main misconception is that it's UX Lite.
-
11:57
Right?
-
11:57
So we're going to—we're going to do the light version of UX.
-
12:00
We're not going to do the research.
-
12:02
We're not going to do all these tools that we have in our toolkit.
-
12:05
We're going to do the leanest version of it.
-
12:07
We're just going to sort of kind of do sort of UX and make it fit into the Agile iteration.
-
12:16
What it really is about is getting rid of waste.
-
12:20
When we talk about getting rid of waste, we're talking about this from the Toyotaism lean manufacturing.
-
12:27
This all comes from lean manufacturing processes and methodologies.
-
12:32
We're going to go over this real briefly.
-
12:34
We're not going to spend a lot of time on this.
-
12:35
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.
-
12:41
But we want to look at this real fast because you'll start to see some parallels that come out of lean manufacturing
-
12:47
and then go into lean start-up.
-
12:50
The first one is reducing waste.
-
12:51
That's the biggest one about—I think Lean UX as designers—is reducing waste—
-
12:55
getting rid of as much waste as possible and getting to the efficient stuff we do as designers.
-
13:00
Just in time inventory—Toyota uses this to create parts that are just in time to create cars.
-
13:08
So they try to keep the least amount of inventory on hand,
-
13:11
and they try to create the things in line.
-
13:13
Continuous flow manufacturing—the same thing.
-
13:16
The idea here is to try to make one car at a time—only one car at a time.
-
13:20
That includes from creating the engine and having the engine show up on time, etc.
-
13:24
Measurable results and scientific methods—so these are KPIs—things like that.
-
13:30
So lean manufacturing, and then there was this kind of lean start-up movement.
-
13:34
It started in 2007-2008.
-
13:36
Eric Ries is—great books.
-
13:39
If you guys haven't read them, I suggest them.
-
13:42
I gave some away the last time I spoke.
-
13:43
I don't have any today—sorry.
-
13:45
"The Lean Startup," "Running Lean,"—I think there's another one now.
-
13:47
There's—I think there's an additional one now, as well.
-
13:51
They keys to lean startup—again—reduce waste, customer feedback.
-
13:56
This customer feedback loop in there.
-
13:58
Again, the continuous deployment process, right?
-
14:01
So moving into being iterative instead of linear, right?
-
14:07
So I want to continue deploying my design—getting it out to market as fast as possible,
-
14:11
getting out my business ideas to market as fast as possible instead of a bunch of design and then a release
-
14:16
and then a bunch of design and then a release.
-
14:19
Then validated learning and scientific methods again.
-
14:22
This is just using scientific methods to do design.
-
14:25
There's a lot of design thinking in lean startup.
-
14:29
It's mostly influenced from design thinking.
-
14:33
Then they introduced this build-measure-learn loop.
-
14:37
This starts to become the key to lean startup.
-
14:39
This will be the key to doing Lean UX—these small build-measure-learn loops.
-
14:47
When they talk about this, they're talking about this in really small batches.
-
14:50
This is build, measure, and learn as quickly as possible with the smallest thing as possible—
-
14:56
building the small thing—the minimum viable product in lean startup.
-
15:00
It's build what I have to build to get it out there and measure it.
-
15:03
Then I can iterate on that over and over and over again.
-
15:06
Then Lean UX.
-
15:09
This is—primarily, the thought leader on this is Jeff Gothelf, which I'm probably butchering his last name.
-
15:17
He's got a book out now, "Lean UX."
-
15:19
It showed up at my door yesterday.
-
15:20
I skimmed through it trying to make sure that I wasn't full of crap.
-
15:27
He came up with a lot of these processes from reading "Lean Startup" and talking to Eric Ries and whatever,
-
15:33
while he was at The Ladders.
-
15:34
He was the user experience director at The Ladders.
-
15:38
At The Ladders, they decided that they were going to do Agile.
-
15:41
They didn't tell any of the designers.
-
15:44
They just showed up one day and said, "Hey, we're going to do this Agile transformation project."
-
15:48
"We're going to have a boot camp."
-
15:49
"We're going to train all of you guys on how to do Agile."
-
15:51
"We're going to stick you together, and everybody's going to be great, and we're going to make awesome stuff faster."
-
15:56
"And it's going to cost us less money and everybody's going to be happy."
-
15:59
He's got some great stuff online about how they felt about this.
-
16:03
His team put together this document of—like why Agile sucks.
-
16:07
Then—like handed it to them.
-
16:09
They have all this funny—so go out there and Google it.
-
16:14
It's pretty good.
-
16:15
They hated it!
-
16:16
They hated it!
-
16:17
Because he—they had this issue—right—where it just did not get along.
-
16:21
They could not get this stuff to get along.
-
16:23
So what he starts to do is he starts to think about—okay—how can we make this process work?
-
16:30
Some of the keys to Lean UX are design is a hypothesis.
-
16:36
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,
-
16:44
or if we make assumptions, we test those assumptions as opposed to doing genius design where we just assume that we know
-
16:49
exactly what our user wants.
-
16:51
We don't test it.
-
16:52
We just stick it out there.
-
16:54
Build the simplest thing first.
-
16:55
Again, that MVP.
-
16:57
Build things small.
-
16:59
Collaboration—we'll get into this when we talk about implementing.
-
17:04
Again, this build-measure-learn loop.
-
17:05
We're going to see how we break this down into the Agile sprint.
-
17:08
We see the build-measure-learn loop.
-
17:12
Everything is an assumption in Lean UX.
-
17:15
It's very key to doing Lean UX.
-
17:18
All your designs are assumptions,
-
17:21
and you're going to test everything as much as possible.
-
17:24
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.
-
17:32
But there's still some ways to kind of test internally and to validate some of your assumptions.
-
17:41
So as it starts to break down, Lean UX has this process where we go from concept to prototype.
-
17:47
We validate internally.
-
17:48
Then we test externally.
-
17:50
Then we learn and we iterate on that—over and over and over again.
-
17:53
We're going to apply this to our sprints—our Agile sprints.
-
17:57
We're going to move away from this process where we try to do all that up front and then deploy,
-
18:02
and we're going to move it into this iterative sprint model.
-
18:06
So implementing this on your Agile team.
-
18:10
This is not mini waterfall.
-
18:13
All right.
-
18:14
So if you try to take everything you do now and cram it into 2 weeks,
-
18:19
which is what a lot of us have tried to do before in the past, you're going to fail.
-
18:23
It's not going to work.
-
18:24
You cannot take the user experience in the design process and just cram it into 2 week sprints and try to do that.
-
18:31
That's what they tried to do first at The Ladders.
-
18:33
That's what most companies try to do at first when Agile is introduced to their—to their shops.
-
18:38
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."
-
18:44
"And we're going to have whiteboards, and that'll make everything better."
-
18:47
Right?
-
18:49
If you don't embrace moving away from what we're used to as designers and working in these linear paths
-
18:56
and moving toward an iterative design process, it's not going to work.
-
19:00
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
-
19:08
and kind of break some of our old habits of trying to do everything linearly.
-
19:13
Stop passing everything over the wall.
-
19:18
We're going to look at implementing in the room, within the sprint, and then last—
-
19:23
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.
-
19:33
Lean UX primarily is talking about within the sprint.
-
19:35
The book briefly goes into some stuff on how to handle is holistically.
-
19:38
I have a couple tools that we use at work to keep us on track holistically.
-
19:44
So in the room.
-
19:46
Start with cross-functional teams.
-
19:48
Now in Agile, we already have cross-functional teams.
-
19:51
It's part of the Agile manifesto.
-
19:53
Right?
-
19:54
It's about building these cross-functional teams where you have all these different people, all these different players.
-
19:58
What we're going to do is we're going to leverage that as designers.
-
20:01
We're going to start to become design facilitators instead of just designers,
-
20:04
and we're going to facilitate our cross-functional teams to help us do design.
-
20:08
We're going to get everyone involved in the design,
-
20:10
and this is huge.
-
20:13
Design workshops—design studies—whatever you want to call them—not just for the designers.
-
20:18
Bring your devs into it.
-
20:19
Bring your TAs.
-
20:21
Bring your business into it.
-
20:21
Everybody can't always attend.
-
20:23
People are busy coding.
-
20:24
People are busy doing their work.
-
20:27
At a previous company, what we did is we just did open-door design workshops.
-
20:32
So we would kind of have a cue—we would have some key designers that were going to facilitate the workshop.
-
20:37
We would figure out who was going to do what.
-
20:39
Then we would sort of send out an invitation to anybody that wanted to come.
-
20:42
We got really good response from that.
-
20:44
We would get some BAs in there.
-
20:47
We would get some developers in there from time to time.
-
20:49
We would get a good group.
-
20:50
Everybody couldn't make it every time, but—you know—we'd get a good mix of people.
-
20:54
I couldn't come this time, but I can come next time—that type thing.
-
20:57
So we want to get everybody involved in the design process.
-
21:00
Developers have good design ideas.
-
21:03
Business people have good design ideas.
-
21:05
We need to start facilitating that design amongst our team,
-
21:08
and it's going to help us build more of a cohesive team as the design being owned by the team.
-
21:14
In Agile, the team is central.
-
21:18
We want to start—we want the team to start to own the design, as well.
-
21:23
We're going to promote cross-functional pairing.
-
21:25
So this is—you know—I don't know if you guys—anybody do pair programming?
-
21:29
Any developers in here do pair programming?
-
21:32
So we do cross-functional pairing.
-
21:34
How many of you guys pair with your designers?
-
21:39
All right—2 people—awesome!
-
21:43
We want to encourage things like cross-functional pairing.
-
21:45
So this is design and developer sitting down together and working on the problem together.
-
21:48
This is really great because I can design—like a pixel-perfect design,
-
21:54
and then I give it to the developer and he's like, "Dude, we can't do this."
-
21:56
"We have IU-7 support, man."
-
21:59
You know?
-
22:01
So we sit down now at the machine together a lot of times and work through those problems in real time.
-
22:06
Because I can make those decisions as a user experience expert and the architect in the room—right—as the developer tells me
-
22:13
the constraints that we have that maybe I didn't consider.
-
22:16
So we'll sit down, we'll open of Firebug, and we'll just start tweaking the—we'll just design in the browser.
-
22:20
When we get something we like, he'll copy the code over, I'll take a screen grab,
-
22:24
and we'll attach that to the story, and we've done the design.
-
22:28
The work is done already.
-
22:30
Then we'll just go implement that.
-
22:33
We want to break down these silos.
-
22:35
The cross-functional team is important to breaking down the silos.
-
22:37
We want to get out of "I'm a designer. You're a developer. You're a BA. You're this."
-
22:42
We want to start being more inclusive in our roles and—I mean—we can't—
-
22:47
I can't—I'm not going to be the BA.
-
22:48
I am the designer.
-
22:49
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.
-
22:55
I can have empathy for what the developer has to do.
-
22:57
The developer can learn empathy for what I have to do.
-
23:00
As we do that, the team starts to build together, and it starts to own the design as a team,
-
23:04
instead of me being the designer and you guys being the developer because that's horrible.
-
23:08
That's a terrible environment.
-
23:09
I have that environment because we're always mad at each other.
-
23:12
Right?
-
23:13
The developers are always mad at me because I design things that are too hard.
-
23:16
I'm always mad at them because they never develop anything that I want to design.
-
23:20
Right?
-
23:21
So we're going to break down the silos, and we're going to stop passing things over the wall.
-
23:24
I'm going to stop just giving them stuff and saying—like—go do your job.
-
23:28
Yep?
-
23:29
[male] —BA?
-
23:30
Business analyst—sorry.
-
23:36
I've been at the financial institution a little too long.
-
23:39
I'm starting to pick up a lot of acronyms.
-
23:44
Get out of the building.
-
23:45
We do this as designers.
-
23:47
We have this as one of our tenets—
-
23:48
get out of the building, do contextual inquiries—those type things.
-
23:51
But this is really meant as a team—everybody get out of the building.
-
23:55
We have gone on trips.
-
23:56
We've gone down and seen our users, and we go together as a team.
-
23:59
We take developers there, designers down there—everybody goes down there and sees the problem.
-
24:03
When you see the problem you can have empathy for the user and now my developer has empathy for the user.
-
24:08
Now he's starting to become a user experience expert.
-
24:11
He's starting to say, "Well, that sucks for them."
-
24:14
"I was down there and that really—like we should do that better."
-
24:17
Then they start to have ideas on how we can do that better.
-
24:21
Design rockstars down't work well.
-
24:24
So if you are a design rockstar—some people really are, and they're really good at it.
-
24:30
It's probably not the best environment for you.
-
24:32
You're going to—you're not going to probably meld well with the team very well.
-
24:35
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.
-
24:42
So if you're a design rockstar and you want to keep being a design rockstar, you probably want to move out of Agile.
-
24:47
We'll get into why you don't want to be like that in a minute.
-
24:50
But anyway, design rockstars don't work very well.
-
24:53
Shared understanding.
-
24:55
In the room shared understanding is really key to making this process work.
-
25:00
Agile room—right—just crap everywhere.
-
25:03
This is—I have no idea whose office this is.
-
25:07
Google images—I couldn't take a picture of our office, and it was midnight so—
-
25:11
But we got all of our stuff up on the wall.
-
25:14
We put all of our things up there.
-
25:16
It's more than just the—like the Agile board.
-
25:20
It's more than our Agile board—our day-to-day.
-
25:23
They call our room the clubhouse because we've got all kinds of crap on the wall.
-
25:28
We've got a picture or Ricky Bobby—all kinds of stuff.
-
25:31
We put sketches up on the wall, and we put tenets of our design up on the wall.
-
25:35
We put stupid quotes that we say in stand-ups that are ridiculous—put those on the wall, too.
-
25:40
We make it a fun place, but a lot of it is just getting this stuff out of your head and onto the wall.
-
25:48
Like externalize your work—get if off your machine.
-
25:50
If it's in a SharePoint, nobody's looking at it.
-
25:56
Right?
-
25:56
Get it up on the wall.
-
25:57
Print it out.
-
25:58
Make a sketch—whatever.
-
25:59
Get those things up on that wall so that everybody is seeing what you're thinking.
-
26:02
Everybody has—when we do sketches, we put them up on the wall afterwards.
-
26:06
They go stale.
-
26:06
They're up there forever.
-
26:08
We end up throwing them away eventually, but we externalize that work.
-
26:11
We get it up on the room so that everybody can have that shared understanding.
-
26:15
Then discussing and sharing the vision.
-
26:17
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.
-
26:24
I'll be over there doing whatever and somebody will start talking about something and I'll overhear it.
-
26:30
They'll kind of look over and see if I'm paying attention.
-
26:32
Then I'll drop what I'm doing and go and get involved in this discussion.
-
26:36
Those, quite honestly, drive our holistic vision probably more than anything else—
-
26:41
just getting in discussions together, in the team room, talking about things.
-
26:44
It's my opportunity then to share the holistic vision again, to remind people of our vision again,
-
26:51
to say, "No, we don't want to do that, and this is why."
-
26:54
There's discussions that I'll miss, and they'll make decisions without me.
-
26:58
I don't get that input.
-
26:59
I don't get to be the advocate of the user in those discussions.
-
27:02
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.
-
27:10
We don't have cubes.
-
27:11
We're in big open rooms so you can't hide.
-
27:15
But just being willing to get in—and sharing and getting into discussions.
-
27:20
Within the sprint.
-
27:23
Iteration meetings.
-
27:25
Most of you here probably do scrum.
-
27:28
It's the most popular, especially amongst big corporations.
-
27:32
How many of you guys do scrum?
-
27:35
How many of you don't do scrum?
-
27:38
Extreme Programming?
-
27:40
What do you guys do?
-
27:41
Kanban—okay—all right—cool.
-
27:43
So it—this is not necessarily specific to scrum, but scrum kind of has a lot of meetings.
-
27:51
I'm not a big fan of meetings, but that's a different discussion.
-
27:55
If you've read this book "Rework," which is really great,
-
27:57
they pretty much say meetings are toxic—like never have a meeting.
-
28:00
I think it's unrealistic, but I'm not a big fan of them.
-
28:05
But we have grooming.
-
28:06
We have planning, and we have story writing.
-
28:09
We're active in all of these meetings.
-
28:10
In fact, we spend a lot of our time in these meetings.
-
28:13
It's unfortunate that really we spend sometimes too much time in these meetings.
-
28:18
But they're really important to our process.
-
28:20
We spent a ton of time in grooming.
-
28:22
It is pretty much our key opportunity time to help shape the stories, help shape the direction,
-
28:27
help keep things driven on a holistic vision.
-
28:31
We want to be part of planning, and we want to be as best as you guys can—if you can get in—
-
28:36
if you can move yourself into working with the business to write stories, that's excellent.
-
28:41
Some places will be a little weird about that at first, and it take some time.
-
28:45
But you want to get where you can write stories with the business and write your own stories.
-
28:52
This was a grooming meeting—5 hours.
-
28:57
That was like another 5.
-
28:59
I didn't go to it.
-
29:01
I'm not going to a 5-hour meeting—I'm sorry.
-
29:03
At some point, you have to push back, right?
-
29:06
So it can get a little out of hand.
-
29:07
But, again, it's really important you guys participate in these activities—these Agile activities because it's part of growing
-
29:17
cohesively together as a team, and you can do your own work, too—push back on meetings.
-
29:22
There's lots of great stuff out there on how to make meetings better and how to facilitate better meetings.
-
29:27
Look into that.
-
29:28
Try to do your best to work that out, but it's important.
-
29:34
Concepts and prototypes.
-
29:37
Lean UX pretty much relies heavily on concepts and prototypes,
-
29:43
and it was really where the conversation started with Lean UX was—it started with this whole kind of get out of deliverables business.
-
29:50
There's a bunch of blog posts on getting out of the deliverables business.
-
29:53
There's some pod casts with Jared Spool,
-
29:58
and that's what they kind of started talking about was getting out of this deliverables business.
-
30:01
It pretty much meant—like stop delivering 50-page wireframes with all in the annotations.
-
30:07
It is not your job as a designer on an Agile team to distill the story for the developer.
-
30:15
That's a lot of times what we end up doing.
-
30:17
Right?
-
30:19
I like developers.
-
30:20
Don't get me wrong.
-
30:21
Don't take this defensive.
-
30:24
I've worked as a front-end developer, as well.
-
30:25
Pretty much, if I don't have to read the story, I'm not gonna.
-
30:29
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.
-
30:35
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,
-
30:42
I'm going to do that.
-
30:45
So that's what you'll become.
-
30:46
You'll become the person that sits there all day long and figures out what all of the different requirements are for this story
-
30:52
and distills them into a nice wireframe with really good annotations so that you can hand it to the next person.
-
30:59
You become a communicator, and that's all you do.
-
31:01
You just communicate specifications to the next person.
-
31:04
We want to get away from that.
-
31:06
We want to do as much concepting and prototypes as possible.
-
31:09
We're going to look at iterating this process, but we start with sketches.
-
31:14
Stop wireframing.
-
31:15
Get out of the computer.
-
31:16
Start with sketches.
-
31:17
Get your early ideas as quickly out as possible.
-
31:21
You're doing those design workshops—right—like developers will do sketches.
-
31:25
Designers will do sketches.
-
31:27
Everybody can sketch.
-
31:28
It doesn't have to be good.
-
31:28
This is actually a pretty good one.
-
31:29
This is from—this one is actually from an Adaptive Path workshop.
-
31:32
This is a pretty good one.
-
31:34
There are much worse than this.
-
31:35
Mine are terrible.
-
31:36
Mine are—like hard to comprehend.
-
31:38
They're chicken scratch, right?
-
31:40
But they're enough that I can say, "This is my idea."
-
31:42
"Okay. We've got something we can go with here."
-
31:44
"Yeah, we kind of like that," or "Let's throw that one away."
-
31:47
"Let's try this again."
-
31:49
We're going to do a bunch of divergent thinking before we start to converge on one idea.
-
31:53
We do that low fidelity first—lowest fidelity as possible.
-
31:56
Then we start to iterate that fidelity.
-
31:59
So then I might have to move it into a wireframe.
-
32:03
I try not to, but we might have to move it into a wireframe to prove something out.
-
32:08
What we'd like to do is move straight from the sketches to prototyping.
-
32:11
It does not always work that way.
-
32:12
We can't always do that.
-
32:13
We don't always have the time.
-
32:15
When I prototype, I'm prototyping in HTML, CSS, and JavaScript.
-
32:19
I'm making—you know—I'm making mock software so that I can hand that to the next person and say,
-
32:25
"This is how I want it to work."
-
32:27
"When you click that, this is how long it should take."
-
32:29
"It should take this long for that thing to show up."
-
32:31
Because I have control of that.
-
32:32
Not of all of you guys in here have those development skills.
-
32:34
You can pair with your developer to do that type of prototyping if you don't.
-
32:39
You can things like Keynote Kung-Fu or whatever—do your stuff in Keynote.
-
32:45
Make it clickable, right?
-
32:47
The point of this is I want to be able to show this to the business.
-
32:50
What I can show you working is so much better than wireframes and annotations will be ever be.
-
32:55
I will miss an annotation.
-
32:57
I'll forget to annotate that that thing is supposed to show up this fast, etc.
-
33:02
There's so many minute interaction details that I can't cover in a wireframe.
-
33:06
But if I can show you how it works, that is—that's much easier for me to build.
-
33:11
I can see how it works.
-
33:12
I can see when I click on this it should do that.
-
33:15
When we're proving this stuff out to the business and we're handling new patterns,
-
33:19
we want to show them how we want it to work.
-
33:22
If I show them wireframes, they get—they're like why is that misspelled?
-
33:28
I'm like because I'm a designer.
-
33:29
I don't know how to spell.
-
33:31
What does that matter?
-
33:32
It's not going to be misspelled in the app.
-
33:34
They'll focus on things like that or—like what is lorem ipsum and things like—you know.
-
33:39
I can't make these pixel-perfect—
-
33:43
We want to prototype as often as possible.
-
33:46
Research and testing.
-
33:48
This is a huge one I think for user experience folks in Agile.
-
33:51
We feel like we don't get to do any research and any testing anymore.
-
33:55
We don't have the time for it because research—it does take time.
-
33:59
Good research does take time.
-
34:01
I'm not a researcher.
-
34:02
I know researchers, and they're like—I know research user experience people, and they're crazy about research.
-
34:08
It's awesome, but good for them.
-
34:13
One day every iteration.
-
34:14
One day every iteration devoted to research.
-
34:18
John can look at me and say I'm full of crap because we don't do this.
-
34:23
I would love to do this.
-
34:25
This is something that we're striving towards.
-
34:26
This is not something that you guys are going to get day one.
-
34:29
This takes time.
-
34:30
We're getting close to this now.
-
34:31
We've been—we're on the—22nd sprint.
-
34:34
I mean, we've been doing this for a while.
-
34:36
It's taking time to develop this process.
-
34:38
But we're getting much closer to this one day every iteration of nothing but user testing,
-
34:44
and it's super-simple.
-
34:46
Three to five people—no more than five people.
-
34:48
You won't have enough time.
-
34:49
It's test everything—test anything.
-
34:52
It does not have to be a formal usability test.
-
34:55
You could do just a user interview.
-
34:57
You could do some card sorting—whatever—just get anything.
-
35:01
Get your sketches in front of them.
-
35:02
Ask them their opinion.
-
35:03
Do some co-design with the actual users.
-
35:05
"Hey, how do you think this should work?"
-
35:07
"What are your thoughts on this?"
-
35:08
And sketch with them.
-
35:10
We don't have the opportunity to actually get face-to-face with users so we use web accent email.
-
35:14
I send a bunch of stuff to users via email.
-
35:16
I have key users.
-
35:17
When we met them in facilities or whatever, I got their email,
-
35:21
asked them if I could contact them, send them things,ask them questions.
-
35:24
So we have a lot of contact with our users just that way.
-
35:28
You could do email diary studies—things like that.
-
35:31
There is still opportunity to do the work that we want to do as user experience architects and as designers
-
35:38
that can fit in this framework.
-
35:41
We'll get to that in a minute, okay?
-
35:43
Yeah.
-
35:43
We'll have to cover a lot of these type questions.
-
35:45
I'm going to try to get through.
-
35:46
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.
-
35:50
But we'll get to that in just a minute.
-
35:52
I think.
-
35:54
Hold me to that.
-
35:57
Validate internally and then externally.
-
35:59
We do a lot of validation internally.
-
36:00
When I say we don't test, it's not actually totally true.
-
36:03
We don't get to test as much with our end users as we would like.
-
36:06
We, unfortunately, have to wait to we have the release, which we still have staggered releases because we have to go
-
36:13
with other software that's on Waterfall—blah, blah, blah, blah.
-
36:15
We don't get to go every 2 weeks like we'd like to.
-
36:18
But our releases are pretty close.
-
36:19
I think they're every 3 to 6 weeks now.
-
36:21
Our stuff gets out there pretty quick.
-
36:23
We get our feedback then.
-
36:24
Unfortunately, sometimes it's wrong and it's bad and our assumptions are wrong and we have to fix it.
-
36:29
But a lot of what we do is validate internally.
-
36:32
This is that—if you guys are customer-facing, this is lunchroom testing, etc.
-
36:35
My application is internal-facing so it's a little bit different.
-
36:38
But you can do lunchroom testing.
-
36:40
You can take things out in the lunchroom, show people paper prototypes, test it with people in your organization
-
36:45
that don't know about your project—those type things.
-
36:48
You can do a lot of that validation internally.
-
36:49
Validate within your team.
-
36:51
A lot of times we just throw stuff up on the projector and—like the developers will tear it to shreds.
-
36:57
They'll be like—you know—because developers know how to use things.
-
37:02
They are usability experts.
-
37:03
They use computers all day long.
-
37:05
We all—you know—you guys use Twitter or Facebook.
-
37:08
You use these services—Google.
-
37:09
You guys are very familiar with good UI, good user interface, good user interaction.
-
37:16
A lot of times we'll just throw it up on the projector, and we'll get feedback right in the room.
-
37:20
We get a lot of good feedback that way.
-
37:22
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.
-
37:30
Somebody will have an idea—like why are we going—why are we doing that so complicated?
-
37:34
Why can't we just do this instead?
-
37:35
There'll be kind of an aha—like, yeah, that's a good idea.
-
37:38
Because I don't know what I'm doing.
-
37:41
It gets this—starting to do this build-measure-learn.
-
37:45
We're starting—we're going to do that in the sprint over and over and over again.
-
37:49
We're going to build either a concept prototype—it might be the actual code.
-
37:53
We're going to measure that with research.
-
37:56
We're going to follow along with some—we'll talk about holistic in just a second.
-
38:00
We're going to follow along with some of our design patterns and some of our holistic design strategy,
-
38:04
and we'll kind of validate that what we're doing is right there in the measure.
-
38:08
Jeff Gothelf does—their Agile teams are problem statement focused, which I think is a really awesome idea.
-
38:16
It's the first time I've heard of it just recently.
-
38:18
Instead of their Agile teams being aligned to features and functionality, they actually align them to problems—
-
38:24
to the problem statement so the team is actually working on a problem statement.
-
38:27
That, I can see would really fit into this build-measure-learn loop because then I have this problem statement
-
38:32
and I can start to measure against our problem statement.
-
38:35
The example he gave at The Ladders was there was a connections team,
-
38:39
and the whole point of that team was to get people on The Ladders to connect more.
-
38:43
All right.
-
38:44
So their problem statement was we need—we're trying to get more people to connect.
-
38:47
Whenever they would do this build-measure-learn, they have something to measure.
-
38:50
Are more people connecting?
-
38:53
Not versus did we just build the code good or is our code coverage up, etc.
-
38:57
Then it doesn't leave just the design team in the business of validating and trying to measure and learn from.
-
39:03
It puts the entire team into perspective.
-
39:05
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
-
39:11
and try to align us more to that problem statement because I like that idea a lot.
-
39:16
Lastly, holistically.
-
39:18
Last but not least.
-
39:19
This is the one that I spend probably most of my time as the user experience architect on our team working on—
-
39:24
trying to drive holistic vision inside of Agile.
-
39:27
Lean UX helps us a tone within the sprint, but there are still some problems with Agile that I've found
-
39:34
that make it really difficult to do big picture design in these little, teeny sprints.
-
39:38
The business tends to not want to let us think outside of that space.
-
39:42
They say, "Well, no, we're working on this this 2 weeks or this 3 weeks or whatever."
-
39:46
"What are you doing thinking about that?"
-
39:48
You're trying to argue, "Well, we've got to think about that."
-
39:50
"If we don't think about that then how do we know what to build today?"
-
39:54
Agile sort of—kind of—[audience applause], right?
-
39:59
If we don't think about that, how do we know what to build today?
-
40:01
Agile is saying, "Well, we'll just re-do it."
-
40:03
"We'll just fix it."
-
40:03
It's iterative, so we'll just—we'll re-build that.
-
40:07
You're saying, "I can't design this today if I don't know how that fits into that tomorrow."
-
40:12
So holistically we have some tools that we're using, and I think they're working pretty well.
-
40:17
We're doing a pretty good job, at least that's what people tell me.
-
40:20
Develop your design principles.
-
40:22
You can do this at any point.
-
40:23
You guys could go back tomorrow and do this so you don't have to do this at the beginning of the project.
-
40:27
A lot of you have design principles that are in your head and that you're using to do the design.
-
40:31
You've kind of got them up there and you're using them to lead where you're going.
-
40:38
Get together with your business, your product owner, your team.
-
40:43
Start to jot down what some of those design principles are.
-
40:45
Our document is 2 pages, and it's not amazing at all.
-
40:52
It's pretty simple.
-
40:53
It started out as a concept.
-
40:54
The business asked me to do a concept for what our application would start to look like holistically.
-
41:00
So we did the concept and everybody liked that.
-
41:03
This was just a presentation.
-
41:04
This wasn't like a—we didn't really do much design.
-
41:07
We did a little IA and some layout.
-
41:10
Then out of that came a bunch of principles that we got from doing—getting out of the building and seeing our customers
-
41:15
and seeing our users, and we were starting to see some of the problems and kind of really what we wanted to fix.
-
41:20
The business was saying what they wanted to fix as a company and how they wanted to be tomorrow.
-
41:24
We started to kind of meld those together.
-
41:26
We put this concept together, and the business was very happy with it.
-
41:30
I said—I took a little risk, and I said, "Well, can we make these our design principles that we design to?"
-
41:35
And they said, "Yeah."
-
41:36
We put it in our Wiki, and those are our design principles now.
-
41:41
Business has sign-off on them.
-
41:42
So when we start doing things, I cite these things all the time.
-
41:46
I'm saying all the time, "Well hey, look, we have design principles."
-
41:50
The business says that they want this—that they want this type of design and that doesn't match.
-
41:55
So what do we need to do as a team to fix that?
-
41:57
The team is really starting to get on-board with it.
-
41:59
They're starting to understand these design principles.
-
42:01
They're starting to do them themselves.
-
42:03
They're starting to call them out.
-
42:04
Developers will come to me and they'll point out inconsistencies when the application doesn't meet our design principles.
-
42:10
So we get key buy in, and we stick to them, and we cite them often.
-
42:15
They become our principles—our guidelines to work by.
-
42:18
Then we adjust them when needed.
-
42:20
It's Agile.
-
42:21
The project changes, the project moves.
-
42:23
You can't have design principles that are set in stone.
-
42:27
These did not come down from the mountain and give your design principles to your developers.
-
42:34
This is work together as a team to develop these design principles and get everybody on-board with them.
-
42:38
Then, when they need to be adjusted, don't be afraid to crack open the document, adjust them, and move forward.
-
42:45
Pattern libraries and style guides.
-
42:47
Super important.
-
42:50
This is sort of like our third UX person is these pattern libraries and style guides.
-
42:55
Without them, I don't really know what we'd do, and currently—the state that they are—these are not ours.
-
43:01
These are just quick examples.
-
43:03
Currently, the state they are is kind of scary.
-
43:05
I've got a lot of work to do when I get back to work on Monday.
-
43:09
But they're not just for designers.
-
43:11
This, again guys, look into pattern libraries, and there's a lot of really great stuff on how to do a good pattern library.
-
43:18
They're kind of tricky.
-
43:20
There's some strategy to doing them right and doing them wrong.
-
43:24
Key ones are they're not just for designers.
-
43:26
These are not just for the designers in the room.
-
43:28
These are pattern libraries for the entire team.
-
43:30
Again, in Agile, it's about the team.
-
43:32
It's not about designers and developers.
-
43:34
They have to have input into this pattern library.
-
43:37
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.
-
43:46
It's got to be team input into this pattern library.
-
43:49
It has to be accessible to everyone.
-
43:51
If you are like the master keyholder of the pattern library and you have to give people access to it
-
43:57
and—you know—go make them like—"Oh, I need access to the pattern library."
-
44:02
"Okay. Put your name in, and then I'm going to give you—like read only."
-
44:06
That's not going to work.
-
44:07
People are not going to use it.
-
44:08
Everybody has to have access.
-
44:10
People need to be able to edit it.
-
44:13
In Agile, trusting the people your work with is key.
-
44:16
So don't try to lock it down and try to control it and be the designer that owns the pattern library.
-
44:22
It needs to be curated and updated as often as possible.
-
44:24
We'll look in a minute where we attempt to do this.
-
44:28
Again, this breaks down sometimes, but I think we're doing an all right job.
-
44:32
How we curate and update the pattern library—we put code in our pattern library.
-
44:36
So we have our own UI guy.
-
44:37
He puts code in it.
-
44:38
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
-
44:47
that in the software, we try to put that in the pattern library.
-
44:50
We use Wiki to do it, unfortunately, because that's the software we can use.
-
44:54
There's some software out there, depending on how you guys are locked down,
-
44:56
there's some software out there that you can use to do pattern libraries.
-
44:59
How are we doing on time?
-
45:01
Okay.
-
45:02
Story maps.
-
45:05
This is a feature hierarchy of the backlog.
-
45:08
We have 4 different products running different directions.
-
45:11
There's like a thousand stories.
-
45:13
I need to be able to see all the stories that the business is writing.
-
45:16
It helps me key an eye on the big picture.
-
45:19
This is just an example.
-
45:21
So I organized it by feature.
-
45:23
I don't care about the prioritization of the business.
-
45:25
I care about the prioritization of features.
-
45:28
We can mark out the releases.
-
45:33
So when we look at the iteration, this is our iteration.
-
45:36
We start on a Wednesday.
-
45:37
I have no idea why.
-
45:39
We do our workshops and our design sessions—try to do them at the beginning.
-
45:42
Testing is scheduled for Thursday.
-
45:45
We'll do something low fidelity on a Friday.
-
45:47
The majority of the sprint will be for design.
-
45:50
Monday we document because we're getting ready for demo.
-
45:52
Tuesday is demo day.
-
45:54
We watch movies and demo.
-
46:00
Shoot.
-
46:02
I'm going to have to fly through this, guys.
-
46:04
I'm really, really sorry.
-
46:05
This is—I'm at 45 minutes.
-
46:09
Moving beyond incorporating Lean UX and embracing Agile.
-
46:14
I think we can embrace it.
-
46:15
Agile is human inherently.
-
46:17
It is human-based.
-
46:19
It's about people over process.
-
46:21
It's in the manifesto.
-
46:22
Cite that often.
-
46:24
Encourage that in your teams.
-
46:27
It offers us design constraints, which I think are really good as designers.
-
46:30
When we have no design constraints, we tend to not do a very good job with our designs.
-
46:35
If you give me a month to make something, I will use up all of that month,
-
46:38
and I'm probably going to do the best design on the last 2 days.
-
46:43
Forced deadlines are really great for designers—11th hour design.
-
46:46
I do good design in the 11th hour.
-
46:48
When I'm forced to have to come up with something creatively really quickly and I'm out of time,
-
46:52
that's usually when I do my best work.
-
46:53
I don't do my best work at the beginning of the sprint.
-
46:56
It gives us room for failure and, as a designer, I am—I love this.
-
47:00
Because it doesn't have to be perfect.
-
47:02
My design does not have to be perfect day one.
-
47:04
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
-
47:10
developing and then we put it out in the market and the design wasn't any good.
-
47:14
I have time to iterate that design and make—you know—there's room for my mistakes.
-
47:20
Team ownership.
-
47:21
It compliments and encourages good user experience.
-
47:25
This process really helps us do better user experience.
-
47:29
A lot of times we say we do human-centered design and we're not doing human-centered design.
-
47:33
We're going genius-design, and we're calling it human-centered design and really just nobody calls us out on it.
-
47:38
I'm guilty of doing that.
-
47:40
This encourages us to do human-centered design, to do this iterative loop, and to get feedback.
-
47:48
Responding to change over following a plan.
-
47:51
This process itself is iterative.
-
47:53
I can turn the design process towards the process itself.
-
47:55
I can use my design to make our process better.
-
47:57
I can figure out what works for our team versus another team.
-
48:01
It's not dogma.
-
48:02
Agile is not dogma.
-
48:03
It's Agile.
-
48:05
It's supposed to change.
-
48:06
You're supposed to be able to adapt it.
-
48:07
Change is okay.
-
48:09
Really, I think it culminates into this entire process—when you take Lean UX and you put it into Agile,
-
48:15
and we start facilitating design as designers, I think it's design thinking.
-
48:19
I think you can say about Agile and Lean UX, it's a human-centered approach to innovating to integrate the needs of people,
-
48:25
the possibilities of technology, and the requirements for your business."
-
48:28
Thanks, guys!
You need to sign up for Treehouse in order to download course files.
Sign up