In September 2018, on the company’s 8th birthday, Rabid became Ackama - this was to reflect that fact that we work on large digital ecosystems, and given that nature is the largest ecosystem in the world we wanted a name that came from nature. Ackama, or Makamaka, is a small bushy tree with white flowers and red seeds. It’s found on the coast from Whangarei north.
A Meeting of the Worlds
When I came aboard as the designer at Rabid, I was thrown straight into an Agile development workflow without much warning. I was a bit overwhelmed, as one generally is at a new job, but it was exacerbated by the fact that:
I didn’t know Agile. At all.
Agile and design != instant success.
As a designer I was massively outnumbered by developers.
Eek! Not to worry, I’ve gotten to a good place with all three of these things and I’m happy to share my findings.
My context is interesting because Rabid is a fairly unique group, in the sense that their developers are all very open to design input and generally welcome good design as a help rather than a hindrance. This made the transition to working across multiple projects in an Agile fashion much easier. However, as I’ve been going along, I’ve run into some interesting general gaps between what Agile supports and where design happens.
I also held a group discussion with @kellective and @amandadorrell at the Gather conference in Auckland a few months back, with a room full of designers and developers. We got a pretty resounding consensus about where tension points lie and also where people have found benefits:
Problem: A lot of tools that are designed for use by Agile teams are development-focussed without much consideration to how design might factor into the process. For instance, it can be hard to make a story in Pivotal Tracker for design. Designers are rarely designing siloed, modular bits and pieces, and are generally more focused on the big picture. It’s hard to really get any value out of a story that sounds like this: “As a user, I want the site to look consistent with the style guide so that I can navigate easily and understand what’s happening.”, especially when constrainted to a two week sprint. Not only does this story need to happen across the entire project, it also doesn’t really lend itself well to sizing.
Don’t write design stories at all. Kind of scary if you’re a team who relies entirely on Pivotal, but if your team understands that design extends across the whole project, it’s not so bad. This requires the designer to be an active communicator about needs and progress in sprint reviews, so that the team is across what is going on.
Write very simple design stories that reference material like wireframes and style guides, like “Apply styling to X feature”. This is a bit better, although it can clutter your story tracker. At least design is in there getting points assigned to it. Designers should participate in the story sizing meetings if this is what you’re doing.
Add design as a task under developer stories. I’m not a huge fan of this, but it’s what we’ve been doing lately and it works alright. Again, it’s good for designers to have input on sizing stories in this way.
Many designers hate iteration, or at least wish it didn’t happen to them. Waterfall design and non-iterative design are both dying a serious death in the web design world, and for good reason. They’re restrictive, boring, and rarely facilitate good collaboration between designers and developers, as well as non-technical stakeholders who are involved. Agile brings the whole team, including the client, to the table throughout the process, so you can hear what people want and also how things change across the life of the process.
If you do the designs and move on to the next project, instead of being a part of the Agile team, you’re missing client feedback further down the timeline, which could render your designs less effective. If you’re an Agile designer, you’re there in the sprint reviews and the day-to-day, able to present each phase of the design as needed, and are able to response to anything the developers or client might need from you.
The issue with being stuck in the fray all the time is that you can’t be designing while the devs are building the same piece of the project. It’s ideal for design to be a sprint ahead of the dev process for a particular feature, that way, when the devs start building, they have your design to work from, and you can also provide in-the-moment help. This doesn’t always pan out, but with good planning, it can happen.
Making beautiful, pixel-perfect Illustrator/Photoshop/Fireworks/Whatever mockups is a fun practice that many designers enjoy doing. You can take hours to make a beautiful rendering of what you’d like everything to look like…but the reality is, at the end of the day, either you or a front-end dev is going to have to implement that in code. Additionally, what happens when something changes? You have to go back into the program and resize boxes, shuffle spacings, and (heaven forbid) rip out a whole section and start all over again.
As I said before, waterfall design/non-iterative design are on their way out. Taking days to design a “finished product” isn’t the name of the game anymore. Agile encourages designers to be, well, agile. Make some wireframes, user test those wireframes, and iterate on them as you go. Wireframes are quick and dirty, and leave a lot to the imagination in the way of anything other than layout. However, that’s actually a good thing. Combine these easy-to-iterate wireframes with a simple style guide, and you’ve got yourself a good start towards an easily edited framework for designing and growing with a project. When circumstances change, it’ll be easy to pivot and accomodate new feedback from clients, users, or your team.
Unfortunately, there’s not much room for the “artíste” in this equation. A lot of designers don’t like that, but when you’re not siloed away from developers, you need to drop your ego and start being a team player. It’s really satisfying to make a “finished piece”, but we’re not artists, we’re providing a service, and we need to be ready to work with others and accomodate the requirements of the client and user. I’ve had to adjust my attitude over the past few years, and now I regard a good designer as someone who works well with other people, listens to feedback, and is willing to change their work if needed. That doesn’t mean you shouldn’t defend your designs. Not every client request is right for what you’re building, so you still want that confidence in your work to be able to push back when needed.
I’m not trying to convert anyone here. I’ve just heard plenty of noise from lots of different people about the topic of Agile and Design, and thought I’d put my perspective out there. It’s a tangle, truly, but I believe it’s one worth struggling with. I think Agile has the power to bring developers and designers together in way that few other working processes can, and that’s a pretty valuable thing. At the Gather discussion, one thing everyone agreed on is that designers and developers are squishy people with feels, and they need the support of the other in order to do great work. Maybe Agile can help us do that.
Check out a great article: A List Apart: Getting Real About Agile Design