Philosophy of Design
The Design industry is a kingdom of philosophers. Our meta discussions are endless. We constantly try to define and re-define our own field. Decisive response to environmental change (like Agile and Lean) takes us literally years.
And I love it.
Meta discussions show that we deeply care about our jobs and give us an in-depth insight into the nature of our field. Philosophical disposition helps us better understand what we are and what we are not doing right. It’s absolutely great… unless it detains us in our ivory towers.
Futile Crusade
Joshua Porter, author of unforgettable Designing Social Interfaces, one of my favorite UX bloggers, asks in his latest blog post: „Is design building interfaces or solving problems?” and starts his crusade against closing up design in sprints.
I’m afraid that the question itself is misleading and the crusade is rather futile.
Is there really a dichotomy between building interfaces and solving problems? No, and I wouldn’t assume that Joshua really thinks there is. As I understand, Josh is not trying to conflict both definitions, but rather to emphasize the power of building interfaces anchored in a problem-solving approach to design. Fair enough. This is a statement that I can wholeheartedly agree with.
I’d say that design as a work field consists of two crucial ingredients:
- problems solving
- communication
Only mixing up these two ingredients give us proper, tasty design. If we stop at the „ingredient 1” step, the design would be just an academic field.
Let me put it straight: design must be actionable. We’re not paid to plan solving problems, but to solve problems.
Designers solve problems by building interfaces.
This simple, almost trivial statement implies actual building the thing. If the product we carefully designed won’t be built or the final result will be far from expectations, the problem of users remains unsolved. It means that design has failed and in fact, that designer has failed.
Designer should always be judged by the final result of his work – the product.
I’m sorry to say so, but nobody cares about our pretty deliverables and amazing research if they won’t lead to a stunning product.
One sprint ahead
Joshua argues that „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.” and I must protest.
In some methodologies (yes, Agile) it might be a good idea to do initial UX activities in, so-called, sprint zero, but does it implies a separation of the design process? For the sake of the final product, I’d rather suggest including the rest of the team in the „design sprint zero”.
The team will be much better motivated if it’ll actually understand what the designer had in mind and how the design works.
We’re not paid to enlighten people around us out of our ivory towers. We’re paid to cooperate with team and create amazing products that solve real problems.
Estimations
And finally Joshua suggest that design if perceived as a problem solving activity doesn’t fit the „fixed-time sprints”.
Josh, the design is not a magical, unpredictable craft. Design is a blend of science and art. The art part gives us less certainty in time estimations than engineers have, but still, I’d argue that it’s absolutely possible to assess the time of design tasks.
In my „UX manager” times I was always encouraging my team to break every project into sets of small activities and write down a probable amount of time that they need to finish a certain task.
Guess what. After a couple of sprints, their estimates were much more accurate than at the beginning. It resulted with much more reasonable deadlines that were based on facts (passed sprints), not on mere manager’s wishful thinking.
And this whole play with estimations gave us additional superpower – insight into our own practice. It lets us eliminate steps in the process that are not contributing to the final result and focus on key activities. From my experience, the first design hardly wins. So the quicker we can get to test of conception and start iterating – the better.
The actual measurement of users behavior and iterative improvement of the design are the safest path to success.
Joshua – to engage in meta-design discussion with one of my UX heroes, is a real pleasure. Thank you for thinking-stimulating blog post.
