DESIGNING

AGILE
INTERACTIONS
Sami Niemelä
Creative Director, Nordkapp
@samin / www.nordkapp.fi

Tuesday, June 1, 2010

Hello, my name is Sami Niemelä. I am the creative director of an interactive

design consultancy Nordkapp from Helsinki, Finland. We design and
develop strategy, products, services and transformations. Our clients are
multinational media companies, operators, mobile phone manufacturers
and also other consultancies such as IDEO.
 DESIGNING
AGILE
INTERACTIONS

Tuesday, June 1, 2010

The topic I want to talk about today is combining interaction design practice
with agile development. And especially working from the outside on a
consultants’ point of view. To coincide with this, a project we just finished
“a world record in agile” where we helped to build a online tv system for our
client SuomiTV on top of Brightcove’s technology platform.
 Agile
1 : marked by ready ability to move with
quick easy grace <an agile dancer>
2 : having a quick resourceful and adaptable
character <an agile mind>

source: www.merriam-webster.com
Tuesday, June 1, 2010

Let’s focus on semantics for a second—the Merriam Webster definition of

the word Agile is quite an interesting one. Especially the second bit—
“resourceful and adaptable character”— is by definition is very interesting,
and important. In my mind this says a lot about the role of designer in the
modern design practice.
 THE AGILE MANIFESTO
— Individuals and interactions over
processes and tools

— Working software over comprehensive

documentation

— Customer collaboration over contract negotiation

— Responding to change over following a plan

Tuesday, June 1, 2010

Here’s the original agile manifesto. As you can see, it’s all about the
constant adaptation to change. This is where I think a lot of the challenges
arise. Don’t get me wrong — agile is good for a lot of things such as quick
ROI for client - things happen visibly all the time, and the main goal is to
produce working software. As Agile is based on sprints, it's also quite good
on keeping the train moving in design as well
 STRUCTURE
VS
CHANGE

Tuesday, June 1, 2010

As practice, design is about creating structure through methodology,

processes and patterns. Agile is about adapting to change and evolution as
you go.

How does this apply to design process then?

 INSIGHT SYNTHESIS IMPLEMENTATION

Tuesday, June 1, 2010

Here’s the typical design process, from research to synthesis and

implementation. The further up the value chain you go, the worse Agile
methodology works by itself. Remember, the main goal of agile is to provide
working software in an extremely reactive environment. Not define strategy
or even long term directions.
 ” —IxD brings vision,
Agile brings control.”
@petterihiisila

Tuesday, June 1, 2010

Here’s a quote from a friend of mine when discussing agile & ixd on Twitter. I
think it crystallizes the issue pretty well. What we need is a controlled way of
working in sync with the developers without sacrificing the long term clarity.
 DESIGN

DEVELOPMENT

TIME

Tuesday, June 1, 2010

One thing worth noticing as well is that large projects tend to be design-
heavy in the beginning, but once everything is defined the development
starts rolling on – and the need for design keeps getting smaller.
 COMPLEXITY

TIME

Tuesday, June 1, 2010

On the other hand, in an agile project, complexity grows over time. the
bigger and longer the project, more moving parts to take care.
 Strategy

Planning Sprint x Planning Sprint +1 Sprint + 2

Design Sprint -1 Sprint x Design Sprint +1

Development Sprint - 2 Sprint - 1 Sprint x Development

Tuesday, June 1, 2010

Here’s the design process broken down into agile sprint model. The basics
are pretty simple - planning is done one sprint ahead of design is done one
spring ahead of development. All fine and dandy–
 Strategy

Planning Features + Requirements Sprint +1 Sprint + 2

Design Sprint -1 Stories + UX Sprint +1

Development Sprint - 2 Sprint - 1 Working Code

Tuesday, June 1, 2010

– and it goes on as quite systematic process where sprint features are

being mirrored with the scrum team, fed to designers and finally diluted
down into Scrum user stories.
 —HOW?

Tuesday, June 1, 2010

How to do this then? One important question is ask here is are you working
on supporting an existing product or creating something new?
 “SPRINT 0”

S0 S1 S2 S3 ETC

Tuesday, June 1, 2010

When working on a *new* project, the development team you’re working

most probably has a sprint 0 for preparations and setting up different
things. Apart from agreeing the culture and way of working, this is an
opportunity for design to raise up a flag and take this as an opportunity for
fill any missing holes in concepting. Actually, in some cases the S0 can take
up to several months.
 YOU’LL NEED
— Strategy

— Concrete Directions, communicated

— The right people.

Tuesday, June 1, 2010

The purpose of S0 is to make sure your team has everything they need to do
their work. In terms of design, here are the things that are necessary to
make the project happen:
— Strategy — where are you intending to go to and why?
— How will your team get there? e.g. design patterns, any frameworks,
design drivers and principles.
— And of course the right people.
 —WHO ARE THE
KEY PEOPLE?

Tuesday, June 1, 2010

As in anything, the key asset for successful project are the people involved.
 —SCRUM MASTER

Tuesday, June 1, 2010

The scrum master should be someone who understands design well

enough, and is willing to change her own craft as well.
 —DESIGN TEAM(S)

Tuesday, June 1, 2010

The design teams—Why a plural? Because in the long run, a project needs a
lot of support on implementation phase as well. And if your team has to
design the concept along with giving out support for the dev team, it gets
quite intense quite soon. And in order to deliver quality work, we need to
make the support a team on its own.
 —THE PRODUCT OWNER

Tuesday, June 1, 2010

You most important person is the Product owner - someone who is involved
with the project 100%, and senior enough to be accountable for major
decisions. I agree with Alan Cooper on that ideally PO is a senior interaction
designer. It has to be someone who understands all sides of the project, a
generalist.
 —WHAT CAN
GO WRONG?

Tuesday, June 1, 2010

So, like said—going agile means going systematic. There are several things
that can go wrong but are easily avoidable.
 — NO STRATEGIC DIRECTION

Tuesday, June 1, 2010

First one is having no vision. This means decision making has no direction,
and this leads very easily to reactive, scrum-led design which doesn’t quite
work for anyone.
 — LACK OF CLEAR,
SHARED VISION

Tuesday, June 1, 2010

Apart from existing, the strategy should also be shared and communicated
to everyone involved. The decide-as-you-go -moments will be some much
easier and consistent when everyone knows where the projects should go
to. Be visual, tell stories here.
 — NO COMMON CULTURE

Tuesday, June 1, 2010

with no culture, your project is a mess ›More complex the project, more
systematic you need to be. Establish ways of working, build the culture for
the teams. Even down to small details like email rules. Sounds nitpicking,
but when you put strange people working together in a mid-to high stress
environment, it's the small things like these that cause friction.
 — PRODUCT NOT OWNED

Tuesday, June 1, 2010

Your most important person absent leads very to scrum-led design.

Which is sometimes fine by itself, but only if you're mostly doing design
support.
 —WHAT CAN
YOU DO?

Tuesday, June 1, 2010

Like said, these are the opvious pitfalls but they are quite avoidable as well.
 — Have a vision that everyone understands.

—Make sure everyone understands the importance

of their commitment.

— Work as a catalyst for your team.

—Make friends with the developers. In the end, they are the ones
that make or break the project.

— Involve your client as much as possible. As in agile should.

Tuesday, June 1, 2010

- Have a vision that everyone agrees. Especially the business stakeholders.

Make sure it's communicated visually: stories, images, example scenarios...
- Make sure everyone understands the importance of their commitment.
- Have all the necessary assets for your team: brand guidelines, visual
language, behaviors, interaction models, design patterns.
- Make friends with the developers. In the end, they are the ones that make
or break the project.
- A project glossary: if needed, prepare a document outlining the
terminology in the project. Useful esp for your clients!
- Involve your client as much as possible. As in agile should.
 Agile Interaction Design manifesto

— No silos, no unnecessary hierarchies but a mutual

culture, roles and responsibilities.

— Defined behavior within refined, working software

— Open dialogue and shared language

with genuine collaboration

— Common, communicated vision with willingness

and resources to change.

Tuesday, June 1, 2010

I’d like to propose an Agile Interaction Design manifesto on top of the old
one:

— No silos, no unnecessary hierarchies but a mutual culture, roles and

responsibilities.

— Defined behavior within refined, working software

— Open dialogue and shared language with genuine collaboration

— Common, communicated vision with willingness and resources to change.

 …

Tuesday, June 1, 2010

So, to conclude this thing. At best, working with a solid agile team is a
wonderful experience. I'd like to compare it to a swarm intelligence—
everyone acts as individuals on shared goal, DNA, and culture. It's not easy,
but it can be done. The results of a working process can be beautiful.
 KIITOS

Sami Niemelä
Creative Director, Nordkapp

sami (at) nordkapp.fi

@samin

www.nordkapp.fi

Tuesday, June 1, 2010

Thank you. It was a pleasure talking to you. Please ask questions, comment
—I’d love to hear your thoughts on this.