Hey, I'm Marie-Astrid 👋
I've been working at Scaleway as a Product Designer for over three years now.
But to be honest with you…I didn't understand anything about those highly technical products at first! 👀
Here's my journey, where I learnt how to navigate an environment I didn’t fully understand (then) and how I stopped freaking out about it over the years.
During my design studies, I learned to boost my creativity by working on various projects. I was very comfortable with most of my assignments, and sometimes I even got to choose the ones I would work on!
The issue was clear: I had never worked on a project I wasn’t already familiar with.
Fast forward to my adult life, I was recruited into a tech company: great team and exciting challenges! BUT panic arose as I realized the products were much more complex than I had imagined! My team tried to reassure me, but I still panicked!
How would I manage to design products I understand nothing about???
Like many designers, I am prone to the infamous “impostor syndrome”. So imagine my utter despair as I realized I understood nothing about the products I was supposed to design … So here are three facts I keep in mind every day to overcome the syndrome.
Come on, this fact is clearly not advertised enough!
Companies are in constant evolution, even more in high-tech and innovative industries. It's no secret that our industry has high turnover and technical debt is piling up. We can't keep track of every specific use case. And don’t get me started on incorporating other companies' technologies such as S3 or Kubernetes!
So clearly, I had to demystify the so-called omniscience of developers and realize we were all in this together from the start. Struggling, but together! !
Didn’t I say during the interview that I NEVER worked in this industry?
When I became a recruiter myself, I realized how hard even finding a tech-oriented designer was. We would often select profiles based on how well they might fit the team, the versatility of their work, or even proficiency using specific tools - not their technical background.
So repeat after me: I wasn't hired to be a developer but to design the product and that’s it!
Every product is bound by design fundamentals such as CRUD (create, read, update, delete), user workflows, design systems, etc. Without a recipe, you can still rely on the basics to make a tasty dish!
I became more & more aware of this by helping hire other product designers. Even without any prior technical knowledge, they made great contributions to the discussions.
On top of that, a new designer will always bring a fresh perspective on our current methods and on how to improve our processes (yes, design debt is a thing).
So focus on the basics first, and worry about the technical stuff later!
Now that I had stopped panicking, I had to come up with a plan. My team was expecting me to relieve them of their JIRA burden as soon as possible and for that, I needed to learn & work at the same time every day! How am I still alive? Let’s find out!
To get more familiar with the product usage, I started browsing through the workflows I was used to, such as account creations or profile updates.
After that, I went totally bananas and tweaked everything I saw. I made obvious mistakes on purpose to see what kind of error would show up or entered a huge amount of data to test the load. The stars of the show were the components & documentation! Here’s an example: As I tried to create a Scaleway Instance, I realized I needed an operating system. The description was detailed and the component hinted it was mandatory.
The last step was comparing them with what our competitors used! Were we using different components for the same action? Did we use different namings for the same feature?
This process is not a one-time thing of course, but little by little, I was able to understand how the product worked through my favorite language: design!
As I completed my company’s onboarding, I was very impressed by the speaker’s use of layman terms and examples. It was much easier to understand but it was still A LOT of information to process. I needed someone to teach me the basics!
Like a fisherman in the raging sea, I need to find a lighthouse: someone I can lean on to safely guide me to the land.
I listed the main characteristics I looked for and searched for them as soon as I could:
I couldn’t bother my lighthouses 24/7. I needed to read or watch some tutorials on my side.
I managed to pick out some quality content by following those principles:
Who’s also in need of detailed product explanations? The Visual Design team who illustrate the products, of course!
Our products revolve around abstract concepts, and they have to rack their brains to create distinctive and meaningful illustrations. Illustrating a product is like documenting it at another level. Both their methods and the results were very useful to me - as a product designer - or to anyone who needs to understand the main concepts of each product.
The Visual Design team manager even wrote an article about their graphic makeover!
Instead of conducting interviews, I focused on the ready-made feedback to save time.
I started with the easiest sources: social networks! Using a few keywords, I found some interesting feedback about how the interfaces were perceived.
Next was our Feature Request website. It is made for our clients so they can request specific features. It was perfect to understand what was missing from a technical AND design point of view.
I saved the testimonies relayed by the Sales & the Support teams for last. It helped me get an idea about our customers’ struggles and how we were planning to resolve them.
Reconnecting with the users’ needs helped me keep the goal in sight and freed me a little from our internal developer's perspective.
At the beginning, it was possible for me to work on many different subjects. I attended many meetings with Product Managers, scribbled a lot of ideas, assisted with workshops… It was a lot at first, but a few months in and I was able to remember every product and most of the features. Learning by doing!
During these years, I realized I spent around 40% of my sprints understanding the technical part of my tickets. Even if it became simpler as time went by, I still needed to free up some time to actually innovate on my designs!
In technical companies, products drive the whole structure. As such, it makes sense for the designers to comply with tech rituals and even elevate them. Some useful ones are:
-User stories: by introducing a design request from the perspective of the end-user, it was much easier to understand what I needed to do
It’s not always perfect but I saved so much time last year thanks to those processes! Don’t overlook them!
You know when you're in a meeting and you're nodding along with the speaker but actually you don't understand anything? I do the same.
Out of curiosity, I went to a second product presentation held for my new colleague and that was AMAZING. The information was much easier to take in since I focused on the part I had trouble remembering.
So I stopped being ashamed of my own ignorance and actually went to every product presentation possible. I think a once-a-year reminder can be really useful.
As the dinosaur of my team, I act as their “Human Wikipedia”. But this is a risky situation for the team’s future. That’s why a shared glossary is a good first step to ensure everyone is on the same level of basic knowledge.
It is a simple but powerful tool that can come in handy before launching a project. Because sometimes, Product Managers and developers use different words to describe the same features.
So save lives & time by discussing the terms before starting on your project.
Whenever I am stuck on my designs, I always try to see the bigger picture. It helps me to notice inconsistencies and make the product usage clearer. There are different ways of doing it:
You may be wondering WHY anyone would want to suffer through this “Product Designer” nightmare? The answer is obvious: You will become a better Designer.
🔥 UNSTOPPABLE you will be
Your ability to find solutions can only improve by resolving complex technical issues every day. Clearly, designing other products will be a piece of cake (or at least a lot easier) after that.
📖 KNOWLEDGEABLE you will be Work is the perfect environment to learn as you will apply your knowledge immediately while being surrounded by experts. Moreover, you will improve your understanding of development as processes are very dev-oriented.
🤝 NEEDED you are
Many technical companies put too much emphasis on their competitors and on their own developers’ perspectives. Thus they lack a deep understanding of their users. So YOU bring the science they need to innovate and improve their interfaces!
There are no miracle solutions to fully understand a complex product. But I hope this article will help you understand “something” about the products you will be working on. 😉
And if you are itching to put these tips into practice, Scaleway's Product Design team is recruiting new talents
In February 2021, Scaleway introduced the Mac mini M1 from Apple. It quickly sold out, and I was put in charge of the massive restocking we needed. But there was one big problem: the VNC was slow.
Creating design approaches for high-tech products is an exciting daily challenge. Learn how we succeed to create a library of robust design assets for our cloud products ecosystem.
As we were building Scaleway's Console, we kept recreating the same components. So we decided to gather all of those components into a library. That's how Scaleway UI was born.
