Introducing UX to Your Development Process
How to effectively integrate your UX Design practice into your team’s Agile Development Process
This material in this article and in Championing UX Design was a two part talk given at UX Dev Summit 2016. I recommend reading that one first. Because there is so much material in the talk, I wrote these articles for attendees to review and dig in deeper. Even if you weren’t at the talk, I hope you will find it valuable!
In the beginning, there was Waterfall.
And it was…okay.
It’s often conceptualized not by a peaceful waterfall but rather as a series of prison cells. Prison cells with high walls topped in barbed wire. The input for each cell just shows up one day. The people in that cell have no context or insight to why these decisions were made. All they know is that they better abide by them.
So this jovial group of prisoners take these requirements and do their work. Once they finish, they then lob their work over the next wall. From there the process continues.
And then there was Agile
In 2001, 17 pretty cool people got together and said, “there’s gotta be a better way.” And so the Agile Manifesto was born. It is:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The idea isn’t that things like processes and tools aren’t important, just that individuals and interactions are more important.
Following this manifesto, many new software development processes were born. The most popular of these are Scrum, Kanban, Lean, and Extreme Programming. Scrum is so popular, in fact, that when most people hear “Agile” it is what they think of.
So what are we hoping for?
What do we get by incorporating our UX Design into the agile development process? It is something that, social proof can show, is a huge feat. If we do put in the work, what do we want to get out of it?
- Know the technical constraints and design with them in mind.
Simply put, a necessity of this is collaboration. Collaboration with development can help us identify design that could be technically prohibitive. This allows us to adapt before we have invested time in refining or testing a design. - Research and test before, during, and after development.
This is huge. As UX Designers, we are able to identify friction in a UI and resolve it before it even goes into development. Often with more complex interactions it can be difficult to fully prototype these experiences. Being able to test throughout the process we are able to reduce our risk and increase our confidence in the design. - Have time to design for both microinteractions and the big picture.
When we do get in the trenches it’s easy to lose sight of the bigger picture. When we are pressed for time, we often lose the freedom to design the oh so important details. It would be ideal if our process accommodated both of these needs. - Adapt quickly to new information.
Another great reason to integrate UX Design with the development process. When you aren’t working with development, no matter how hard you try, you’ll be slowed down reacting to new data and iterating on features. - Minimize documentation.
We are designers. We would like to spend our time designing and testing our work, not documenting it. A desire of integrating with development is that we would be able to reduce the amount of needed documentation for a project. - Be quick.
Simply said, if we can reduce the time from concept to customer’s hands we win.
This may not exactly mirror your list of reasons, but they will be the primary principals we will be considering when evaluating different processes.
Scrum with ‘Big Design Upfront’ (BDUF)
This is a common place for organizations to start when figuring out design with an agile process. This is because agile often comes into play only as a development thing, and design is left out of it. With BDUF, we are still holding on to Waterfall and only the development step is Agile. Let’s look at some pros and cons.
Pros
- No tight time constraints on UX Design
- Accommodates up front research and usability testing
Cons
- Requires detailed documentation
- Rare for testing during/after development
- Little to no collaboration
- Still Waterfall, harder to react and adapt to new information
- Lost work to unknown technical constraints
- Designer is focused on other work when issues arise
The biggest issues here lie in the lack of collaboration, which hinders our ability to know technical constaints early on, test throughout the process, and demands plenty of documentation. On top of that, we will have moved on to several other things before what we designed will be worked on. This can be a difficult position, and requires even more documentation of design decisions.
All in all, this just doesn’t provide what we need out of integrating with the development team.
Scrum with Just in Time (JIT) Design
With JIT design, the UX Designer is now actually embedded in the sprint that the development team is working on. Awesome, we’re integrated! But this also means that the designer must design and development must code in the same two week sprint. It also requires work that doesn’t need design to be available so that the development team isn’t sitting and waiting on you half the sprint.
This process puts pressure on our ability to recruit for and conduct proper research or do anything beyond guerilla testing. It can also be easy for us to lose sight of the bigger picture and design things that don’t consider application wide side effects or introduce inconsistencies. Again, let’s break it down.
Pros
- UX Integrated with team
- More Collaboration
- Less documentation required
- Opportunities to test throughout development cycle
Cons
- Very little time for design
- Not every feature gets design
- Designer on this team can lose sight of bigger picture
- Harder to do preliminary or targeted research
- Team commits to deadline to implementing something that isn’t yet designed
We’re making progress. Yet, it seems we may be hurting the team by forcing both design and development into the same sprint.
Scrum with Design Spikes
In Scrum, a spike is a week long break from the cadence of sprints. During this week an architect, or in this case designer, work on refining a big picture plans or ideas. The rest of the team work on smaller, background tasks that don’t need planning.
A design spike can provide us the freedom to do that research we need to do for a particular feature set. It can give us the time to consider the ripples changing something will make to the application. It can give us the time to think about the big picture.
If we pair JIT Design and appropriately placed design spikes, we may be on to something yet.
Pros
- Answers some of the problems with JIT
- Allows design to catch up on big projects and high level design
Cons
- During Spike team needs non-design work
- Segregates team during spike
- Can often slow down momentum
One thing that can happen is that a lot of design is complex and we end up spiking between almost every sprint. At this point all we are doing is slowing everyone down. Perhaps there is a way we can resolve this?
Staggered Sprints
Since design and implementation operate on different time frames, would it make more sense to have simultaneous sprints? That’s he idea behind staggered sprints. Both UX and Development run a sprint that then provides output for each other’s next sprint.
In sprint one, dev is working on some high technical cost tasks with no design dependency. UX is working on some design stuff to get to dev to work on in sprint 2. Sprint 2 UX reviews the work dev did in 1, and works on what dev gets in sprint 3 while dev works on what UX designed in sprint 1.
With rose colored glasses this process is pretty cool. But upon closer examination its clear we are just moving towards Waterfall again. It segregates design and development, so we lose the benefits we get from working together.
Pros
- More time for Design, research and testing
- Product tested both before and after development
Cons
- Similar problems to BDUF
- No testing during development
- Easy for design or dev to get ahead of each other
- Expects work to fit in a very particular framework
- Prioritizes design, neglects QA and other essential parts of development process
- Line back to UX often not implemented in practice
Another big problem that can happen with staggered sprints is that design may end up moving faster than development. By the end of sprint 2, they have designed enough work through development’s sprint 5. And once development gets around to that feature, the designers aren’t going to remember what justified the design decisions they made months ago.
Kanban with a UX Column
In Kanban, cards flow from left to right across a board. There isn’t an encapsulated sprint (but that doesn’t mean you don’t have deadlines). So here a UX Designer can pull a card from the top of the backlog. They are able to plan their research, create prototypes, and design the feature. Once done, they mark that card as such. When a developer become available, they are able to pull cards marked as done in design.
It is a bit like BDUF or staggered, but since cards move across the columns, a developer will be pulling shortly after design finishes. Our design work wont have to sit for as long lost in the bottom of a backlog. We do create a little segregation, but less so than either of the other two. Since everyone is on the same board, everyone is on the same team. We are all trying to move cards from one side to another and appreciate the dependencies we have on each other.
Pros
- Items flow through in priority
- Accommodates up front research and usability testing
- Team can swarm to pitch in with UX
- UX integrated with Dev Process
- Allows for kickbacks
Cons
- Requires detailed documentation
- Design is ‘done’ before dev and change can be difficult
- Designer is focused on other work when issues arise
Even though this is better, we still don’t have the collaborative environment we’re hoping for.
Lean Software Development
Lean is a methodology that has been gaining a lot of traction lately. Like any of these, it is flexible and tailorable to your organizations needs (think about scrumban or even scrummerfall).
It has its roots in manufacturing, and centered around this simple concept:
Lean UX
Lean UX builds off of this methodology and is a product development process that was conceptualized by Jeff Gothelf. You can actually read an amazing article he wrote back in 2010 about his journey with the very question we are asking here today. If you have read his book, Lean UX, its clear that these ideas are what led him to it.
There are a couple of really important differences between Lean UX and the other processes we’ve talked about. I won’t be able to cover them all, but here are a few of the big ones.
First, you start with a dedicated cross functional team. Second, the entire team starts together by defining or understanding the problem they are trying to solve. Once they have a clear problem, as a team they document what they assume they will need to do to solve it.
These assumptions are formulated into hypotheses where the team states what they believe needs to be done and why, and how they will know if they are right or wrong. By doing this, the team is creating a focus on producing some outcome, not just deploying code.
I think this validation of outcome is my favorite thing about Lean UX. It forces our mindsets into a place of learning. It encourages us to research and test, even after a feature is implemented. Many of the scrum methodologies don’t force this and make it really easy to push code and move on.
Let’s look at the rundown of pros and cons.
Pros
- High collaboration
- Team is empowered to solve the problem
- Little or no “handoffs”
- Encourages testing throughout process
- Team delivers outcomes, less focus on output
- Only process where measuring success is baked in
Cons
- Harder sell, harder to get buy in
- Team engagement is crucial
- Requires entire, dedicated cross functional team
- Can be challenging if there is a disproportionate amount of work for one domain
By disproportionate amount of work, I mean something like an immense technical hurtle that will take months of development to overcome. Of all the cons, this is the one I have faced the hardest in trying to figure out. Of course, in retroing we came up with a much better approach to how we could have gone about things. Sometimes it can just be about changing your perspective.
With Lean UX it can also be harder to get buy in, from both team and leadership. There can be a feeling of “I’m a developer, why am I wasting time doing these other tasks?” Once the team realizes it has empowerment and ownership over solving the problem this usually resolves, but that’s not always the case.
And finally, for Lean UX to work well you need to be able to dedicate your full attention to your team. If you are a UX team of one juggling several balls, lack of dedication may become a huge issue for you or other team members.
Which process is right for you?
Well it depends
If you are a UX Team of One, you will probably be fine with any option provided there is only one team worth of developers. However, if you’re involved in multiple feature sets that are simultaneously in development, it’s likely you will have issues with JIT and Lean. For this situation you’ll find most success with a Kanban approach.
Again, JIT and Lean both need a team that is willing to collaborate across domains. We get a lot of benefits out of this, but if that isn’t the nature of your coworkers, it might be a hard sell or something you have to work towards.
Generally speaking, the sprint format does create a lot of issues and tension for teams that attempt to design and develop within the same sprint. However, if Scrum works really well for your development team it might not make sense to pull them away from it yet. In this case, I would try the staggered sprints approach, knowing that I will need to do extra work and be extra diligent to avoid some of the pitfalls. I would also attending the development sprint standups and provide time to work with them as things come up as opposed to waiting for trouble.
The approach I believe in the most is Lean UX. But, as I described above, it is probably the hardest to get buy in for until your team has gone through it. A lot of them might feel like they are wasting time or that the process is slowing them down.
What we find though is that we are actually able to produce outcomes with much less time and effort than if we had followed another process. Additionally, we have verified these outcomes and have confidence in our work. It isn’t just about shipping code, it’s about solving problems.
UX and Dev sittin’ in a tree. Now what?
The most important thing is to be understanding, and give your team and yourself grace to fail. You are going to mess up in this process. Things aren’t always going to go right. When that happens, call it out. Have a retro. Figure out what you can do better next time and improve your process with that information. Let me know about what you learn.
A quick note: I didn’t leave Extreme Programming (XP) out on purpose. I’ve just only spoken to the processes I have experience with. Unfortunatley, I haven’t worked in an Extreme Programming process, and the whole thing rather confuses me. I would love to hear how you may be incorporating XP and UX Design. If I learn anything, I’ll update you here.
Finally, don’t forget about what we discussed in Champoining UX Design. As you are able to work more closely with development and accomplish more with your application, make sure you manage that disruption well. Don’t pull the rug out from under your user’s feet.
Another mantra that can help keep this in mind is:
Aim before you fire the big guns.
The potentially disruptive changes that you introduce need to be obviously better to your users, or they will resits the change with all they’ve got.
Thank you for reading!
If your struggle with integrating UX into development process is getting buy in, you may also need to dive into Championing UX Design (Check out this companion article if you haven’t already).
Thank you to the Orlando Designers group for their feedback, my work family at PowerDMS for giving me the freedom to experiment and learn, and my wife, Paige for her support. Also, thank you to UX Dev Summit for giving me a platform to speak about this topic. And again, thank you for reading.
Have some thoughts? I’d love to hear them. Feel free to comment or respond to this article, or say hi to me on twitter.
