Squeezing the Design Process into an Agile world – a real world story

You’ve just been assigned to your first project. It’s to build a product. You’re excited and nervous at the same time, you think – “finally a project I can sink my teeth into, I can adopt design thinking, do my user research, find user pain points with the client and come up with a killer design that everyone loves and I’ll be the new star of my organisation”

You walk into your client’s office, and meet the “scrum master” what’s that again? You think. Oh yeah – this is one of those Agile projects. That’s cool, you think, as you quickly rummage through your notes from class and try to remember all the lingo, like product backlog, sprints, scrums, features, user stories, epics…hang on where do I fit into all this? Nevermind, I have to rush to my first scrum meeting.

Everyone is standing around a wall of post-it notes. Post-it notes! A UX designers’ best friend. I’m home. Wait a minute. They’re all saying a bunch of things I don’t understand and turns out we are already half way through the project and all the product features have already been decided on by a BA or if you’re lucky enough a previous UX designer that was involved in the ‘discovery phase’.

“Peter – can you make this section stand out a bit more, try a few things and can it be done so we can release it this sprint?” asks the scrum master. “Sure” you reply. Wait a minute, did I just get cornered into making things look pretty. Is this what I signed up to? Why am I making it stand out more?

You take your seat next to a developer after the scrum meeting feeling a bit deflated and introduce yourself. After speaking briefly, you realise he has a very different take on what UX design is and you think to yourself this is going to be a long uphill battle.

Fast forward to the end of your first sprint, you’ve slightly tweaked some features that needed to be finished and helped the dev guys put it into HTML and CSS.  You think you’ve gotten your head around the whole agile way of working, and are beginning to understand things like velocity points. You haven’t exactly gotten to work in the design process, but at least you’re learning how agile works. It’s time for the first ‘show case’ meeting and as it is an internal project you manage to sneak in some guerrilla testing that morning with users by walking around and asking them to have a look at the new features that’s just been released. Generally, they seem to get it, but you do notice a few holes in the design after seeing them struggle to use some features. At least now you can somewhat justify your design decisions and have some ideas for the next sprint.

It’s come time for a ‘retrospective’ and your team mates were nice enough to say that what went well was your onboarding. You personally thought it was a train wreck but at the same time are relieved, they have some trust in your UX abilities, even if you feel you didn’t really do any UX work. It comes time to voice what didn’t go so well, and you say something along the lines of the “the designer should be working on designs a sprint ahead of the dev team” you’re not quite sure if you even understood what you just said. Then the product owner chimes in and says “my boss doesn’t really get the my favourites section”. Finally! A chance to state that users weren’t getting it either. “I could use some of the next sprint to test out the ‘my favourites’ section with users to see where they are struggling and update the designs based on that” you say. “Great! How many points?” she replies. How many points?  How do I answer that? I’ll have to first think of scenarios to test, then test the current product, then update the design based on my findings, then make a prototype, then test again, then update, then…. Oh no they’re looking at me “umm 8 points” you say. “Can the developers work on other backlog items while you’re working on that?” She asks. “Yeah there’s other features to work on in this sprint, we can do that in the first week” replies one of the developers. Ok, so now I have not the whole sprint, but half the sprint to do this. Oh well. Looking back I could have said “how about we leave the development of the newly designed feature till the next sprint while I work on the design this sprint” Experience and a bit of confidence that you will inevitably build will ensure you will say this next time.

And thus, you can see the conundrum that many designers and no doubt, you, will face when working in an agile project.

“Although any sprint can theoretically aim to address design issues, the pressure on designers to not hold up the rest of the development team once normal sprinting has begun is enormous. However, the time needed to explore very complex design decisions could drastically slow down team momentum.”

 

Fitting Big-Picture UX into Agile Development, Smashing Magazine, Nov 6, 2012

I could have written a blog about things like sprint zero, with diagrams demonstrating how a UX designer should be involved in the discovery phase before user stories are created or how a UX designer can work a sprint ahead, but there’s plenty on that. In reality this doesn’t always happen. You may be thrown in mid project, or mid sprint! and it’s going to take time to get to know your team and how they work. The real world is a mess, as is, design. Yes, there is a design process, but as a designer you will realise, that the process isn’t always linear. You’re going back and forth through that double diamond (or whatever dogma you’ve been fed). You sometimes have to make compromises, you sometimes have to wait it out and gradually, hopefully, with your speaking prowess, more user adoption and your passion for design thinking you will convince your agile team mates to start allowing more time for human centred design before and during an agile project. Don’t be disheartened, pick your battles, and remember at the end of the day it’s not a process war, everyone on the team wants to build a great product, it’s how you get there that can get messy – something that design and agile have in common.

Ps – I will include a diagram after all.