Some of these may resonate with you:
My company does not value design.
No matter how hard I try, my team doesn’t get it.
I feel discouraged and alone.
I have no voice.
I want real design work, not tweaking a color or moving a button around.
More often than not, we find ourselves joining a company where design processes have not been well-established. We want to build up some solid experience and pursue the challenges of design and are passionate about building an amazing product. However, we might start to feel undervalued or unable to focus on crafting because of the many unexpected obstacles in the way.
That was how my journey began - I was clueless and naive, struggling to change my situation. I devoted myself to my design craft: designing new features, improving user experience, practising research and user testing. However, the progress was slow and I was impatient.
Looking back, I see the mistakes I made and how I have learned and grew from them. I want to share the stories about my journey, what I found to be working or not. They may or may not apply to you but I hope that this can encourage you, let you know that you are not alone in facing these problems, and perhaps provide some insights or motivation to solve them.
Being in a creative field, intuition can be a powerful tool to generate ideas or to support my design process. However, we have to constantly reflect and recognize if our intuition translates into facts or assumptions and being human, we are always prone to bias and our emotions.
I once believed that “my company does not value design” was a fact. I was frustrated and became nervous to talk to people, and started to feel alone. With this mindset, I was further isolating myself and was afraid to ask for help. It took me a while to realize that the situation did not benefit the work or anyone - it was unhealthy to the entire team.
To distill the assumption behind this mindset was not that difficult. I had mistakenly assumed that the people in my team have a decent understanding of product design. Furthermore, I assumed the rationales behind my suggestions and proposals were obvious to everyone. However, that was far from the reality.
I learned that the best way to turn the mindset around was to give up the idea of “me vs them”. A sole designer did not need to work solely. Battling with the rest of the team was definitely not going to support me in achieving anything good both for me and for the team. I started to listen more instead of continuously promoting my opinions to people. I conducted one-on-ones, shadowed meetings and observed their workflows. And most importantly, I changed my mindset to accept the team’s efforts on things that I have different opinions on. I started to have real empathy for my team, and became curious about the feelings and rationales behind the product decisions and opinions on their side.
I once assumed that by talking about my suggestions and proposals in detail, people in my team would understand and trust my expertise effortlessly. However, I was too focused on my stories without paying much attention to others’. The effort on seeking alignment is too critical to be missed.
In the beginning, many people in my company barely knew what I was doing as a Product Designer. With their own individual understanding of design, there were expectations to have me on tasks like beautifying an onboarding doc; designing meeting slides and pitch decks; drawing illustrations for the marketing website and stickers, and of course, tweaking colors and styles...
I was naturally concerned as my priority was to focus on product design. Besides, I was afraid that accepting once may lead to the precedence for many more similar requests to follow. I also did not want to simply say “No” as being a new and sole designer, I was eager to gain trust and find allies.
I set a rule of 20/80 for myself, to spend no more than 20% of my time on trivial tasks. In order to cope with this reduced time-effort limit set by myself, I needed to find a way to manage my time and effort wisely. For these trivial tasks, I decided to achieve that by defining the goal as identifying and solving only the fundamental use case of each task.
To extend with an example, I was asked to “beautify” the onboarding document. Among many problems, one of the key pain points of the document was the hierarchy of the content. The document looked crowded and lacked the essence of text structure. Once the problem was identified, I focused on distilling the important content and adjusting the typography design. The reading experience was improved, along with the clarity on the structure of the content. The work did not require much effort, but the result was acknowledged by the satisfaction of the onboarding team and the users.
These tasks may not be directly related to the product, but surprisingly, I gained lots of knowledge about the product and the people through them. Also they were small in scope with an easily managed timeline and the results could often be seen and measured quickly.
Through working with people on these small trivial tasks, conversations about design were started and I managed to win their curiosity about designing better products. On the other hand, I learned the benefit of keeping the scope small.
For many years, I have always been reluctant to share “unfinished” work. I wanted my work to be “perfect” and “ready”. One of the reasons was that I was too concerned about meeting other people’s expectations as I found that many of us like to judge a designer’s work as if that work was her best.
To free myself from others’ and my own expectations, I found that the best way was to focus on a well-defined goal and try not to think about the judgements on vaguely defined terms such as “perfection”. This further helped in defining a manageable scope and enabled me to deliver - which I later identified as one of the key traits to bring value to the business and improve the experience of the product.
This is especially important being a sole designer in a fast paced startup environment where I was constantly battling with time and resources and I learned this valuable lesson the hard way and here is one of my most defining learning moments.
I got assigned a project to improve the experience for invoices. The original goal was to update the data table with more filters so that the invoice can be easily customized. I did my research and realized the problem was much more complicated. Adding more filters to the data table would not solve the entire problem.
By that time, I fell into a line of thinking with sheer confidence to solve the problem in one shot with a much broader goal. As a result, the scope was getting bigger through the process. The design took longer than expected and the devs were confused about their deliverables. After three sprints, the work was not halfway done. The project was put on pause as there were other projects lining up.
In retrospect, I identified the key mistakes:
I ended up creating a huge project scope as I was so eager to have a “finished” solution to deliver. I thought that this was the only way to show the team my expertise and my value to the project. However, what I did was exactly the opposite, I overestimated my ability to manage the project volume and I failed to deliver the results.
I looked back on my own strategy in dealing with trivial tasks and later realized that the same process would also apply on product design works as well. Focusing on well-defined goals, starting with fundamental use cases and most importantly, never aiming to have everything done at once.
If there is one suggestion from me, I would want to encourage fellow designers to be confident about their “unfinished” work. In fact, from my own perspective, most of my works can be considered unfinished, imperfect or even just started. Let the value of the work be evaluated by the work itself, with the goals, the process and the measurements.
To design better experiences, I know research is critical to identify problems and to gain user feedback and product knowledge. However, the budget, resource and time on research was limited in the company. Meanwhile, there were not many chances to be able to meet and talk to the users directly.
Under these challenging circumstances, I knew I had to approach research in a different way. Instead of setting a dedicated time frame, and focusing on a specific topic, I collected information continuously from different pieces and gradually accumulated the data. So that I could use them when needed. When there was no direct source to get to the data I was looking for, indirect information was also a good starting point, and can be turned to a direct source with time.
Attending meetings could be helpful to gain more access to meeting and talking to the customers.
At first, I had no clue about the agenda for many meetings, so I attended as many as possible. I was not invited to most of them but that did not stop me from simply sitting in and listening: onboarding, client performance review, integration requirements, new features, product enhancement, etc.
Once I gained a better understanding of most meetings, I focused my attention primarily on meetings where I could talk to the clients and users.
I realized that I could also collaborate with other teams. There were many recurring meetings with customers or potential customers on many topics, such as our monthly or quarterly program review, sales demos, onboarding meetings or feature requirement gatherings. Most meetings involve clients talking about their problems, confusions or pain points, and can be easily extended to gain valuable information about their experience.
Hence I offered my help to strategize on how to better guide the users on the meetings with fewer leading questions and a much more open and flexible structure. With more empathy, users were willing to share the scenarios in a much detailed context.
Besides the meetings, working as customer support could help to gain enormous data about customers.I tried to spend about 4 hours per week working as a customer support myself where I could directly talk to the users, and listen to their problems.
I also tried to add a button on the UI to direct users to answer one or two questions relating to their experience about the product. A checkbox was included in the questionnaire to ask if they were interested to be reached out for more details. This can be done using an inexpensive tool and with minimal developing efforts, and gain a list of users willing to talk about their experience in more detail.
Through attending meetings, being a customer support and conducting in-app surveys, I was able to gain more direct resources for the research. Research can be done through many ways and using different methodologies. This gradual accumulation of information allowed me to collect useful data and information under limited time and resources.
Looking back, being a sole designer was challenging because I was never just an individual contributor focusing only on my design craft. Many of my works involved coordination and management. Many times I found myself spending more time on Excel than on Figma. However, I enjoyed the process and my growth along the way.
Just like a design challenge, the same process can be applied to the obstacles on the way. Trust your skills and the process to solve the problems step by step. Throughout the journey, take care of your emotions and be careful not to fall into any negative mindsets.
