Blessings and Curses

As we designers grow in experience, I expect we should start to see how our backgrounds have helped or hindered our designs in what would best serve the people. We are more aware of our biases, which is another way to internalize the adage “We are not the users”.

The field of user experience design is rich because its practitioners come from diverse backgrounds. I’ve met people with backgrounds in English, graphic design, software development, psychology, and human factors, to cite a few examples.

While I will explore my background and its associated blessings and curses in this article, I encourage us all to reflect on the effect our background has on our work.

Empathy for developers

Doing object-oriented programming feels like constructing a new type of building with 10–15 strangers. You’ve never seen the building before, but you roughly know what it needs to do. Additionally, you have to define each person’s job description, including how they should work together. Additionally, you have to be ever mindful of gaps in overall capability, not overburden any particular worker, and finish on time. Therefore, asking developers to think about screen layout, colors, and which font sizes to use is like requiring the housebuilder to have 5 of the team members match outfits in addition to everything else they have to do. It only complicates the developer’s job and rarely feels like the highest priority.

I understand the immense cognitive load that developers experience daily. Therefore, I will make sure that I spell out salient details to my designs when writing design specifications. I hope that the design guidance I provide will empower the developer with the necessary information, and they know more precisely what to implement and why we’ve chosen that route.

Enhanced collaboration with developers

Another benefit is in communicating better with developers. I feel like I can better predict whether something would be feasible. When something cannot be implemented precisely as designed, I enjoy collaborating with the developer to find a new solution that best satisfies feasibility constraints while maximizing user experience. Or, if nothing more can feasibly be done to improve the user experience, I can better understand the rationale.

Expanded awareness of the technology stack

Another benefit is knowing a little bit about what’s happening “underneath the hood”. So, for example, knowing about network transfer protocol, Big-O, and databases would be very difficult to understand if you didn’t already have a background or took the time to learn.

Clearer bug reporting

As someone who has had to resolve bugs myself, I’d like to think that I can write bugs that developers can replicate more easily. Furthermore, I can provide direction and illustrate what I mean clearly so that bug reports can be more actionable. Additionally, communicating software issues has paired very well with the designer’s need to communicate the design of interfaces visually and clearly.

Create tooling to empower designers

Designers who know how to code can also augment their design capabilities, whether that be by creating a plugin in Figma or Sketch, throwing together some HTML/CSS/Javascript to illustrate an idea, or writing a bash script to automate a repetitive task.

Another benefit from being a developer is occasionally leveraging developer tools for design work. For example, knowing the command line helps with converting file and data formats. Also, in a pinch, if I need to add assets to a repository or edit documentation myself, I can fork the repository and submit a merge request.

Add value across more stages of the product lifecycle

In organizations that require generalists, people with my background can thrive. Not only can they support a project through multiple phases of the project lifecycle, but they can also support a team of designers as a design-ops person.

Modular thinking

Thanks to object-oriented thinking and the don’t repeat yourself (DRY) principle, atomic design and design systems come very naturally! The same goes for thinking in styles and symbols (Sketch, Illustrator) or components (Figma).

Design overcomplication

One major drawback is that I find I sometimes can make the experience unnecessarily complex. I’ve been in situations where, as soon as I say my idea out loud, I see the blank looks in people’s faces and realize I need to dial it back in complexity. In another situation, I put a prototype in front of somebody. They looked at it for a long time as if they could not even put into words what they felt was wrong.

Over-sensitivity to edge cases

As a developer, you get hypervigilant about edge cases because being resilient to edge cases is required for writing good code. As a result, programmers seek after edge cases. Unfortunately, it can be too easy for a designer to gravitate toward these edge cases, losing sight of the primary and most common use cases. Furthermore, while edge cases are essential for bug-free software and usability, they are often not as important to communicate to a stakeholder trying to understand the big idea, who merely want to hear of the value proposition of your feature.

Comfort zone of coding

On an intellectual level, I understand (and even preach) that sketching and drawing will be faster to iterate upon and allows people to evaluate ideas sooner. However, whenever I encountered a problem as a developer, the first tendency was to see if coding could solve the problem. While the muscle memory to code has waned somewhat over the years, even now, I find myself needlessly upgrading Yarn packages as an excuse to procrastinate diving into the unruly mess of a difficult design. Or, I choose foolishly to build and host my portfolio rather than using an online website building service.

When I played piano, perhaps I faced the same thing as well. It was so much more fun to play songs that I already knew than to trudge through the difficulty of learning new songs.

Lack of focus

Especially with projects like this portfolio (where I am both designing and coding), I’ve felt a substantial amount of self-directed frustration because I was spread too thin. Either the design suffered in favor of the development, or vice versa.

Other quirks

Other quirks abound. To cite an example you might appreciate, consider how my quotations are always inside of punctuation even though I’m American. I know that goes against the rules, but that makes more sense to me. This habit comes directly from the practice of writing syntax-conforming code.

So, those are the interferences that I have experienced, resulting from transitioning from developer to designer. I’m sure that any of you would be able to write how your background has blessed (or cursed) you as well.

What’s your background? What are the blessings and curses your experience has had on your designs?