How to design a product you understand nothing about

How to design a product you understand nothing about Build • Marie-Astrid Molina • 09/02/22 • 6 min read

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

The Nanny

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

Community

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)

Design cloud product

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…