Deprecated: Return type of CycloneSlider_Plugin::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/virtual/citizen/html/bits/wp-content/plugins/cyclone-slider-2/src/CycloneSlider/Plugin.php on line 14

Deprecated: Return type of CycloneSlider_Plugin::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/virtual/citizen/html/bits/wp-content/plugins/cyclone-slider-2/src/CycloneSlider/Plugin.php on line 22

Deprecated: Return type of CycloneSlider_Plugin::offsetSet($offset, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/virtual/citizen/html/bits/wp-content/plugins/cyclone-slider-2/src/CycloneSlider/Plugin.php on line 10

Deprecated: Return type of CycloneSlider_Plugin::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /var/www/virtual/citizen/html/bits/wp-content/plugins/cyclone-slider-2/src/CycloneSlider/Plugin.php on line 18
Zooming Out

Zooming Out


Upon commencing a new gig, different people and departments are going to seek out for our help to “improve the UX of XYZ,” which we generally see as a good sign, as it shows that the holistic and comprehensive concept of User Experience Design has made its mark in today’s thinking. And as designers, we are usually well-equipped with a helpful and supportive mindset and, therefore, we are eager to seize the opportunity.

But if we are new to a company or project, we will only have a confined understanding of the big picture. This is absolutely normal because achieving a full understanding takes time. It also means we are only able to help at a limited scale. And here is the peril…

The problem at hand is that we are assessing situations in isolation — or in a silo. We are looking at an issue without being capable of taking its whole breadth into account. We will often encounter situations where we have ideas and propose solutions seemingly fitting to a particular case.

But more often than not, these solutions will turn out to be unfeasible, not adhering to established patterns or misaligned with how the company has handled similar situations in the past. We are wearing blinders and our thinking is shielded from what is right beside us.

To overcome this tunnel vision, we need to foster the habit of “zooming out” into our personal design process.

It is tempting to look for solutions in separation because it feels easy, faster and we think that we have found the apparently perfect solution for the task at hand. But it will likely be a fallacy and crack as soon as the solution is released into the wild.

To prevent this from happening, it’s important that we take a step back and evaluate the value and suitability of our idea in the context of the whole ecosystem. Taking a birds-eye view will help us judge the true value of an idea.

When we explore a problem, we need not only to consider the issue on its own but rather understand it within the wider ecosystem. Working within the limited realm of the issue at hand and overlooking relations and dependencies between the various parts will result in a patchwork that feels disjointed and incoherent experience.

Deconstruction

To find the best solution, we need to deconstruct the isolation and analyze the issue with the whole ecosystem in mind. We need to obtain the ability to assess a situation on the micro- as well as the macro-level.

  • How are similar situations handled in the product or service?
  • Which patterns are used and would they work for the given situation?
  • Can we adopt an existing approach for our situation to make use of established and learned system behaviour?

Reusing existing components, interactions and concepts will establish consistency within our product or service and help our users navigate and control it.

Jakob Nielsen has manifested consistency and standards in his usability heuristics, an interface usability should be assessed against. He states, “Users should not have to wonder whether different words, situations, or actions mean the same thing.” This means we need to ensure consistency throughout the product or service and similar interactions should be handled in a similar manner.

It doesn’t mean we should blindly copy the same pattern over and over again, but rather that it’s the responsibility of the designer to weigh which approach is the best for the given situation within the constraints of the broader context. There are good reasons for applying new ideas or breaking conventions and patterns to solve a problem if it will be for the benefit of the user — which is the crux of User Experience as a whole! It’s important to be able to evaluate the situation within its context to make elaborated decisions about it.

“Zooming out” can also mean to take our idea and explain it to another person. While leading someone else through our thinking, we will critically assess our lines of thought and realize slips and errors in our reasoning just by explaining to another person. In software development, the term “rubber ducking” has been defined.

The allegory describes the activity of explaining everything in a very detailed form to a rubber duck, aiming for a fortunate stroke of serendipity. This is what we can do here as well, with the not-to-be-underestimated advantage our conversational partner is even capable of replying and sharing his or her thoughts with us.

And the earlier we do this, the better because the more time we spend on working out the details, the more it will hurt if we have to throw the idea into the bin. The more attention and meticulousness we put into the elaboration of it, the less likely we are to accept it’s not the solution we’re seeking.

This can become very frustrating since it also means we will discard ideas we have spent a lot of time with and we were convinced about its viability. It will also create discomfort, as perhaps the most obvious solution won’t be the right direction to go. We need to be prepared for setbacks during the exploration of our thoughts.

Global Optimum and boring solutions

But these setbacks are necessary to distinguish the global optimum from the local optimum of our product. Fancy and clever approaches will not always work for the greater good and usually result in bloat of complexity. Users would have to learn additional mechanisms and interaction sequences, which would result in an increase of complexity and the cognitive load to master the product or service — which is poor user experience.

This needs to be prevented by all means, since complexity will creep into our system quietly. Complexity is a simmering detriment hiding in every corner of our system, being fed by every decision we make. It sits behind benign ideas, lures us to become careless about its shattering consequences with promising ingenuity and creative tribute, only to reveal its vicious face if we are becoming too negligent about it.

Therefore we might need to settle for “boring solutions” and accept they are indeed the preferred way to go. GitLab, a software development platform has even established the term “boring solutions” within its company values, stating, “Use the simplest and most boring solution for a problem[…]” because “[…] every little reduction in complexity helps.”

Aiming for boring solutions doesn’t seem desirable or worthwhile.

As designers, we are under the assumption we are supposed to be hyper-creative, edgy and out-of-the-box thinkers. But creativity doesn’t necessarily mean we have to “reinvent the wheel” every time. Ideas we consider clever, disruptive or ingenious can turn out to be overly complicated and confusing, hindering users to perform their tasks and achieving their goals, rather than supporting them.

In the realm of enterprise software, where our product is just a tool among others, reducing complexity should be a guiding design principle — efficiency is key. But efficiency should also not be used as an excuse to sacrifice usability — boring should not be conflated with bad. Therefore, the right approach, in the interest of the user, might be a clever and surprising one, but it also might be a very dull and trite one.

Taking a step back, “zooming out,” and overlooking the relations and context of the interrelated parts which are creating the big picture, will help us to identify the true best solution. Zooming in and out can be seen as an iterative process of constantly “sanity checking” ideas and approaches to unlock the full potential of an idea. And even though the idea might not be as revolutionary as we would like it to be, our users will be the beneficiaries.