Lincoln Anderson / Design Noodles & Doodles / April 24th, 2014

The Creative Process in an Agile Development Environment – 352 Noodles & Doodles

When our CEO Geoff announced that 352 was making a shift to agile development we were all excited, even though we were entering uncharted waters. Agile had many clear benefits regarding team organization and workflow, but my fellow designers and I had a lot of questions, including: Is agile appropriate for us? Will it make us better designers? Are we going face many challenges?

The answers have been a resounding yes, but even the challenges have been worthwhile. In this 352 Noodles & Doodles, we talk about how an agile development actually enhances our creative process by taking designers out of isolation and letting our designs evolve along with the rest of the project. Enjoy!

Transcript below.

Image credit: Grand Canyon Celebration of Art

[Lincoln Anderson:] Hi, I’m Lincoln Anderson. I’m a designer at 352. 352 is a website development firm, and a couple years ago we decided to make this dramatic shift in our culture towards being more agile. Agile is a kind of a buzzword in our industry. It represents a lot of values and methodologies around how we organize, how we work together and how we build projects. It has a pretty good history in more technical firms – software engineering firms – but as designers, we wondered how is this going to affect us? Is it going to make us better designers, is it appropriate for us? Are we going to encounter certain types of challenges?
And we found: yes, all of the above. It’s been really good for us over the last couple of years, and we’ve picked up a lot of lessons that have helped us become better designers. So I want to share some of those lessons with you today, and hopefully next time you design a project, these will help you.
 
So the first lesson we learned was that we prefer cross-functional teams over silos. Silos are this concept, that’s pretty common in our industry, where you take all the people with a particular skillset, like all the creative people, and you put all of them on one side of the building and you put the programmers on the other side of the building. And it’s kind of weird if you think about it.
 
What we’ve discovered is that if you take all those people and you mix them up – you know all the people you know you’ll need for a project. You’re gonna need a couple designers, a couple programmers, maybe a marketing specialist or a QA guy – quality assurance – and you put them on a team and say, “You guys work on this project from beginning to end, whatever you need to do.” It’s a lot better; it’s a lot more fun. You learn from each other and there’s a lot more stuff that doesn’t slip through the cracks.
 
As a designer it’s a lot more satisfying because you can be designing something, and you can spin your chair around to a programmer and say, “This thing I’m designing – I know it looks cool, but will it work? Is there any technical problem that you see down the line?” And they can help you be a better designer, and they learn about the creative process. It’s just a lot more satisfying and a lot more fun to be on a cross-functional team as opposed to being isolated.
 
The next lesson that we’ve learned is that we prefer collaboration over these “Big Reveals.” So, there are always times when a designer needs to isolate themselves and polish a design and flesh out the details of it before sharing it with the rest of the team. You need to get your idea down on paper or on the screen so people really understand what you’re thinking.
 
But the danger with that can be when you are isolating yourself for too long; you’re working on something for hours or days or weeks and you’re not sharing it with anyone else. You don’t have anyone telling you whether you’re on the right track or not, and you end up in this this situation right here where you’re pulling back the curtain and saying, “Check out my masterpiece!” And you missed the mark. Maybe you like it, but no one else really likes it, or some details that the client gave you on the first day have changed since you started working on the project.
 
So it’s really key that you’re always collaborating. We have standup meetings with our clients every day, and it gives us a chance to give a little update of what we’re working on, ask some questions and make sure that we’re on the right path. That’s really key.
 
The next lesson that we learned was that we prefer flexibility and future growth over locking down a design. So, if you’re a designer, you’ve experienced designing something and you love it, you get a point where the client loves it. Everyone on the team loves it; this design looks great. And then a couple weeks later, someone comes back and says, “Hey, we need to make a change.” And it’s really frustrating to you, as you can imagine. You thought you were done with this thing and now it’s back to the drawing board, they need to make changes.
 
So there’s a temptation to lock down the design and say “My design process, after everyone is happy with it, we’re gonna lock it down! I’m gonna lay down the law; you can’t make any changes after this date,” and make a big deal out of it. But the reality is that in life, things change. And you need to be prepared for that.
 
If you are working with a client who is inquisitive, and they’re researching their users and finding out more about how their industry works, they’re going to have changes. They’re going to say, “Hey, I was wrong about something I told you last week, I’ve learned more and the design, the product will really be better if we did it differently.” So you need to be prepared to adapt to that change.
 
Also think about when you launch that design, and a website is alive and people using it. If you’ve done a good job, there’s gonna be more and more people using that site, and more and more features are gonna need to be added. More content. So that thing is gonna need to grow. So we try to set ourselves up so that change is not so painful. There’s a couple ways to do that.
 
One, is when you’re wireframing a site and deciding where the menus are gonna go, what type of menu it’s going to be – think about down the line, how that might change. Sure there are only three menu items right now, since you’re in the first week of development but what about down the line when there might need to be like 15 items. Does you menu expand, does it account for those types of changes? 
 
Programmers are really good at identifying these types of opportunities because that’s kind of how they think already. They’re always looking at their logic and thinking, “what if the user does something crazy I need to account for, something that I didn’t necessarily predict in the moment?” So, they’ll really help you out in finding where you need to account for that flexibility.
 
The other thing you can really take advantage of are modern tools. The hot one right now is CSS pre-processors like less and sass and stylus. You can look up those terms if you don’t know what they are, but those are really going to help you once you get into development to make changes on the fly to colors and rounded corners and things like that which would normally be a really big pain to have go back in and change across your site. You can make a sweeping change in just a few seconds, so just check those out.
 
The last lesson that I want to talk about is really specific to Scrum. Scrum is a framework that will help you get your organization or your team off the ground in an Agile way without having to think of a lot of rules right off the bat. You can kind of follow these rules that Scrum sets for you and then you can kind of tweak it as you go and adjust it to how your team needs to work.

 

One of the things that’s really core to Scrum is this concept of a backlog. If you never heard this term before, you can think of it like a big list of all the things that need to be built on your website, but instead of it being a task list or like a features specifications list, it’s more a set of user stories. User stories is what they’re called and these are what they sound like, they’re little stories about how users will interact with the product. So, instead of having a list that says, “build a product catalog,” you might have stories like, “the user wants to find a product by name,” or, “they want to search for a product by color.” And then you talk a little about the motivation. “They want to search by color because they’re shopping for a friend and they don’t know exactly what the friend wants, but they know they like the color red,” or something like that. So, you get started thinking not just about this thing that you’re building, but why you’re building it. And this really resonates with designers because we like designing for people. We like designing user experiences, UX. The backlog helps everyone on the team and the client get on that same page of thinking about how the user is going to use the product instead of just making this jumbled pile of things you need to build and then just cranking through it.
 
So, these are some of the lessons we’ve learned about how to do Agile design and I hope you learned a thing or two. Thanks for watching.