I used to be disorganized — a mess, actually — before I discovered the power of a few simple design tricks. My hope in writing this article is that these Product Design hacks, which I learned from the other amazing designers at Nubank, will help you as much as they’ve helped me. Anyway, without further ado, let’s jump in.

TL;DR

1. How to start your desk research;
2. How to write hypotheses;
3. How to start your prototype;
4. How to organize your pages on Figma.

1. How to start your desk research (a template!)

Why you would use it: You have information coming from everywhere and don’t know how to organize everyone’s thoughts and opinions.

Who helped me on this: João Rios and Leticia Ratkiewicz

What you’ll need: a kanban page (I use Notion).

Have you ever found yourself in a situation where there was a lot of information coming from many different places? Your product manager has some context, your manager has some other context, and the research team already did research about it 5 years ago…

Well, this Desk Research template is for you. It’s just a simple way of organizing everyone’s thoughts and opinions, benchmarks, useful data, random facts… and anything else you think is necessary. Here’s how I do it:

The columns are:

1. Benchmarking
2. Quotes from real users
3. Numbers
4. Questions
5. Learnings

And you can add as many columns as you want, such as “hypotheses”, “outcomes” or “random ideas.” Just make sure it doesn’t get too long!

2. How to write hypotheses (a simple framework!)

Why you would use it: Your team wants to test everything “just to test it”, but you can use this framework to help them test the right things.

Who helped me on this: João Rios (this guy helps me with everything).

What you’ll need: A blank page (seriously).

A Product Manager that I really like, Teresa Torres, once said that Testing Everything Doesn’t Work.

In her words: “I’m not saying don’t experiment. I’m saying stop experimenting at random.” And to help you and your team, there is a framework that is focused on writing hypotheses that you can build on your own.

Problem Hypothesis

We believe that… {here you write the problem}

for…{who’s facing that problem}

will achieve…{desired outcome}

because…{rationale and proofs}

Check our job opportunies

Experiment(s)

We will do…{easy/fast/high confidence/solution}

for…{experiment target parameters}

and we will know the hypothesis is valid when/if…{metric that will prove the achieved desired outcome}

Learn & Build

If the hypothesis is true, we will… {It should be clear what success looks like}

If it is not we will… {writing this will help you define your next steps}

I know it sounds like a lot of writing at the beginning, but trust me, it’s worth the effort. And if you have so many ideas to test that writing this out feels overwhelming, that’s when you know you’re trying to test too much.

The “right amount” of hypotheses that you should write depends on so many product aspects, but this opportunity tree article (also from Teresa Torres) may help you find the answer.

3. How to start your prototype (draw the interactions before prototyping them on the computer)

Why you would use it: You’re new to the prototyping world.

Who helped me on this: Pedro Murad (a Framer genius).

What you’ll need: a pen and a paper (or an iPad).

This is more like a piece of advice than a “trick” or a framework, but it will help you if you’re learning how to prototype — or if you don’t even know where to start with an interaction. And the best part is, it’s so easy to do and forces you to think like a developer/engineer.

4. How to organize your pages on Figma.

Why would you use it: The title speaks for itself. But, really… your Figma file doesn’t need to be extremely perfect, but a little bit of organization goes a long way.

Who helped me on this: Camila Son — the youngest and most talented designer that I know.

What you’ll need: a Figma/Sketch file.

Just like tip number 3, this is not a framework but rather a mindset. Having pages named “Final” or “Almost finished” is the equivalent of having .psd documents with the names “final-v2”. As I said in the beginning, you don’t need to be extremely organized and I’m not saying you should name every layer (because that’s almost impossible for a designer, but I’m proud of those who can do it). All I’m saying is: try to name your pages as a developer would: the version + what you’re building.

Camila Son, the designer who came up with this method of page naming, once told me: “I always just think that I have to handoff my final flows to the engineers, so I try to tell a very linear and complete story about how that flow/screen fits in that moment. Also, knowing that people from other teams will probably end up asking about the project at some point, I try to write a bit of context about each different iteration”.

And that’s it. For now.

If you have another trick that I should add to this list, please comment below and maybe my next article will be “A collection of tips and tricks I’ve learned from the Medium comments of my first Medium post”.

Thanks to Amanda Legge and Paula Rothman.