Myopia in Design

The topic for this article came about as I read a few articles on Medium about conceptual work, and also as I witnessed firsthand situations where Designers, while embracing a semblance of a process, mostly designed Product solutions very insularly, producing outcomes that reflect mostly their interpretation of what a product should do, and not contemplating what Users and Consumers actually expect and want to do. This concept of myopic views and strategies when it comes to the Design profession and Designers in particular, is always a fertile ground for plenty of discussion, and hopefully this article will provide points of reflection, but also some guidelines that I’ve encapsulated after years of working on the field.

Myopic Views & Comfort Zones. Myopia according to Wikipedia can be defined as is an “eye disorder where light focuses in front of, instead of on, the retina. This causes distant objects to be blurry while close objects appear normal”, which is the clinical definition of the term, but can also function as an analogy which can be applicable to Design in general and Product Design solutions in particular. I’ve witnessed throughout the years, and through multiple sessions with different product teams, that Design Thinking and what it advocates for, has really brought forth not only a user centered process of uncovering solutions, but also fortified the sense of team integration.

For a lot of stakeholders and team members I’ve had an opportunity to interact with, this mechanism has been a novelty, since the typical processes of solutioning for some of these individuals, were based on regimented phases, very much in line with Waterfall type of processes. This typically meant that specific teams and team members would focus on their tasks alone, and therefore have a myopic view of their contribution, never truly uncovering the larger picture of what was supposedly being built or for that matter, whom for. Designers were, and in some cases still are, very much part of this cadence.

For the longest time, Designers would consume tickets and requirements assigned to them through tools such as Atlassian’s Jira or Trello, and go about digesting the documentation provided, in the hopes of creating artifacts that substantiated the needs of their counterparts on the Product Management/Ownership side. This myopic view typically meant that the solutions uncovered, were an interpretation of the documentation produced, which in turn, were written as an interpretation of what Business Analysts and Product Owners comprehended of Users needs, feedback and general observations. This process has always been a convoluted one, and as much as a Designer or a team of Designers, have empathy for their users, there is an evident gap in research and testing, which manifests itself in product solutions that are more an interpretation of what Designers uncover, through different mechanisms, which include among others, competitive analysis.

This segmented view of the solutioning process, privileging some methods over an actual thorough process of creating Product solutions, ones that match the qualities of good Product Design (they should include usefulness, usable, findable, desirable, credible and accessible qualities), eventually produce outcomes that are marred by stunted flows, or solutions that while addressing some aspects (or in some cases, almost cannibalizing solutions from competitors) of the problem, fail to give users what they actually need or want. The advent and popularity of Design Thinking has obviously positioned these roads towards efficient Product Solutions in a dramatically different path, but to this day, I still observe teams that go through this hybrid process of procuring solutions with an eagerness & urgency, which prevents them from truly understanding what they’re solving against, therefore bypassing early testing with users & consumers, and gathering not just feedback, but also understanding the expectations those same users have towards the products that are being created. All of this to essentially state that no matter what, Designers for all their empathy and vast array of experiences, should not get too enamored with their own notion of process or their own devised solution — that myopic view invariably means that Designers are avoiding tackling questions, ambiguities and expectations. They should always, and at every point of the process, question themselves where they’re going, alongside their team, and have a notion that the solutions are not a manifestation of what they solely think is right, but instead, a convergence of a series of inputs, with Clients and Users being the most fundamental ones.

I’ve heard in the past, as I’m sure many Designers have as well, that “Design by Committee” is something to avoid, as is the expression “too many cooks in the kitchen”. In line with these analogies, Designers and their roles, have to be capable of shuffling through all the participants in these contexts, from internal stakeholders, Product, Development, Marketing, Customer Support peers, among many others, and tie all this with what users are not only expecting from a functional standpoint, but also from an expectation/emotional standpoint. There are emotional aspects tied to how users relate to solutions they use (as Don Norman states there are three levels of Design, the visceral, behavioral and reflective), that can’t be avoided, and as the Nielsen Norman Group as documented, there are needs from a functional, reliability, usability and pleasurable aspect that should never be discarded, because they make all the difference when it comes to product adoption and ultimately, retention.

An additional thought on myopia in Product Design is tied with concept work which Designers produce frequently to showcase their capabilities and points of view. As I mentioned early, there are plenty of opinions vehemently opposed to these types of projects, and it’s easy to understand why. While a lot of these proofs of concept are impeccably conceived and devised, they occur through this myopic lens of data that has no relationship with reality, and invariably are just hollow representations which fail to be effective as Design solutions (aesthetic without function, or aesthetic without reason or purpose). However, looking from an innovation standpoint, these are explorations that are needed and should be nurtured, however, now more than ever, for those Designers (including myself), when tackling projects such as these, it’s fundamental that the premises in which these are created, are clearly defined, including the problem statement, the users, the data utilized, the timeline of execution, something that grounds these explorations in a scenario that even if it’s not entirely real, it’s still comprehensible by those who consume it.

Once Again with Feeling: Empathy. Yes, I’ve written an article on the topic of Empathy in Design, and as I mentioned in my previous article, that was also a manifestation of my profound admiration for Professor Don Norman and his take on the topic. When it comes to Myopia in Design, and in particular with Designers, we should always realize that no matter how much empathy and capacity to be emotionally mature we are, we must recognize the expectations from the plethora of users that are going to be in the sphere of utilization of a product. That fact and statement in no way, shape of form, replaces the process of actually Researching, Testing and Validating their input. For all the great attributes a Designer and a team of Designers has, alongside their peers on the Product Solution Journey, all of those vast capabilities and knowledge, can’t truly replace the understanding and response that users provide to what is placed in front of them (in whatever shape that is, prototypes, sketches, surveys).

Even with FAST UX processes, where proxies are utilized as a replacement for actual users, as close as they may get to interpretations and knowledge of habits of actual users, chances are, there will always be elements in a flow that are missed or misinterpreted. Without that cornerstone of User Input, Product solutions may invariably fail to capture those nuances. Ultimately, Designers should always be the ones advocating for the need to test, validate and provide transparency on what is being created. Insular solutions only work for those islands themselves, and when trying to mind the gap and build solutions for the larger contingent of users & consumers, Designers always need to reflect and understand that the solution must have a larger footprint. Shedding ego, understanding & evangelizing the process, and just as importantly, capturing and analyzing feedback for what it is, and not as threats for advocated solutions, are traits/qualities that Designers need to cultivate now more than ever. The world is changing rapidly, with hopefully more conscience, more inclusivity, more diversity, and Designers have an opportunity to carve a profound impact not just on the tools that users will use in the present and hopefully for the foreseeable future, but just as equally important, how these tools are effectively created.

I’ll conclude this article with a quote on the topic of perspective, from J.M. Barrie:

“Nothing is really work unless you would rather be doing something else.”