Follow up on the “Agile Design” post

We re-posted a few thoughts I had on the Agile Design to our mothership blog on and it attracted some interesting comments on reddit. Got me thinking a little more about the intent of what I was writing and any confusion it may have caused. Probably would have been a better idea to approach the subject in a series of smaller more focused posts, but fuck it, I don’t have that kind of foresight.

These were a few comments that really got me thinking:

RE: What is this Agile Design you speak of?

“Agile Design” is a design process tailored to work closely with developers practicing the  Agile Methodology to build software.

That’s really the cleanest way I can package it up. Leading the design team inside of an agile software development company for the past 3 years, our process is ever adapting to work more closely with the clients and the developers.

  • Communicate – daily stand-ups rituals through agile scrum encourage communication between designers, developers and engage the client
  • Collaborate – teams of designers with different strengths learning from each other
  • Iterate – use sprints to scope work into manageable chunks & know that you will have time to iterate & refine a feature over several sprints
  • Pivot – sprints allow you to pivot to a new goal as the business goals
  • Finish – complete segments of work by aligning to sprint cycle & project goals

RE: value Specialists vs. Generalists on an design team?

There was a comment on reddit about specialist vs. generalists. This may not have been the intent of the original post, but it got my gears turning, so thank you.

We only hire “Generalists“.

Having experienced many different design roles in my professional career, I’ve had periods of time where I’ve focused intensely on a “specialized” segment of work. User experience on the web was a focus for about 3 years. Proper, semantic front-end markup use to keep me up at night for a couple years. Before that it was advertising & graphic design… I’m the generalist because learning new specialties every few years keeps me going.  I’ve worked at places where only one of my skills is valued as a specialist, I’d never want to do that again.

And that’s what I look for when we hire. Someone who maybe very good at an aspects of design, but has the aptitude to learn and adapt. We are in “startup” mode, as another commenter else pointed out. Below is an ugly but effective diagram of the “what” disciplines our design team practices:


We do have several people with “specialize” degrees in Human Factors. They focus primarily on requirements, wireframes, and user testing. But these same people stretch themselves to understand and participate in all the other aspects of design our team does.

Sorry – probably too much on that one…. it’s a topic worthy of a separate post, so I appreciate the original comment.

Closing thought

I’ll admit I might be abusing the term “Agile” for my own purposes. But “Agile Design” is the best way I can understand the process we’ve adopted at SPARC. And in agile fashion, there’s probably a few more iterations to better flush out this concept.

Thank you again for the interest!