top of page

My design process

Ian Spalter (Head of Instagram Japan) believes design is not about a static picture: is about the process, and I agree. Having a solid work process is extremely important to me, whether I work with digital products, graphic design or pretty much any creative activity in my life. So here are some thoughts regarding the way I work, and how I approach design.


I believe one of the main goals Design should aim to have is helping solve real problems real people have. So it makes sense that, for me, the first step to a successful design is to clearly identify what is the problem ahead. The idea here is to get to the root of the problem, so, for example, if you identify that your users are not clicking through your website homepage, is it because you don't have a clear CTA button, or because you lack a Design System that could help improve consistency and user experience throughout your whole platform? The more difficult scenario is not always the answer, but it's important to know the true problem you are dealing with.

Running a Design Sprint is a great way to find problems and issues people might be having, in the context of bringing new products to life. The challenge after that is prioritising, but that's why you need a good Product Manager on your team, right?


Whether I am working on a new Landing Page, revamping an old Home Screen banner or planning on making a new illustration, I always do research. It's not only to get inspired, but to understand how other people approach similar problems. You can search for similar problems, or you can find inspiration in another field (for example, print design does not apply in the world of digital products, but we absolutely can find parallels between them, such as the use of grid, the importance of colours and expressing hierarchy through typography).


Photo by Kelly Sikkema on Unsplash


Now you have your problem (or your problems, prioritised) and you did your research. Great, what's next? In comes the creative part, in which you lay down your ideas even if they look bad at first glance. People often do brainstorming sessions in this phase, and I consider it to be a good practice to try to involve people outside your field (multidisciplinary teams are great to find people that have different mental models than yours, and they might suggest alternative approaches to the same problem). Specially in development teams, it is very important to involve developers early on the process.

People often associate designers with walls covered in post-its, coloured pens and whiteboards. But I'll be honest and say most of my creative phase is laid out in a notebook with pencil, or even in a text editor. Just write your ideas down, and be sure to consider all the possibilities.


Part of the challenge of being a Product Designer or a Product Manager, is to know when to take an idea that's promising, and start the development process with it. After you leave the creative phase, you should have a clear path to follow in order to solve your problem (never forget why we entered this process in the first place). The next step is to start prototyping.

A prototype of a product is an early version, a simple model of that product. If your product is an app, for example, your prototype could be some of your screens wireframed. If your product is a chair, your prototype might be an early model of that chair, perhaps a miniature, or one made in a cheaper material. The important thing here is to put something out, something that can go through tests (that we will cover next) and that can provide feedback for you.

I normally do my prototypes on softwares such as Figma, given how easy it is to draw anything there, but you can use a piece of paper, as long as you get the idea straight and convey the solution you are aiming for.


Photo by on Pexels


Sometimes, before jumping to tests, you need to get your design validated. If you work closely with your stakeholders, you might need to run your solution with them, before putting something out in the world. These key people might suggest you don't go a certain way, or remove a certain feature from your product, normally because they hold the vision and the bigger picture, whether is for the product or even to the company that product represents. 


When working with Agile development, we often make use of Minimal Viable Products (MVP). This phase of the design process is when you can start testing your solution. If your minimal product is indeed viable, and users can interact with it and understand it, you can colect valuable insights and feedbacks from these people.

It is one of the most important parts: all your ideas and solutions need to be tested before considered successful. We are not designing for ourselves, or even to our stakeholders. We need to solve the user's problems. So get your product in the hands of some users, and ask for their opinion and feedback. Watch them as they use your product. Did they find what they were looking for? The user's journey you've planned, did it happen? That's the time to observe all of of these things, and to adjust.


Now is time to evolve your MVP, turning it into a more robust product. It's the time to execute on your idea. In multidisciplinary teams, tasks need to be prioritised, and a clear roadmap of development needs to be stablished. As your developers turn in small batches, you need to be able to validate them in different moments, specially when they are shipped to production.


Normally with product development, things don't come to an end after shipping. It is essencial that you keep testing your product, understanding how users are using it, and adjusting as you go. It is a cycle of test, adjust and execute, and we need to keep in mind the problem our users had in the beginning. Always remember that we design for users and to solve a valid problem they have.

bottom of page