Post Image

Designers solve problems by building interfaces. Polemics with Joshua Porter.

Marcin Treder
By Marcin Treder on 23rd July, 2012 Updated on 1st February, 2017

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 power of building interfaces anchored in problem solving approach to design. Fair enough. This is statement that I can wholeheartedly agree with.

    I’d say that design as a workfield 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, 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, 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 good idea to do initial UX activities in, so called, sprint zero, but does it implies 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”.

Team will be much better motivated if it’ll actually understand what 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.


And finally Joshua suggest that design if perceived as a problem solving activity doesn’t fit the „fixed-time sprints”.

Josh, 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 time of design tasks.

In my „UX manager” times I was always encouraging my team to break every project into set of small activities and write down probable amount of time that they need to finish certain task.

Guess what. After 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 super power – 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 first design hardly wins. So the quicker we can get to test of conception and start iterating – the better.

Actual measurement of users behavior and iterative improvement of the design are the safest path to success.

Joshua – to engage into meta design discussion with one of my UX heroes, is a real pleasure. Thank you for thinking-stimulating blog post.

Marcin Treder

by Marcin Treder

Marcin Treder is the CEO and co-founder of UXPin, a product design platform. Since co-founding UXPin in 2010, he has helped build and lead product teams in the Poland and Silicon Valley offices. Previously, he worked on projects for two companies that IPOed and managed the design team for one of the biggest eCommerce companies in Eastern Europe. He holds an M.A. in Cognitive Psychology. Marcin has been given numerous awards, including MIT 30 under 35 for his accomplishments in design and business.

Still hungry for the design?

UXPin is a product design platform used by the best designers on the planet. Let your team easily design, collaborate, and present from low-fidelity wireframes to fully-interactive prototypes.

Start your free trial

These e-Books might interest you