How Tech Support Taught Me to Be a Better UI/UX Designer

I was pushed into running a digital business and learning front-end coding when my business partner and coding better half moved onto working at a startup and left me to run our WordPress theme shop on my own. It felt like I was dropped into the deep end and treading water fast. I was having a really hard time doing little things like customizing a WordPress theme, pushing out a bug fix or communicating to the developers what needed to be done for the next update. So, I decided that it was time to level up my skills and learn how to code. I started looking for the best online tutorials, coding courses and bootcamps and using the web developer tools in my browser  to inspect every site I visited. I spent countless hours on YouTube, watching one video after another about HTML, CSS, responsive design and PHP and down the rabbit hole I went.

After a particularly long night down the Youtube spiral (that ended with me watching a cat write HTML) I felt like I had learned so much, I had taken tons of notes and my mind was ablaze with possibilities and high on all the incredible progress I felt I had made.

Our WordPress theme support desk was normally pretty active. Things got particularly backed up after one of our moderators left and I had to jump in and take over his queue. The support desk was a dark, scary and thrilling place. It was like a whole other world I didn't realize existed.

After designing a product, you really feel like you know it inside out. 4 support tickets in and I realized that I did not. And so began my journey, my real journey into product design.

There were customization requests, complaints, bugs, feature requests, how to requests and everything and anything else you could imagine.

Each time I saw a support ticket that looked relatively straight-forward I was excited because I remembered seeing something about the topic on one of the Youtu...or was it Lynda tutorials I had watched..? (I spent the next 10 minutes digging through my browser history trying to find it, which inevitably I did not). Back to the problem at hand. I took one small chunk of the problem and started to try and solve it, I went on StackOverflow and looked for answers there, finding little hints I solved a bit of it and then tried to understand, define and solve the next bit of the problem.

"At some point, everything's gonna go south on you... everything's going to go south and you're going to say, this is it. This is how I end. Now you can either accept that, or you can get to work. That's all it is. You just begin. You do the math. You solve one problem... and you solve the next one... and then the next. And If you solve enough problems, you get to come home." Mark Watney, The Martian

And that's when it dawned on me... I had finally started to 'think' like a coder and I had finally started to see the flaws in my thinking only from a designer's perspective and not understanding the restraints of the code and the needs of the customer.

Design thinking, Systems thinking, Product thinking

Design thinking is additive and creative by nature. It's about building things up from aggregate information and adding visuals to solve a problem.

Systems thinking is reductive and analytical. It is the process of breaking things down into their component parts in order to solve a problem.

Product thinking - involves wearing many different hats and thinking deeply about the user (from their perspective) and the business (from it's perspective) and how the design and the system can meet to solve a problem in a usable and lucrative way.

Design work alone can be contradictory by nature. It's subjective and often times abstract. We attempt to learn concrete design principles about color theory and typography only to, most of the time, throw it all out the window in favor of what 'feels right' or what the client thinks 'looks good'. We often try to solve user experience problems by 'feeling our way through' them.

"For me, graphic design serves the purpose of solving a problem with attractive visual forms supported by invisible systems or structures." - Vince MingPu Shao

When you start to actually become aware of and try to understand the underlying systems and the skeleton beneath your designs, it opens up new perspectives and possibilities that you may not have seen before.

It opens up more ways to solve for the user's issues and ways to align those solutions with the business's goals.

I slowly started to understand the relationship between how I was thinking as a designer vs a developer vs a product producer. It was a mindset and it felt like I was seeing other dimensions of something that was once flat to me.

The biggest issue with learning code or design in isolation and watching others create projects is that a lot of it won't apply to you as a whole. You'll most likely take bits and pieces from what you learn and then diverge down another path to find your specific answers and solutions for your particular users. But if you know how to think like a coder and a designer and you understand your users and your business goals, you're half way there.

Learn by doing vs Learn by seeing

As a self-taught designer, learning design for me was about seeing. It was about looking at the pretty things of other designers and borrowing and emulating what I saw. I was learning different ways to layer styles onto a pattern or problem.

Coding was about doing. Staring at the text editor of another coder didn't have the same effect as staring at a Dribbble mock from another designer. I needed an actual problem to solve before I knew what I needed to know.

Product designing was about solving real problems for real people (UX design) and applying what I learned to creating a profitable business (business thinking).

While tutorials were invaluable in teaching me application skills, programming syntax and getting that over-the-shoulder look at how the pros do it, what it didn't teach me was how to think like a programmer vs how I had wired my brain as a designer.

I thought I was designing great products, but really seeing what our customers were having trouble with and how they were attempting to fix things and get around bugs themselves completely changed the way I saw the products I was designing and greatly impacted the choices I made moving forward...and for the better!

This was also a deep dive into user research,  something that I often passed off as mere market research.

Component/Atomic design is an area where I see an incredible opportunity to bridge the divide between design thinking and systems thinking. Design systems (all the rage right now) are helping us as designers and coders define a common visual language and framework to speak to and understand each other.

This is the most important part about what we do. No dev or designer is an island. Whether or not we all become unicorns and full-stack engineers is not the point or the goal. It's about better communication and better problem solving and figuring out what it is you need to figure out in the first place to build a better product.