How to design a product you understand nothing about

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.

From school to cloud

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???

How not to panic?

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.

No one understands everything 100%

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 Amazon 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! !

They know that I don’t know

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!

I already know what to do

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!

How to understand the basics and start working

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!

Tweak & compare key interfaces

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!

Find the lighthouse

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:

• Someone who’s easy to talk to, assertive, and eager to share with others
• Someone who teaches students or talks at technical events
• Someone who owns a blog or a YouTube channel

Gather some good references

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:

• Asking my lighthouses for content I could easily understand at my level of technical knowledge
• Choosing the ones in my favorite media. As a five-year-old who hates reading (I know I wrote an article), I will always prefer comics or fun video tutorials. Don’t underestimate this tip! It helps to stay motivated to continue absorbing information.
• Redrawing or rewriting it from my point of view (but it can be time consuming)

Find out who made the visuals and how

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!

Collect quantitative user feedback

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.

Work on a variety of subjects

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!

How to be efficient in the long term

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!

Process is love. Process is life.

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

• Acceptance criteria: by detailing the features, a ticket scope is better defined and easier to estimate
• Design reviews: by implementing this ritual halfway through a sprint, you can obtain meaningful feedback early on to reduce the number of - pointless- iterations

It’s not always perfect but I saved so much time last year thanks to those processes! Don’t overlook them!

Asking for another product presentation

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.

Speaking the same language

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.

Taking a step back

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:

• Workflows & Sitemap: our new UX Designer set up the full sitemap and it worked wonders! It was a lot easier to pinpoint similar workflows to harmonize
• User needs feedback: regularly checking user feedback is a great way to notice low-cost updates. Focusing on user needs = essential features and less “noise”
• User tests: in terms of quantity as well as quality, user tests are the best way to get specific insights. Interviews are especially useful to learn of a feature’s “real” usage

So…why work for products you understand nothing about?

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