Agile Design
Ben Edwards
Agile Defined
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This is the agile manifesto as it relates to software development but it relates to software
design as well. The next few slides will explain in what ways this is applicable to web design.
Resources:
http://agilemanifesto.org/
http://www.martinfowler.com/articles/newMethodology.html
http://www.agilearchitect.org/agile/principles.htm
http://www.agileplanet.org/
http://www.xprogramming.com/
Resources:
http://agilemanifesto.org/
http://www.martinfowler.com/articles/newMethodology.html
http://www.agilearchitect.org/agile/principles.htm
http://www.agileplanet.org/
http://www.xprogramming.com/
Individuals & Interactions
- People are more valuable than tools and process.
- Software is not technical. It's social.
- Interactions should be efficient and enjoyable.
Individuals should be given the power to get things done the best way that they can. They
should be given a license to be creative and innovate.
It is about providing people a way to do something that they couldn't do before. It is about making things easier for people to do. It is about enabling people to interact with technology.
"Do the Simplest Thing that Could Possibly Work", "Keep It Simple Stupid" (KISS) and "You Aren't Going to Need It" (YAGNI) are common mantras of the agile crowd. While these things sound easy or over-simplified the truth is they make a lot of sense. Simplicity in design allows the user to easily do what she is supposed to do with an application, or get the intended message from a web page. We have been moving toward this for years - it just didn't have a methodology behind it. It was just something we knew. "No, I don't think the home page is the place for the CEO's bio, the company stock price, a list of all products and services, and all the advanced search options." We knew that.
"When someone uses software, they're not ust looking for features, they're looking for an approach. They're looking for a vision." - 37signals
It is about providing people a way to do something that they couldn't do before. It is about making things easier for people to do. It is about enabling people to interact with technology.
"Do the Simplest Thing that Could Possibly Work", "Keep It Simple Stupid" (KISS) and "You Aren't Going to Need It" (YAGNI) are common mantras of the agile crowd. While these things sound easy or over-simplified the truth is they make a lot of sense. Simplicity in design allows the user to easily do what she is supposed to do with an application, or get the intended message from a web page. We have been moving toward this for years - it just didn't have a methodology behind it. It was just something we knew. "No, I don't think the home page is the place for the CEO's bio, the company stock price, a list of all products and services, and all the advanced search options." We knew that.
Working Software
- Provide smallest feature set with business value.
- Deliver fast, deliver often.
- Do. Don't document.
Agile practitioners strive to remove duplication from our processes as well. The less we duplicate
information, the more efficiently we can change and the more quality those changes will have. This
is what we mean when we say we value working software over comprehensive documentation.
Customer Collaboration
- Respect your users.
- Be transparent.
- Build relationships.
- Get users using the software quickly.
- Pave the cow paths.
The truth is that the only way for a customer to find out what they want, and more importantly
what they need, is to use the software. This is why agile teams place such a high priority on
delivering working software quickly.
What’s more, agile teams tend to deliver their software in small increments and put in the features that are the absolutely most important first.
It is crucial to have customer involvement in (re)prioritization but this doesn't have to mean external clients
What’s more, agile teams tend to deliver their software in small increments and put in the features that are the absolutely most important first.
It is crucial to have customer involvement in (re)prioritization but this doesn't have to mean external clients
Responding to Change
- It won't turn out how you thought it would.
- Don't fight change. Expect it. Welcome it.
Agile software development is all about embracing change and expecting it. As the old adage goes:
the only constant thing in software is change. Learn it, love it, live it.
Common Elements
- Small, self-managing teams
- Stories, story cards
- Scrum
- Feature-driven design
- Pairings between designers and developers
- Short iterations
- Continuous improvement of products, people, processes
Resources:
http://www.controlchaos.com/
http://www.controlchaos.com/
Tools of the Agile Designer
- Paper.
- Wireframe & prototyping software.
- Photoshop.
- HTML, CSS, JavaScript.
Axure RP Pro, Visio (especially with swipr), even Powerpoint have been know to be used for wireframing.
Agile Design in the Wild
- 37signals
- Basecamp, Backpack, Ta-Da Lists, Writeboard, and Campfire
- 3 person teams: developer, designer, and a "sweeper"
- Figure out your product's personality
- Design the interface first
- Epicenter design
- Ignore details early on
- Design for all state of your app: regular, blank, and error
- Context trumps consistency
- Copywriting is interface design
- Create one interface for all user roles
Fix time and budget, flex scope.
So far we have discussed the theory of the agile method and touched on how it might relate to designers of web-based software and websites. Now its time talk about some real examples of this working.
Epicenter design: Start with the core of the page and build outward.
Resources:
https://gettingreal.37signals.com/
So far we have discussed the theory of the agile method and touched on how it might relate to designers of web-based software and websites. Now its time talk about some real examples of this working.
Epicenter design: Start with the core of the page and build outward.
Resources:
https://gettingreal.37signals.com/
Agile Design in the Wild
- Lominger Limited
- Existing product, with existing user base
- Small team in context of larger company
- A step ahead but still on the same page
- Storyboards to HTML wireframes
- Application without guts
- Minimize styles, variation
- No lorem ipsum
- Never done
- Code. Even just a little bit
Don't use lorem ipsum - it changes the way copy is viewed - it diminishes it.
Agile Design in the Wild
- Your experiences?
Issues & Objections
- ...but my team isn't agile.
- ...but my boss isn't agile.
- ...but my client isn't agile.
- ...my team/company/industry won't accept agile.
What can I do?
Even if you don't think you can convince your team, your boss, your client, or your industry to accept the agile approach to design you can still incorporate agile thinking into your everyday.
Try Or say no to feature requests that will help few but confuse many.
Are there cases where these methods do not work?
Probably, but you know what? I can't think of one.
Even if you don't think you can convince your team, your boss, your client, or your industry to accept the agile approach to design you can still incorporate agile thinking into your everyday.
Try Or say no to feature requests that will help few but confuse many.
Are there cases where these methods do not work?
Probably, but you know what? I can't think of one.
Questions & Discussion