As an interaction designer working in an Agile environment, I’ve recently been asked by several colleagues in non-Agile arenas – folks in agency settings, consultancies, or in-house software companies – what it’s really like in terms of design workflow and output. Their questions have touched on everything from the day-to-day differences to the quality of the designs coming out of the process, and their perspectives have ranged from casual-and-curious, to scared-and-skeptical (e.g., “Oh, it’s just a fad” and “There’s that vast Agile agenda again.”)
Well, that got me thinking. What were the real differences, anyway?
The Agile Agenda
Two years ago, I was brand new to Agile software development and pretty naive overall when it came to understanding competing development methodologies. These days however, I feel like I have some ground beneath my feet when talking about development processes and their underlying philosophies. In taking a step back to consider what it has really meant for me as a designer these last couple of years, I tried to tackle questions like:
- What am I doing now that’s different?
- Did my previous skills and user-centered design approach still apply?
- Did I need to learn anything new?
And, perhaps most importantly:
- What has the overall quality of the user experience really been like?
The following takeaways capture some of the things I’ve learned along the way. This is simply my perspective with a little insight on what the transition has been like. What it is not, is a guide for what you and/ or your team of designers should be doing. I’ll leave that to far more knowledgeable folks to chime in on. Besides, one of the major tenets of Scrum is to do what makes the most sense for you and your team.
one of the major tenets of Scrum is to do what makes the most sense for you and your team.
(Note: It’s probably helpful to at least have a rudimentary understanding of Agile Software Development at this point. Check out the Wikipedia entry to learn more.)
Designer as Design Facilitator
First, a little context. One thing that Agile newbies should understand is that the importance of the team and its dynamics are paramount. Scrum teams are small, self-organizing, and cross-functional. They should include representatives from design, development, and quality assurance. Work is committed to for a finite period of time – known as Sprints, which typically range from 1 to 4 weeks – and the team takes on a feature(s) that it feels it can deliver in that amount of time. And “deliver” does mean working code that is technically releasable to the masses.
I work very closely with the developers on my team and even co-locate occasionally. That in and of itself isn’t ground-breaking stuff. However, what I’ve found is that a large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.
A large part of my job these days revolves around continually fostering communication within the team, as well as with peripheral stakeholders.
Since the focus of the team is to consistently work on items that deliver the most value to the customer, distinct roles within the team are sometimes blurred. Everyone contributes to the best of their abilities given the priorities, including providing input on design. This is especially true when it comes to new features with undefined requirements, but it really has to do with the intimacy of the team and the immediacy around the thing that we’re working on.
Let’s say a Product Manager gives the go-ahead on Feature X because she sees a glorious market opportunity. Once that is communicated to the team and prioritized within the backlog – basically a to-do list consisting of “user stories”, which are written in non-technical language to describe the value of a feature from a user’s perspective – it is up to the team to decide exactly what to create. The product team may still have the final say, but it’s up to the designer to lead the early efforts. That includes applying the tools of her trade in the way of user-centered design principles, coupled with a clear understanding of the business drivers and the technology behind it all. Although some of you reading this may be saying “Well, I’ve been doing that all along, anyway”, the difference here is that it is now being recognized. More on that later, though.
When we embark on a new user story, one of the first things I do is generate some ideas and hold early brainstorming sessions with my core team. This allows me to corral the different ideas and understand everything from technical feasibility, to ballpark estimates on the potential development work involved. Sometimes the conversations go astray or become focused on implementation details, so it’s my job to get them back on track by grounding everything in the end users’ goals and expectations. And everyone likes to be heard, so there’s a good deal of diplomacy required as well.
This ongoing dialog helps to ensure that we as a team are headed towards an appropriate solution and it’s these conversations that the designer needs to facilitate, time and again. (By the way, all of the above involves getting user feedback early and often, but as designers reading this article, you already knew that.)
Again, the headline here is that it’s all about the team. Designers don’t design in isolation and then simply hand-off a design, never to be heard from again. It’s a much more collaborative and tightly integrated effort between the designers, product management, developers, and of course, users.
OK, so all of the above assumes that a Designer actually has the necessary time to conceptualize, validate, and then iterate accordingly. Unfortunately, that’s not always the case with Scrum and this is one of its downsides; which, by the way, is also frequently cited by its critics – especially in the way of shortcomings related to being truly innovative.
When done properly, a “Sprint Zero” is introduced to allow designers to do their upfront discovery ahead of any coding. However, given the flexibility inherent in a process that is beholden to shifting business needs, priorities for the team do sometimes change from Sprint to Sprint. That allowance is, of course, one of Scrum’s key value propositions. It’s also where being nimble on the part of the designer needs to come into play. The old-school way of having a rigid, stepwise process doesn’t apply terribly well any more for delivering complex software that is useful, usable, and ultimately timely. Design processes need to adapt to some degree as well.
All of the above however, doesn’t mean that design thinking isn’t valued; it’s just that designers need to be flexible and shift priorities in accordance with business objectives. If you’re a designer that finds themselves deeply committed to a design or unable to let go of a particular project, you’ll need to acclimate. Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.
Designing within Scrum means being able to shift as needed and handling ambiguity well. Really well.
(For more on the pros and cons of incorporating User-Centered Design within Agile, do read Anthony Colfelt’s incredibly insightful article).
The Lovely Bones
As mentioned earlier, Scrum understands that the needs of the business and its customers (i.e., requirements) will change and almost embraces that mantra. However, because Scrum also calls for working code as soon as possible, you may be thinking that those are opposing forces at work. However, the truth is that it can work. And once again, this is where our fearless designer comes in…
Remember Feature X and how the designer was brainstorming what it could ultimately become? Well, if we join our regularly-scheduled programming already in progress, it’s the designer (and potentially researchers) that are coming up with the building blocks for an incrementally feasible strategy.
What are the core features that users need? Which functionality can they live without (for now)? What could add some wow-factor? In other words, what’s the Minimum Viable Product (MVP)? Getting user feedback is crucial at this juncture to help determine what the bare bones will be – sometimes referred to as a “walking skeleton.” Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next. To a large degree, releasing often tends to keep your designs and product honest.
Designers help define what gets released in order to then get feedback on what’s working, what isn’t, and what’s next.
As with any process, there are very real trade-offs involved. Given Scrum’s inherent proclivity to release something sooner than later, the big question often becomes “is it good enough?” This is why designers working in Agile need to be well-versed in communicating the business value of good design. Making business folks and developers understand why user experience matters is critical to the success of your product in this environment and it’s a never-ending crusade.
Incremental Design While Keeping Your Eye on the Prize
In working to define a Minimum Viable Product, the first challenge is thinking through what can be built in order to satisfy marketplace and user needs in the here and now. Again, we’re back to that notion of immediacy.
Because a designer goes from defining high-level requirements to specifying the very concrete steps of what to build and when, the trick is to keep your eye on the big-picture. I’ll have to admit that I’ve found this to be one of the most challenging aspects of designing in this environment. Once you determine what to build as bite-size pieces of functionality in order to get something out, it becomes increasingly difficult to keep a systems-level perspective on the holistic user experience – i.e., trying to avoid a Frankenstein-ish product – when priorities shift and you have to come back to a design at a later time.
Take any great iPhone app as an example. It doesn’t include everything-and-the-kitchen-sink, but instead distills the core set of features that users will need and then attempts to make that experience really good. This doesn’t mean that you can’t add or improve things at a later time; it’s just that you try and give customers the best you can with the bare essentials first. (One could even argue that the entire smart phone revolution is founded on this very principle. Otherwise, users would have surely dismissed the complexity inevitably inherent in designers lazily porting over a desktop experience into the mobile world.)
It’s probably no surprise at this point that design documentation is kept fairly minimal. The close working relationship among team members means a great deal is communicated face-to-face via sketches, whiteboards, and simple wireframes. The goal of design work (i.e., creating deliverables in the way of experience models, flow diagrams, and mockups) is really to communicate ideas to the team so as to jump-start the development process.
Once developers begin coding, I make sure to check-in early and often to offer advice and provide any additional documentation, repeating as necessary. Documentation still exists and is important, but it’s kept lightweight to capture the essence of an interaction and consumed in a just-in-time fashion.
For those designers coming from more traditional development backgrounds, you may be relieved that large documents with incredibly detailed specifications, footnotes, and obscure corner-cases, are a thing of the past. However, as indicated above, the time you have to think through a design is also compressed.
The big takeaway here is to use your design time wisely and create only as much documentation as is absolutely necessary to communicate your ideas effectively. It doesn’t need to be pixel-perfect, unless of course it needs to be pixel-perfect to get your concepts across.
create only as much documentation as is absolutely necessary to communicate your ideas effectively
When was the last time you really thought about what you and your team were doing? Did you ask questions like: How is this process going overall? What’s working and what isn’t? Should we be doing things any differently?
Well, with Scrum, facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint. They offer the team an opportunity to acknowledge strengths and weaknesses with unabashed transparency. I’ve found that the very nature of this exercise forces designers to focus more on what’s important by continually questioning their own process. This is especially beneficial when it’s coupled with customer feedback from designs that are live because the team is getting stuff out more often.
facing yourself in the mirror is a standard option courtesy of “retrospectives” after each and every Sprint.
Hopefully you now have a little insight as to what to expect with Agile, as well as some awareness of the trade-offs involved. Upfront design and research are sometimes rushed and the ever-present threat of compromising user experience quality in favor of releasing something – which frankly feels like a gravitational pull sometimes! – are very real challenges. That said, not going astray and loosing your moral and/ or design compass by building unnecessary features and going down dead-ends is ultimately a good thing.
And rest assured designers, there’s still no shortcut to delivering a great user experience. The same, core user-centered design principles you know and love still apply and are highly valued. In the end, it’s not that drastic of a shift and designing within Agile just keeps you on your toes a little more.
My parting advice: be nimble, collaborate with your team as much as possible, and don’t take an uncompromising, hard-line approach to process guidelines. And most importantly, keep your eye on the prize.
This is the first of a two-part series. The second article, Designers as Product Owners, will focus on additional responsibilities designers can take on within an Agile organization.