Christian Manzella Rotating Header Image

June, 2011:

Agile with UX at 10,000 Ft

What Agile with UX Is Not

 

  • Agile is not a methodology; it’s a concept
  • Agile is not an excuse to produce less documentation; it’s an excuse to produce relevant documentation
  • Agile is not a method where any one discipline rules; it requires collaboration
  • Agile is not a solution to waterfall; it’s a different tool
  • Agile is not a system where everyone rushes in at once, but overlap can happen when appropriate
  • Agile is not viable if there is not buy-in from the top-down

 

If you haven’t already, I recommend reading the Manifesto for Agile Software Development. It’s worth reading through the “Twelve Principles of Agile Software,” instead of just stopping at the first page.

Similarities

Make no mistake.  UX design in agile is difficult.  It’s hard because Agile is hard to begin with.  Agile requires self-discipline among each team.  The larger the team, the more challenging self-discipline becomes.  It requires motivation and commitment to doing the right things for the customer.  And it will be as long as people think of them as separate concepts, competing for attention.

(Later I’ll add some diagrams showing the similarity of Agile/Scrum diagrams to the Boehm Spiral model & UX diagrams)

UX & Agile are incredibly similar, as an overall approach. This may very well be the first hurdle for many designers to get over.  The comfortable “phase,” previously enjoyed by the experience subject matter experts is removed and suddenly everyone has a say in what the experience looks like.  While anathema to some experience designers, this is a dream come true for others.  After all, this is what we try to do to architect a truly brilliant experience: collaborative discussion and design with all of the disciplines involved in the development of the software or site.  This encourages buy-in from the ground level and increases the likelihood of technical feasibility, from the start.

People

I’m just going to come right out and say it.  Successfully working in Agile requires intelligent, committed, motivated, hard-working people.  Everyone on the team needs to exemplify these values and an Agile team is truly only as strong as its weakest member.  That’s not to say you need to start kicking people off the team; but everyone on the team has to have both the acumen to see when someone needs guidance and the humility to accept guidance when it’s offered to them.

As UX designers, we need to be guiding hands, not dictators, within Agile.  Everyone has good ideas on the team.  Our role is to inspire that conversation to take place in a way that produces results and positive outcomes.  Be a culture ambassador and instill a willingness to participate in your team. Place value in every suggestion made by every team member, despite how wonky you may think it is.  When you work with everyone and step through ideas, you sometimes define solutions that you were previously blind to.

You are not in a silo.  You have to work with your developers, your engineers, your content strategists, your vidual designers.  They’re all important to your process.

Re-work

The bane of the development profession.  Doing it over.  The first thing to destroy morale and dishearten the team.  Re-work is probably pushed back on harder than any other concept in Agile.

As part of our ambassador role, UX needs to encourage re-work.  This is our team’s opportunity to reinvent.  There’s no reason to be discouraged based on “whims” of stakeholders.  The reason for the stakeholders’ feedback loop is to identify things that may have escaped us during the design and development cycles.  Own the mistakes and own the re-work.  Every mistake is a chance to learn and do it better the next time.  As an experience designer, our work is never truly done.  The world changes, people adapt, their models change.  Agile allows us to instill this mindset to the rest of our team.

Research

UX in Agile does not mean “fly by the seat of your pants.”  We’re still beholden to backing up our decisions with research and data, and, where possible, moderated interviews.  We still need to apply the knowledge we have and create elegant, simple, effective solutions for users based on their needs.

Metrics are all-important; real metrics.  Understanding what’s been done and, more importantly, watching for what needs to be done. Coupled with customer feedback, you can gain valuable insight into your users’ behavior.  These things allow you to identify the top issues that need to be solved on a regular basis.

Key to this is not trying to solve for the 1% first because it looks like a quick win.  The low-hanging fruit is the most tempting one, but not always the one that will provide the best end result for your users.  By definition, if you solve for the 1%, you risk screwing up the remaining 99%.  Don’t take a quick win at 1% when the 3, 5 and 7% are still unsolved.

Deliverables

UX in Agile does not mean throw deliverables out the window.  It means be smarter about deliverables.  Call it lean, call it what you want, but the point is not to reduce deliverables, as much as it is to reduce unnecessary deliverables.  A project may very well require exploratory sketching, personas, wireframes, patterns, storyboards, and prototyping.  Define your deliverable types and define a common language to work from.  This way the type of deliverable your provide isn’t a surprise to your teammates or your stakeholders.

Don’t marry yourself to your deliverables.  Go fast, go hard, and be willing to change and adapt.  Don’t become so obsessed with the pixel-perfection inherent in your deliverable and the level of aesthetics involved with it that you become disappointed every time you have to change it.  Don’t polish details, unless it’s appropriate to the deliverable.  Don’t obsess over the little things when they aren’t appropriate.  Separate your deliverables so you don’t have a cascade effect when you have to make changes.  Interactions, content, layout, can all be represented in different documents, allowing you to provide the level of detail appropriate to the type of deliverable only within that deliverable.

Reviews & Demos

Regularly scheduled reviews are the perfect time for presenting prototypes.  UX should present UX deliverables the same way the developers would present code, or visual designers would present comps.  Present them on paper, present them as wires, as PDFs, interactive prototypes.  You’ll be able to determine what resonates best with your stakeholders and they will truly understand the value in architecting the experience.  Regular exposure to UX deliverables helps reassure the stakeholders of your organization that you are on the right track.  You also have the added bonus of having the entire team chime in on the experience presentation, when it’s designed collaboratively.  That kind of enthusiasm for work is infectious.

One-size-fits-all

Wrong.  No.  It’s not true.  Square pegs, round holes and all that stuff.

Don’t get your head wrapped around any particular solution as the holy grail of design and development in Agile with UX.  The point is flexibility.  What makes sense for low risk features does not make sense for brand new, out of the box solutions.  Your team, and your organization will have to adapt to what makes the most sense.  This may even include adopting a different methodology altogether if the one you’re working with doesn’t make sense for your team’s dynamics.

Going back to the level of intelligence involved in designing UX with Agile, be smart.  Be smart.  Be smart.  Be smart.  Make intelligent decisions on how you do things.  Review what you’re doing in a cycle as regular as your demonstrations to stakeholders.  Fix the things that aren’t working and cultivate efficiency out of the things that are working.

What Agile with UX is

 

  • A concept promoting iterative change, cultivating a better experience
  • A chance to work more efficiently, focusing on appropriate documentation
  • A platform for truly collaborative design sessions, involving the whole team
  • A different tool to build with, allowing you to approach problems from a different vantage
  • A chance to get it right; rapid iteration allows you to make mistakes and learn from them
  • An opportunity to instill the culture of designing for the user into the organization

Designing for What Users Do

(Instead of what you want them to do)

Genius Loci is the “spirit of a place” in landscape architecture. The lighting, the path, the ambiance comprise the genus loci; and how the visitors of that place react to it, on an emotional, perceptive, and subsequent behavioral level is the result of working with the naturally occuring space. How a space is established against its natural setting dictates how we feel as we enter that space and how we manage ourselves within it. How easily we traverse the pathways within are dictated by our comfort with learning the space we’re in, greatly impacted by the space itself. All of these things contribute to a positive, emotional experience, encouraging a return.

A site launched for the first time has no genus loci. As designers, we know how we want the site to be used, but life isn’t breathed into it until the users have undertaken the onus of determining how the site is used. A website has no “natural space,” occuring in a virtual realm, devoid of any natural setting. A website’s genus loci is defined by its structure, design, and, most importantly, how users evolve to use that site. Ignoring how users have come to use a site, despite any quirks or perceived inadequacies could result in a failure for a redesign.

Missed, or ignored, because it takes place in a virtual space, an area connecting digital cues and mental interpretations, this space between grows to be is as much a part of the website as the content, the colors, the shapes and objects that fill the page. How your users have decided to interact with the arrangement of content, colors and lines, is your first baseline when improving a site.

While observing best practices is critical, users already have an idea in their head how a site works, based on how it has worked in its previous iterations. Designing away from this without any feedback from the users can have disastrous consequences. Long-time adherents to the site can suddenly feel disoriented and not have a sense of where to go. Engage your user base as an initial first step toward redesign. If you’re unable to do moderated interviews, setting up a survey online can be an acceptable starting point. Take the time to find out what your users like about the existing site and what they feel works. Examine the potential behind how they’ve evolved to using your current site.

Not to say that every crazy idea the users have are going to be the right one, but there’s great merit in putting faith in your existing users’ feedback. They’re the ones that have been using the website! Take the information you gather from them, compare it to best practices, meld it together with your ideas, and create a great experience. Improving the experience that exists, instead of trying to completely re-define it, is much easier and your users will react better to it.

Successful landscape architects look for patterns in the existing area they’re working with, respecting both the spirit of the place, and the way visitors interact with it. Trees don’t move out of people’s way, according to where they want to go. Instead, people weave their way through narrow paths and small, breakable branches, that allow them through. Their footprints are then followed by the next visitor, and then the next. Over time, a natural path clears and a walkway is established. New visitors will tend to follow that path, as an easy way to get from one side of the forest to the other. A talented architect recognizes that path, created by the natural inclination of visitors working in the existing space, and uses that as the walkway, creating the appropriate ambiance around it. Improving on the existing experience.

Agile UX: Consider Seating

With the idea behind Agile being that interactions and individuals are paramount, everyone involved needs to buy in.  Without complete participation from the team, the concepts behind true Agile are lost.  There’s an approach to bringing the right individuals together that’s so simple, it can easily be missed.  And with this approach, there’s greater opportunity for defining a holistic user experience, defined and committed to by the entire team. Seating.

Where people sit… someone inevitably brings it up any time Agile is considered, but rarely is it seen through.  Organizations quickly see to creating cross-discipline teams and putting them in a room together, at least part-time.  Or they create a space for the team to meet on a regular basis that the team “owns.”  It’s their room, their table, their walls for post-its and ideation.  This has value, of course, but it only brings the team part of the way there.

Moving to a more flexible development system allows you to break free of the restrictions inherent to classic methods.  By extension it can also let you break free of long-held organization principles.  Putting together a cross-discipline team, made up of the people that will be working on a given project, is an important first step.  It also establishes the natural order that occurs in the project.  There is and will always be a natural, sequential progression to how anything developed by a team is created.

Special attention should be paid to that progression.  That progression represents the ideal way the team should sit with each other.  This allows those that need to work most closely together to do so, by seating them next to each other.

As an example, assume that my (incredibly simple and not real) process was to have a user experience strategist design a strategy, to hand it off to an information architect, to hand it off to a graphic designer and a content strategist, to a business analyst, to a web developer, to a database administrator, to a programmer, all with project manager oversight, who coordinates back with the user experience strategist on the appropriate approach to the project.  My process (Not intended to represent any actual process. Seriously.) might look like this:

 

I would expect people in the “steps” to work closely with those in roles that occur naturally as a tangent to them, before and after, and even at the same time as them.  I can identify based on my team’s needs and experiences who will need to work the most with each other.  This isn’t about popularity, or who gets along best with who.  No one should care about where they’re most comfortable sitting.  Identifying that the UXS is going to work a great deal with the IA, I want them sitting next to each other.  Knowing that the IA is going to work a great deal with the CS, I want them sitting next to each other.  The CS next to the GD, and so on.  My seating arrangement, around a large table, might look something like this, based on those I determined work most closely together:

When changes between iterations are identified and start, they can happen anywhere.  That’s another big part of the point of Agile; change. It’s best to not play musical chairs and have to set up meetings when they do start.  If the changes surround a design change because the copy is too large for the space allotted, the above seating allows the IA, the GD and the CS to quickly pull up and discuss the challenge.  Similarly,  the WD has easy access to the BA for any requirements verification, and the Programmer and WD are set up to be able to work hand-in-hand as they develop the interactions, together that correlate to the data set worked out by the DBA.

More importantly, the close proximity of team members to each other allow them to work together, during the planning and defining stages, to create a unified vision for the user experience.  Every person on the team has an equal opportunity to participate in defining the user experience, according to their role.  With everyone having a voice, and a part, the initial definition of the experience, and all the permutations that occur, are the result of an entire team working toward the best possible outcome.

The seating, like all things Agile, has to be defined by the organization, the team, and the projects at hand.  It may even vary from team to team within a given organization, based on how each of those teams best operate.  That’s okay.  It’s part of the point.  Each team has to make sense of what they do, and sit accordingly.  The key is to make sure you are actually taking advantage of what’s going to make working together more efficient.  Make sure your choices can be justified based on who you work with.

There is, of course, some sacrifice of “personal space” and “privacy” by people on the team. However, if your organization is flexible enough to acknowledge the merits of Agile and unorthodox seating as steps towards improved software, other policies can be adopted to allow people their sense of space.  Allow spaces for reflection or quiet/solitude time to work on intense personal tasks in places with scenic views.  Or set up smaller, working rooms, designed for one or two people to be in.  Let people work for an hour or two at the local coffee shop.  As long as no one falls into an abusive pattern or uses a space as a way to be apart from the team, this will work out really well.

While the greatest value for a project is collaborating with the other roles in your development iterations, it’s important to not lose sight of the value in working with others within your discipline as well.  If you work with an organization large enough to have multiple teams, it’s important for the common roles on those teams to meet on a regular basis.  This allows all of the Information Architects to share patterns.  It allows the Visual Designers to come up with common styles.  It allows the Programmers to continue working from a common class library.  And we tend to learn from and teach those who do what we do most often.

Agile can get messy and it’s easy to fall into the chaos that unchecked Agile can become.  Use research; you’re not the first to do “it,” whatever “it” is.  Gather data and make judgments. Rely on your ability to think. Every team will find the right level of organization to support their needs and their project’s needs.  Sitting with the people that you will interact with the most helps cut down on some of that chaos and establishes some order from which you can work more efficiently.