Musings of a design team of one: #2

Princess Oviawe
3 min readDec 6, 2022

Some broodings and reflections of a solo product designer.

For better context read the first part here, but if not, you’re welcome to the party.

A siluoette of a man standing on a rocky landscape
Photo by Austin Mabe on Unsplash

This is a sign of progress, and I have mentally given myself a pat on the back for starting a second issue on this topic.

Also, I’m thinking of continuing this as a series, Anyways, we’ll see.

Some miles from the beginning:

One characteristic about me is that I like structure and processes. Whatever activity it may be as far as I am aware of the process involved, I’ll follow it to the letter, But as work life would have it, I learned that one has to be open to new experiences, processes and structure. We can’t all work in one way all the time. Cost, certain circumstances and creativity have to be taken into account sometimes.

This realisation stood out when I joined my first startup, after rigorous self-learning about UX design processes and a few projects in my portfolio, I found out that not all design tasks start the text-book way, sometimes there’s little to no user research done due to time or budget constraints and sometimes, the management isn’t aware (or doesn’t care) that research is essential.

As a refresher, here’s a popular structure for design projects

Double diamond design process poster
Double diamond design process image on Wikipedia

One way I’ve tackled this over the years is to embrace flexibility and try always to find a walk-around.

Example:

When research is overlooked or tight on budget, resort to guerrilla research: have quick interviews with 5 -10 persons, get insights fast, write a report, present and then utilise outcomes in design.

In the long run, this is not a solid plan for most ideas, as nothing, I repeat, nothing beats in-depth research. I usually resort to this either as a last option or as a way to convince stakeholders of the importance of thorough research.

Something to note about the beginnings is that it was riddled with poorly managed feedback. It used to be quite difficult to separate negative feedback from constructive feedback. What’s even the difference you may ask?

Well, negative feedback focuses on everything you’ve done wrong -although most times when this is received it’s often true. This hurts because your flaws are exposed, and some people don’t say it nicely.

Constructive feedback is kind of mixed, your mistakes are clearly pointed out, but you are also given opportunities or ideas on how to be better, sometimes you are first appreciated for what you did well before your flaws and corrections are out.

In order to learn and improve better at this, I tried the following.

  • Writing down any feedback I receive. If it’s constructive I’ll also note down suggested ways to improve.
  • Set a reasonable timeline to improve and …
  • If possible reach out again for more feedback
  • Document any new improvements.
  • Try as much as possible not to dwell on mistakes.
  • Try not to take harsh feedback too personally (preserve my mental health by selecting the main points to improve on.

I’d like to say this has worked so far, and I’m still looking for more ways to improve, but if you’d like to put me to a test, the comment section is free for you.

Just kidding, please be nice, I’m only human.

Well, I’ll pen down here, to be continued…

--

--