UXPin

Click for search

UXPin

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

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.

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.

Estimations

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.

Buffer Share
marcintreder

by Marcin Treder

UXPin CEO

Marcin Treder, UXPin CEO, is a design enthusiast that literally lives for creating the best user experience possible. After years working as a UX Designer and UX Manager he focused on his own start-up UXPin that provides tools for UX Designers all over the world. UXPin tools are used by designers in companies like Google, Apple, Microsoft, IBM, Salesforce. UXPin was recently voted the best start-up in Central and Eastern Europe. Marcin enjoys writing (e.g. for Smashing Magazine, .Net Magazine, UXMag, DesignModo, SpeckyBoy...), blogging (Marcin.is) and tweeting (@uxpin, @marcintreder).

GET EXPOSURE, SHARE KNOWLEDGE, BECOME A GUEST BLOGGER!

Leave a comment