We are jumping right into the meat here. I know this blog is pretty new, but this problem is not, and it’s one that I deal with every day.
How do user experience designers fit into an agile development team?
If you’re unfamiliar with agile development in a software environment, it’s a process of building software that comes from the Agile Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
For a more practical explanation, agile develops in short, fast sprints, releases often, and iterates on features rapidly. Die-hard agile fans will tell you that there is a right way and a wrong way to employ agile methods. Most companies, however, use the strategies slightly differently to learn what works best for them. At TribeHR, we are always changing and adapting as the company grows and we find strategies that work well for our team. One challenge that we have always faced is how to fit feature design into the agile process.
To fully explain the problem, I’ll quote some UX experts that were interviewed for UXMatters:“Agile is a development methodology and UX design is a design methodology, so right there is a reason why there are gaps,” answers Tobias. “Principally, in agile development, developers are fully aware that they don’t have all of the inputs and knowledge up front—that is, they don’t know what the final product will be like until they’ve completed the last iteration’s build. During each sprint, the team looks at a part of the whole product and works on that. Therefore, the team acquires knowledge and understanding during the individual sprints. Yes, there is a master set of features that the team determines up front and that carry through in the project’s backlog, but there are a lot of issues and details that they’ll identify during the course of the project. For an agile purist, there’s nothing worse than ‘Big design up front.’ In contrast, in UX design, we want to know everything that’s relevant up front; that’s why we make so much effort to carry out proper context-of-use analyses. We want to anticipate and envision the product holistically—and not just its parts—as soon as possible. What will it look and feel like? This does not mean that we take only one shot at the design—we do ideate and iterate, but we typically want the knowledge to be as complete as possible at the beginning. For UX folks, it’s all about the big design up front, because we want to define and design the product as one holistic user experience and, at the same time, minimize concept ambiguity during implementation.”
To summarize, good design requires time: time to think about the feature from different angles, time to brainstorm, time to research, time to wireframe, and time to collaborate. When that time is taken away, the result is often a poorly designed experience that misses the mark. For development, that’s ok – the agile method tells us to iterate, fix, and release. For user experience, however, that method doesn’t work so well. We don’t want to constantly be changing the interface that users see. Also, we want to make sure that we’ve done the big picture thinking about how the feature will fit into the software before we even start working on the details.
So, now we have a good grasp of the problem. As I’ve mentioned, this is one that I’ve been working in everyday for the past year and a half. Over that time, I’ve tried a number of different strategies, but I’ve never really been satisfied with the results. Until now. Over the past two months, I’ve been tweaking this process to attack epics from a design perspective. Ideally, this process takes place a week or so before development, so having a good backlog prioritized is key!
Designing in an agile environment
1. Define the problem.
The first step in designing a new feature is to look at the problem that you are trying to solve. The definition of this problem comes from a few different places: the customer, your support team, stakeholders. What exactly are you trying to accomplish? It’s important to get to the root of the problem, rather than getting potential solution input (eg. the profile list should allow me to do X is not a problem. As a user, I can’t find a way to do X is the problem).
2. Hypothesize a big picture solution informed by the design principles.
In my last post, I talked a little bit about design principles. I am a firm believer that each project should have it’s own principles. Here’s a great example of some principles to borrow from designer Joshua Porter. Once you’ve decided on principles for your project, use them to help solve design problems. Look at the problem in the perspective of the software as a whole. Whiteboard, brainstorm, reframe, and come up with some initial assumptions that can drive your solution.
3. Break it down so that you can take small steps keeping the big picture solution in mind.
Here’s where we get a little more “agile”. Once you’ve got a good grasp on how you want to solve the problem, break the solution down into smaller pieces. Even a complete site redesign can be broken down into navigation, content area, footer, blog posts, etc. Agile is all about doing one thing at a time rather than everything at once.
A great example of this is my current project at TribeHR of updating the navigation structure in the software. The general goal was to improve the visibility of different areas, and increase the speed at which users could move around the software. This was broken down into a few different steps:
- Update the main navigation
- Include drop down menus
- Give users access at adding new items easily
- Give users access to administration tools easily
- Give users access to related reports
These five steps help improve the overall navigability of the website, and are much more likely to get built in a sprint that undertaking a whole “Improve the navigation” story.
4. If replacing a feature, take baby steps towards a new workflow rather than removing one altogether.
It happens to everyone: you release a new feature and users start using it in ways that you didn’t anticipate. The workflow is wrong, the feature isn’t properly integrated with the rest of the software, the results are poor. It’s time to revisit the feature as a whole. You get customer feedback, do some competitive research, and embark on version 2.0.
I know how it feels to have a major feature that you don’t like in your software. The knee-jerk reaction is to rip it out and start over, trying to solve all the broken things at once. The problem with this type of solution is that it usually reproduces the original problem. You can’t monitor the results of a huge feature change that completely changes the interface and workflow. Rather than tackling the whole thing at once, the agile process prefers that you make small changes, and then monitor the results. Try re-factoring one step in the workflow and see if that increases usage. Add or remove elements and talk to your support people to see if they get any feedback. Taking baby steps ensures that you can monitor the changes, and allows you to confirm (or deny!) that the changes you are making are the right ones.
5. Spec with customer and development.
Making sure everyone is in the loop is so important. No one exists in a vacuum, and everyone on your team has knowledge that they can contribute to designing a solution. At Tribe, I make good use of our customer-facing people to make sure I know what the problem is. I also go back to them with a solution when I have some rough ideas. Bouncing solutions off of customer support reps can often generate excitement AND make sure that you’re addressing the problems that the client is presenting.
At the same time, I’m no developer, and I don’t want to create a solution that is over engineering. While I’m working on a spec for the feature, I make sure to run everything passed at least one member of the development team to ensure that I’m not designing a behemoth.
On that note, it’s also worth mentioning that our feature specs are not strictly technical. We use them for communicating with sales and development a like. The specs are written in friendly language (with a technical section at the end of the code talk), using scenarios to outline the need, problem, and solution, screen by screen details, non-goals, etc. Making specs that everyone can read and understand benefits EVERYONE in the long run.
6. Wire frame / design
Once the spec is done, the stories, have been created, and the iteration is planned, I can look out a few weeks in advance to see what specifically is coming up. If anything touches the user interface, I try to make sure there are either wire frames (we use UX Pin) or high def Photoshop mock ups for non-interactive stories.
7. Build and release.
Enter the regular agile iteration! Ideally, every story has a spec and wire frames associated. One spec and wire frame may cover a whole epic, but at least the developers are informed on the bigger picture while being able to dive into the details.
8. Test everything.
Unless you have a close relationship with all of your users, it can be really hard to tell if a feature release has been a success or not! For UX designers, track hits is often not enough. We need to know HOW the user is interacting with the new feature, and this is something that I’m still learning on how to track. We are currently using a combination of Google Analytics and Apptegic to test how features are being used. We also have some product champions that give us regular feedback, which is awesome!
Getting metrics is one of the most important and often enjoyable parts of my job. I find it really cool to see how many people are using the software, what people seem to enjoy, and letting the user really drive the process of improving the software.
9. Revise the hypothesis based on the results.
Sometimes, looking at the metrics can produce results that you didn’t expect. Dan McKinley from Etsy gave a great presentation on his experience on building out a new feature that didn’t go as expected: Infinite page scroll. His presentation was one of the major influences to my current process. What we can take from his experience is that things don’t always go as expected, and sometimes you need to revise your original solution based on the results.
Don’t be afraid to make changes! That’s what agile is all about, right?