• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Designing Agile Interactions
 

Designing Agile Interactions

on

  • 6,475 views

Description from the UX-Lx wbsite: ...

Description from the UX-Lx wbsite:

More and more UX projects deal with agile development in one way or another. For an interaction designer / project lead, this makes the projects themselves sometimes rather complex systems to control. In order to succeed, the projects themselves need to be designed to possibly evolve throughout the project.

How does this work? How to carry through the different phases from research to implementation? What types of phases can or should be even involved directly w/ agile teams? What are the roles of different stakeholders?

Statistics

Views

Total Views
6,475
Views on SlideShare
6,364
Embed Views
111

Actions

Likes
45
Downloads
231
Comments
5

13 Embeds 111

http://blog.nordkapp.fi 32
http://www.projekt-log.de 24
http://www.slideshare.net 23
http://www.linkedin.com 12
http://nordkapp.fi 4
http://lanyrd.com 3
https://twitter.com 3
http://www.lmodules.com 3
https://confluence.tfe.nl 2
http://stream.olishaw.com 2
http://next.nordkapp.fi 1
http://user-pc4 1
http://nk 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

15 of 5 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • As a lone designer thrown into an agile process I have been struggling to figure out how the design process can be established so that it does not get drowned out. Your thoughtful and comprehensive ideas are very helpful! Thank you for posting this presentation!
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for the comment!
    Are you sure you want to
    Your message goes here
    Processing…
  • This is one of the first holistic descriptions of the agile methodology! Thank you. Everything I've read and heard about agile has been development-centric, and finding a way to integrate it into our organization that spends a lot of time on design (ixd) has been a huge hurdle.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks man, glad you like it. We hope to expand this in the future— as this was done for a 20 min slot, each and every slide could be expanded to 10-20 mins on their own:)
    Are you sure you want to
    Your message goes here
    Processing…
  • Great presentation Sami, it's good to see such a concise description of agile and how it applies to design having spent most of 2009 doing agile IxD everything you said is spot on :)
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Designing Agile Interactions Designing Agile Interactions Document Transcript

    • 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 A 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 di erent 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.