Over the years, I've developed a series of tools and techniques that have helped
teams integrate, both agile, user experience, and
lean ux, and due process. And I want to share three specific techniques with you now
and tools that can help you start to build this
level of cross-functional collaboration, and increase the efficiency of the
teams that you're working with. The first is the concept of the experiment story, and we
talked about user stories as the building block for an agile backlog.
An experiment story.
Allows you to build learning into your backlog. It's a
story just like any other. But instead of delivering
design or code at the end of it, you're delivering
learnings
You're writing an experiment Story, You're assigning.
Resources to that story. So you're saying we'd like to learn this as part of the story, we
write it like a hypothesis. We believe that by adding a big red button to the
checkout flow, people will buy more stuff and we're going to
assign the product manager and the designer, for example, to that, and we're going
to estimate it at two points or three points.
And we're going to build learning into our backlog and we're going to
prioritize that against delivery stories, stories that deliver
code.
We're going to put it into the backlog where we believe it should go.
Knowing full. Well, that we may learn something from
that experiment that will affect the downstream
prioritization of the backlog. We're going to
assign resources from the team to work on this who will not work
on something else while this story is in play.
We're going to use those learnings to refine and groom the backlog
Downstream from here. Now as the learnings come in
from that experiment, we have to bring that back the team as quickly as
possible but the idea is to build
learning into the execution process. So that you're always checking
whether you're building the right thing or not. And by
writing these stories for experiments and in prioritizing them
just like you would execution,
Delivery work.
You're forcing the team to consider what's more valuable at this point. Should we learn something
about this or should we build it?
And that's a good conversation to have with your team and this is a terrific tool to start that
conversation and to build that continuous learning
into your agile delivery process.
Another tool that's worked really well. For me, over the years has been
a Wiki you can use Wiki's for any kind of knowledge
aggregation, but we've used them in the past for Knowledge Management Systems,
especially Works, especially well, with distributed teams. But this is a great place to
aggregate your project assets to onboard, new
team members who join, and they want to know what's taken place to date.
Take a look at the wiki. All the assets are there you can keep corporate
documents.
You know, that's important. And most importantly, if you need to maintain the product, people can go back to the
wiki and look at the decisions that were made the assets that were
captured, any kind of commitments that were business rules that were
changed based on learnings, it's a terrific way to aggregate
information and, and the benefits of using this is that it's living piece of
documentation. It's not, it's not a static document that lives on somebody's lap top.
It lives in house on site with revision
history. You can
See what's changed, you can see who changed it, you can see the discussion threads
around the things that have changed.
Wiki's typically interface with other project tools so they
can connect with your project management system or your bug tracking system or
perhaps with your with your agile project management system
and they can often send you push alerts when things have changed. So if you're not directly involved with the project but you're
interested in the progress made, you can sign up to get alerts
from that particular page or from that project that says, hey this changed, there's a new
discussion over here.
And this allows people who are not directly involved with the product development process.
To keep tabs on how projects are performing customer service
marketing legal compliance. Branding
Executives can keep track on specific projects by subscribing to the
pages on these Wiki system. And the nice thing is that they're accessible
from any device anywhere anytime. So everyone has
access to these tools at any given time.
Now if you set up a Wiki for your project here's some basic
basic framework for setting up that project. So obviously you'd like set up a project description with a
name and the problem statement. The problem statement being why are we doing this
work? It's a terrific way to frame a project in your Wiki and
your documentation what we set out to do and it's a good way.
To go back and validate some Downstream thinking, maybe your six months into a
project and you're drifting away from why we set out to do this in the first place, it's a good way to
revisit that you set out your success criteria your
outcomes, who's on the team, what they're doing and any lists
of completed stories with links back to those stories. So people can
see what's been delivered, what it look like when it went live
bugs, Etc and you can you can break down the project into a story page,
a page per
Rate that has a link to where you're tracking the story.
It has the assets for that story designs, wireframes prototypes, any
research, efforts and evideos any photos, any documentation that you've
captured during those research with summaries and links
to all the artifacts that allows team members to go back and review, things or new
members to on board to get a sense of why we made the decisions that we made. And again,
this is living documentation. So it's not one person's responsibility.
Its ability to update this, it's the team's responsibility.
To continually make sure that this knowledge management system is up to date.
Now, another tool and a terrific use for a Wiki is the idea
of a style guide. Now, this is my definition for a style guide. It's a set of defined
guidelines for the presentation layer, the behavior, and the
voice of a system, whether it's a website or online product,
marketing, marketing, collateral Etc, and it's also a repository of
assets, both graphical and code, for this system,
There's a big movement Now to create living style guides which are the actual style sheets
for the system. So if you update the style guide, you actually update the site in production
But style guides are extremely powerful. They work really well. If captured if you're not going to do a live style guide,
capturing it in Wiki's a terrific way to do it. And they work really well because they
Define all of the basic components of the workflow in
the interaction of your system. What is the header going to look like? What is the footer going to
look like, what type of navigation are we going to use? What's the font structure?
Do our positive buttons. Go on the left versus on the right. Where do we put our form
field labels? Do we use? Carousels. You know what kind of arrows do we use? It
said all of
Of things that need to be defined once and codified and
reused throughout your system can be captured in the style
guide.
And so, you're building consistency for your customer consistency of brand,
consistency of voice of interaction. I've learned how to use the
system here and it works the same way every single time. They launched something
new or I try something different on the website, you set expectations for your
customer.
To deliver the product, the experience the same way each use.
you're also adding efficiency for your team by defining these
assets, once
Storing them centrally and then reusing them throughout the system as
often as possible.
And so, you're taking all the routine work out of the design and you're allowing
Your team to be much more to focus on the bigger challenges. The more creatively
challenging portions of the experience, which buys them more time
because they don't have to debate. Each time they build a form where the form field
labels go.
And what's nice is that you're creating a foundation and a set of rules on
which you can build and expand the product Suite, which then allows you to easily
scale the system and empowers, the team to move forward without having to
seek approval design approval, interaction approval for every
decision that they make, because the basic building blocks have been defined once
and agreed upon by the entire organization.
There are two ways to build a style guide. I call them slow drip and big bang
and there's pros and cons to each one. The slow. Drip way is to fill out a style
guide opportunistically to create the template for it and to capture
it as you're creating new assets. Hey we built a new photo
gallery interaction. Let's put that into the style guide.
Hey, we figured out there were going to move the form field labels from inside the box to left. Align on top of the
box. Let's put that into the style guide and the benefit. There is
that you don't stop the current development workflow. Your opportunistically filling this
thing out
And it keeps the style. Guide is a living document, that's continually evolving and
learning the problem. With this particular approach, the con
here is that it will take a very long time to get a
complete view, into your system defined and codified into a stock out
of the slow drip method.
And so, alternatively, you could choose to go with the big bang method. When you dedicate some resources, may be a designer
and an engineer and a writer or a Content strategist
to defining the style, guide, all at once. They take some time outside
of their regular work flow, they break down the system into its core components
and they put in all the information into the style guide. Once maybe takes them a month, maybe
takes them a couple of months to get it up and running and and complete but they
build that system. But the benefit is that it makes it
Apprehensive from day one from day. One, all of the components are in there. All the assets that you need
to build an experience to prototype and experience are there and the
efficiency of the team can move forward significantly on day. One on
launch of the style guide.
As if you're thinking about where to start, always start with a table of contents for your style guide. Break down
your, your site into its core components. Header footer
forms, photo, galleries content, tone
voice, editorial, Etc. And then Farm out
those pieces to the people responsible for them and let them fill them out.
But starting with a table of contents, works really well. A couple important things to remember
about the style guide, first and foremost, assign an
owner. Someone has to own the style guide. Now, it's not necessarily
a fun job and so you might want to rotate that own or every
quarter, but someone has to own it and make sure that its current
and it's up to date as soon as that style guide falls out of
date people will stop using it. Someone has to own it and ensure
that it keeps currently.
Make sure that it's accessible to everyone and that it's easy to get to. I worked at a company
once where if you typed the word style guide into the URL bar of your
browser, if you're, if you're on site inside the network, it would resolve to the style
guide, do whatever you can to make it as easy as possible
for people to access. The style guide from wherever they are, especially with distributed teams.
Continue to encourage usage of it and updating Point people to it,
put signs up in the hallways and in the break rooms, make sure people know that
it exists, use a Wiki for a week. He's a terrific tool to make it
happen and most importantly, remember that, it's a living
document as your system involves the style. Guide has to evolve, it has to stay
current. If it doesn't stay current people won't use it and you'll start to
lose that efficiency. Now, the style guide allows your team's to
stop discussing.
What elements they need to do. They need to create in order to move
forward quickly.
It allows them to prototype experiences very, very fast because the assets
exist they can pull together and approximation of a new experience very quickly. Here's a header.
Here's a footer, here's form. Here's some buttons, some content.
And so you can create realistic, prototypes, in a fraction of the effort that it would
take you to code these things from scratch. And that's why it's a terrific tool for the lean
ux process.
And so, in summary, I want to talk about how lean ux merges, the concepts of user
experience and design product management, marketing, and
development, with the agile process, first and foremost, we solve our
problems together as a cross-functional team to build that shared
understanding we get our ideas out of our heads, early
and often. Through sketching, through conversations, through brainstorming
exercises, we recognize that our ideas are hypotheses.
And we validate our design hypotheses quickly.
To know if they're right or wrong. So we don't waste time.
Building and designing things that aren't accurate.
We use scrum as a nice Rhythm
to structure, our lean ux
activities and to build that continuous learning into the Agile development process,
Everyone participates in the process story Gathering, and estimation and prioritization
product design, engineering content etcetera.
Always think about how you can be leaner
in your experimentation, in your process, in your design, in your
engineering. Right. We only want to do what we
need to do to move forward. One step closer to certainty from
doubt. Working in small batches.
Research is an ongoing activity. It's not something that happens once at the beginning.
And once at the end of your project, it's something that we kick off the initiative with and we
build into our iteration Cycles. So that we have that
continuous feedback, both qualitative and quantitative to understand if we're still building
the right thing as you're working, transparency is
key manage up and manage out, let everybody
know what you're doing, what you're learning, how you're
progressing, and why?
Taking the next steps and that will give them a sense of comfort to
stay out of your way and let you continue to move at this pace.
And then finally all of this is an effort and in service of not
designing and not building things that people don't want which is the ultimate form
of waste. Thank you.