Never ask a designer to build a bridge

While seeing a demo of soon-to-be-released software, I noticed something odd. Screens with little data looked broken because pagination was left out. We, the product team, defined that in order to make demo users feel at home, the pagination bar should be visible, even though there was only one page to display. If the designer just added this component things will feel more intuitive and clients will convert a lot easier.

Our designer said no. And he was right.

Adding this element would maybe solve this issue but would raise problems in other parts of the application. His fight for consistency reminded me of Prof. Miermans quote. We should have asked him to evaluate the design system for users with little data. We probably would have reached our goal faster, easier and with a more durable solution.

Never ask a design to build a bridge, ask for a way to cross the river.

From solution focus to problem focus

We, as humans, are trained to think in solutions. We are appreciated for helping others and applauded when our projects move forward. So it is natural to ask people to implement our solution and then to explain our problem.

This is desired behaviour in many situations:

• In social relationships, it is appreciated to help the group with a solution
• In crisis, it ensures forward movement and keeps perspective
• When you fix a technical problem your website is back online or your shower is again connected to your water supply. You get awarded right away.

Designers are often presented with complex problems where the answer is always a balance between multiple stakeholders with multiple goals, within the context of politics, technology, budget and deadlines. Asking to change one aspect of the solution may require restructuring the whole shebang.

So please present the problem as a goal: “I would like to achieve this for this user in this situation”.

A good designer will answer this, as a sign of appreciation, with some hard questions:

• How do we know this is an actual need?
• How often does this occur?
• How will this affect this user?

Raising a problem in those complex situations will get you to better solutions for the problems of your users. Because there are probably way more variables to the problem than you see at first glance.

Design is a marathon

Couldn’t you just add it; that’s way faster.

You’re right. Questioning everything takes time. Preparing a change request is a lot harder, but it’ll pay off and save you time in the long run.

Designing a (software) product takes effort to:

• Fully understand the problem you’re solving
• Take decisions on what to tackle first
• Knowing what makes your solution so unique
• Constantly validate your hypothesis
• Inspire a team to solve the user problem
• Explain to all stakeholders why your solution will work
• Evaluate and learn from your mistakes

Design is not something that can be done in a sprint or a workshop. It takes time to create something big.

Design is a continuous and iterative process of learning, balancing and improving. Just as Daft Punk phrased it: Our work is never over.

If you see something that bothers you in the interface, don’t hesitate to ask for its purpose. This way your designer can find a durable solution for your probably important observation.