Is design building interfaces or solving problems?

I’ve been talking with a lot of designers lately and it’s clear to me that many of them(us) are struggling with development processes that aren’t always design-friendly. The other night, for example, I made the off-hand comment that it’s hard to organize design efforts in sprints because not all design problems are two weeks long.

The response I got surprised me…it was “thank God I’m not the only one who feels that way”. It was relief…I think a lot of designers working at startups and other places where sprint-based work is being done are feeling this pressure…they are forced to work within schedules that aren’t always conducive to the way they want to work.

It depends, of course, on your view of design.

If you view design as “we need an interface for this” then you can more easily schedule a fixed amount of time for building the interface. How long does it take to mock something up, get it into HTML/CSS/JS, and fully integrated with the backend? Those steps are roughly predictable if you know how many screens you’re creating and the process of mocking up is not much more than going with your first decent guess. From an development perspective this is the ideal case…a predictable design process that takes roughly the same amount of time every time.

But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem…it depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule…and it’s why design doesn’t fit into fixed-time sprints very well.

The second view is the view of most designers I know. What motivates them is that they love solving problems…they are unsatisfied with the status quo and want to improve things. They get their kicks out of solving problems with interfaces as solutions, and the thing they hate the most is an interface that doesn’t truly solve a problem (but purports to). And because solving the problem is the goal some designers keep working through deadlines…in the same way that a Sunday morning crossword puzzle can stretch into Sunday afternoon simply because it’s not solved yet.

So if you view design as merely building interfaces then you can schedule that work relatively easily. But if you view design as problem solving then it’s probably better to have a separate design process out in front of your development sprints that allows designers to adapt to the problem at hand.

Update: Josh Seiden was kind enough to respond with this post: Team Problem Solving, suggesting that we not get caught up with simple time periods and work to be more collaborative.