Agile Survival Guide for Designers

Are you a designer about to work in agile teams? Or are you a scrum master and don’t know how to handle your ever so grumpy creatives?

Red Badger works with agile methodology and I really like the way we work here. Surprised to hear a designer liking an agile team? I would like to share some tips that designers and scrum masters can follow to make designer’s life in agile somewhat enjoyable.

Things are getting better

My favourite horror story was along the line of…

I turned up on a new project and they asked me to design up a login button. I don’t even know what site we are making!!

Fortunately I‘ve never had this before, but I can imagine that could easily happen in more tech driven teams.

Designers are used to working in waterfall and it suits them very well. The fundamental premise of agile methodology doesn’t sit very well with the design ideal. The difference between agile’s ‘Do just enough to make it work’ and designers’ ‘Keep pushing until it’s brilliant’ mentality are quite hard to compensate. On top of that, visual design is such a subjective art. You can’t say ‘It works’ like you can with coding. So how do you know when visual design is ‘just enough’? No wonder designers find the agile process painful.

But. Things are getting better.

These days, people are more aware of importance of good user experience including visual design – it is becoming an integral part of Minimum Viable Product. (Interesting read about it here on Startup Blender: Minimum Viable Product vs. Minimum Delightful Product). Advances in CSS and HTML allows us to be more ambitious in terms of visual expressions = there are greater expectation on presentation standards. There is a willingness to accommodate user experience process into an agile one. Let’s take advantage of that.

Tip 1: Phase 1 for user experience and backlog creation

This is optional, but I highly recommend having a separate phase for user experience and developing Look & Feel. Especially when whatever you’re making has no brand to work from and/or the brief is loose.

It’s not Sprint 0 – This is a phase BEFORE Sprint 0. At the beginning of Sprint 0, the team should have a good idea of what they are making, and Phase 1 is there to make this ‘idea’ good.

It’s a time to look at the concept in wider context. It’s a time to create Look & Feel, stress test the ideas to create focused backlog, and run it by users.

And it’s not a waterfall in disguise. You’re not solving all the problems, but it’s your chance to have a broader approach developed and agreed. Sprint 0 is there to refine what to be developed during Sprint 1. And you have all the rest of sprints to get things right*.

(* Scrum masters and project managers – you may need to think about keeping designers involved a little longer…)

Tip 2: Be part of Sprint 0

It’s probably very obvious but it’s crucial for Design and UX to be a part of Sprint 0 to make sure some core visuals are designed up for the Sprint 1. Designers and UX need to stay ahead of development to minimise UI changes later on.

Tip 3: Design not ready? Use Bootstrap.

UI devs don’t need to have the ‘button designed’ on day one these days. There is Bootstrap (or something equivalent)! It looks decent and a quick way to start seeing and testing functionality without the final design applied. So don’t bother with half-baked-hastily-put-together designs. Ask them to use Bootstrap in the meantime.

It’s still important to have Look & Feel developed in Phase 1 though as this will inform the layout and construction of the page, so when you finally get around to do the design, there is a minimum pain for UI devs.

Tip 4: Things are agile for everyone

Sometimes there is a bit of unfair expectation by other team members that when you hand over any design, it should be FINAL and should not change. I agree that’s probably the case if you’re working in waterfall as you have chance to design up all the pages in details, look for inconsistency etc. But if you’re working in agile, designers should be allowed to improve things in later sprints as much as devs are.

Mind you, I’m not saying you can put off ‘getting it right’. You should try that all the time anyway. But if the design needs improving, it needs improving. Insist on it.

Tip 5: Talk to scrum master and project manager

Before any project starts, it’s good to talk to the scrum master and/or project manager over the project plan. Do raise an alarm if they are planning to make you start at the same time as UI devs. You need to explain and convince them why you need some time upfront.

Here is one example. Imagine that you’re putting new tiles up in your bathroom. What would you do first? Measure the walls? Decide on colour schemes? Choose the tiles? But I bet you won’t just pick one tile of certain design and slap it in the middle of the wall before thinking about all these things.

Designers need to think about wider context. How much wider depends on the project, but you will definitely need some time upfront to make sure that you are not creating Frankenstein with plasters all over. Remember putting plasters on Frankenstein takes time – a lot more than making something good in the first place.

Tip 6: Talk to UX

Always, always start sketching with UX. Don’t wait till you get a wireframe because you won’t like it anyway and they won’t like you for changing it so much. It’s much quicker to sit with UX and sketch it out together, so you’re all on the same page. Then you can split from the UX to do what you’re better at based on agreed approach.

Tip 7: Talk to UI devs

It’s good to talk to UI devs about design issues from an early stage too. After all they have to code it. I always ask opinions and suggestions from UI devs (and everyone else for that matter). They know an awful lot more about techs than you do and some – especially the ones I work with here – have a really good eye for design & UX.

By involving them in the design early on, it becomes much easier to improve things over sprints as the benefits and aims of doing so are clear to them.

Tip 8: Talk to everyone

I know it’s obvious, but it’s worth noting. The well working agile team talk to each other. We’re all trying to solve the same problem. You’re not tossing your work over the fence. Be pragmatic, and don’t be too precious – good designs are good whoever designed it.

And remember that you’re the champion of good visual design. Make a noise and be heard.

And well done, you made it work

There is definitely a stronger sense of contributions to the final product in agile team. Probably because you remain part of the team until very nearly the end of development.

Also it’s a rewarding experience seeing your design turned into reality right in front of you. It’s your chance to refine your design as it’s being built. So try it. You never know, you may even like it.

Sari Griffiths

Chief Design Officer

More from Sari