Every design decision is an assumption

Recently Petar posted this tweet which contains a screenshot where a person — maybe it’s Petar himself? — argues the pointlessness of sharing buttons.

While I agree with the author’s thoughts regarding sharing buttons, what caught my attention was this:

Every design decision is an assumption. You put something in front of the users and then observe how they use it and then optimize.

This is something that a lot of people don’t understand about design as a practice, especially clients. Often times they come to us for straightforward answers and solutions to their problems, only to face disappointment when they realize we can’t help them in that way. And who could blame them? We’re supposed to know this, right?

This is commonly the main reason the stakeholder-designer relationship goes sour. They assume we’ll be able to wave a magic wand and solve their problems, however that is simply almost never the case. Most design problems are complex and the designer has to take in a tremendous amount of new information in order to, first understand the problem, and then apply their accumulated knowledge, in order to even begin solving it.

So, if we can’t give them the straightforward solutions, how do we help them? Why would they hire us?

A designer takes an educated guess, creates an assumption that something will work, puts it to the test, and draws conclusions. This loop repeats itself: asking more questions, making more incremental changes, and hopefully they get to a better place than where they started from.

In my opinion this is a more organic, natural way of designing things. By starting small, and improve gradually by trying a lot of things, you get to see what works and what doesn’t. You keep what works, and discard what doesn’t. Compare the things that worked, make a decision what to keep and commit to it. Than you revisit if it doesn’t meet expectations, and keep trying new things until you meet the expected results.

This process gets you and the stakeholder together on the same side, working together on a solution for their problem.

Insisting on doing things right, and even worse expecting that a UI will eventually get to a complete state, where it will be considered finished, is an expectation which is best avoided for the sake of all involved.

3

1

1

Error happened.