My design approach

In order to solve the right challenges, it is key to gather insights into the ideal target user's behaviors, motivations, needs and goals. I believe exploring and understanding the problem space, gathering insights and identifying opportunities form the foundation of every good design.

Empathy is crucial to problem solving (and to a human-centered design process) as it allows me to set aside my own assumptions about the world and gain real insight into users and their needs. It is also an essential component of business solutions when you look at things from the perspective of profit, it is key to avoid to create solutions which completely miss the mark by developing solutions in isolation.

For a product or service to truly succeed, it must excel in three essential areas: desirability, feasibility and viability. While having a working technology (feasibility) and generating profits (viability) are crucial, they alone are not enough. A successful solution also requires a deep emotional connection with its users: a sense of desirability that drives them to engage, adopt and share it with others.

To design a desirable product or service, we must first understand the needs, experiences, wants and preferences of our target audience. This involves empathy, observation and a willingness to listen to their stories and challenges. By doing so, we can create solutions that resonate with them on a personal level, making it more likely that they will use, recommend and even become advocates for our product or service.

Throughout the design process empathy can be a potent tool that extends far beyond its traditional application in user-centered design. By actively listening to and understanding the needs, concerns and perspectives of our key stakeholders, including colleagues and client partners, we can create more effective solutions that meet their needs and build stronger relationships. When we prioritize empathy within our own teams, we foster an environment of trust, collaboration and open communication. This enables us to navigate complex challenges, identify opportunities for improvement and make informed decisions that benefit everyone involved.

I do build empathy by embedding myself in the context of my target group in order to gain personal insights into the experiences they have. I do usually do this following these four steps:

• Step 1: Discovery: I enter the user’s environment and make contact with the user
• Step 2: Immersion: I participate in my user’s world to collect qualitative data
• Step 3: Connection: I try to resonate with the users and recall my own experiences to connect and create meaning
• Step 4: Detachment: I step back into the role of designer in order to reflect and create ideas

Here it follows my toolbox of activities and techniques for gaining empathy with end users:

• Beginner’s Mindset: I always try to assume the mindset of a beginner when I seek to empathize with users even when I have prior experience of the context in question. This is because I am both an engineer and a designer an I have to do my best to leave this at the door when I make observations. The key here is to never to judge what I observe, but instead question everything, even if I think I know the answer and really listen to what your users say.
• User Observations: documenting user observations through photos and videos it is easier to dig into them further to help guide innovation efforts, identify the right end users and discover the emotions that drive user behaviors. If project constraints allows I carry out photo or video based user observations in a natural setting in order to record them while they experience the problem I want to solve.
• Photo and Video Journals: in some situations where users can be in far away locations, it makes sense to hand over the camera directly to my users and give them instructions to take pictures and videos of their activities. The advantages with this variation of user observations is I don’t interfere or disturb the users with my personal presence at all (even though users will likely adapt and change their normal behavior slightly).
• The What-How-Why: this method allows me to move beyond this concrete evidence and explore the more abstract motivations which drive the actions I observed. In What?, I record the details of what happens during the user observation. In How?, I describe how the person carries out tasks. In Why?, I make educated guesses to interpret the scene, then I test these motivations on users at a later date.
• The 5 Whys: this method requires to keep asking “Why?” until I get to the root cause of why users behave in a certain way or feel a specific emotion. It doesn’t have to be exactly 5 times, but as long as I am still getting answers, I keep prompting users to dig into their reasoning and behaviors to uncover great insights to find the root causes of their behaviors.
• User Interviews and Surveys: one-on-one semi-structured interviews can be a productive way to connect with real people and gain empathic insights into their needs and wants. I conduct interviews with representative users to explore their experiences, needs and goals. Alternatively, I distribute surveys to a larger sample of users to gather quantitative data on their demographics, preferences and behaviors.

“ Failing to prepare is preparing to fail.” - John Wooden

Here is a checklist and template I use when planning these above mentioned user research activities:

• Cultural Probes: this method consists in creating packages of tasks to give to a target group to get a better understanding of their lives. This probe tasks are often small creative challenges (writing a diary or taking photos, for example) that not only help you gather information, but also provide inspiration for the design process by playfully inviting users to share rich clues about their lives rather than factual information.
• Engage with Extreme Users: It’s important to allocate some time to focus on the extreme users within my target group because it will magnify the problems, needs and methods required to solve the problem at hand. I first consider what makes a user extreme, then I engage with them using the other techniques and at the end with the insights and ideas gathered I came up with solutions that also fit my wider target group. I don’t design specifically for these extreme users that make up a small percentage of the target group.
• Embrace Analogies: analogies provide a fantastic opportunity to capture the attention and imagination of our users through an ingenious and wonderfully simple way to build empathy with them. With over 10 years of experience in shipping digital products across various industries, I’ve learned to draw inspiration from one domain to another, generating solutions that might otherwise remain undiscovered. By using analogies to compare different fields, I create opportunities to envision innovative approaches that go beyond the limitations of a single discipline.
• Bodystorm: when you act out and immerse yourself in different user scenarios, you can better understand the problems a particular user group might face and thus gain greater empathy for them.This method places the project team in the users’ shoes and will therefore boost the empathy for the target group. I assign everyone a persona, interface or touchpoint based on the findings in your customer journey map. If users are present, I ask them to pretend to accomplish their goals as usual. Otherwise, I assign a persona to each member of the group who doesn’t serve as a touchpoint. After carrying out multiple role play scenarios I plan a review session and typically refer back to these ‘real-life’ experiences later on in the design process to come up with the most fitting solutions.
• Story Share-And-Capture: sharing is caring! I always end rounds of user research with a session where team members can share their most inspirational stories and findings. This not only boosts the level of empathy with users, it also informs and inspires the next stage of the design thinking process making the agile team always updated in the design process.
• Journey Mapping: I map the journey users take when interacting with a product or service, from initial awareness to post-purchase support.

I believe it is key to define both the scope and purpose of these activities in order to make sure I have buy-in from everyone on the team. Sometimes people in the team can have strong opinions and biases for example, therefore I make sure stakeholders are on board with the plan for the wider design project.

When I review the data gathered via research with the project team, I let everyone generate ideas separately at first, then examine them as a team for common ideas. I think thematic analysis and affinity diagramsare a great way to make sense of information when I have a lot of mixed data, such as facts, ethnographic research, ideas from brainstorms, user opinions, user needs, insights and design issues.

Solutions come later! I conduct research with a fresh and open mind and only once the research phase is complete, I start to use the data I’ve obtained to develop solutions.

“It is a capital mistake to theorize before you have all the evidence. It biases the judgment.” - Sherlock Holmes, A Study in Scarlet (1887)

This doesn’t mean I don’t introduce solutions in ethnographic research (user testing is important, after all) but it does mean I introduce those ideas at an appropriate time, once I’ve had a chance to observe users without bias.

In this phase, I organize the information, results and insights I have gathered during the Empathize stage. I analyze and synthesize my observations to define the core problems identified up to this point in order to create user centric meaningful and actionable problem statements.

“Analysis and synthesis are equally important and each plays an essential role in the process of creating options and making choices.” - Change by Design, Tim Brown, CEO of IDEO

My goals in this stage is to to crystallize my research findings and better frame problems to make them easier to be understood from stakeholders and teammates, refining the design challenge and establish a clear direction for solution development.

I think the Define phase is perhaps the most challenging part of the design process. A clear definition of the problem statement ensures kick-start ideation in the best possible way and will serve as a guiding light throughout the rest of the design process.

In order to break down complex concepts and problems into smaller, easy-to-understand partsI list here some of the more useful analysis and synthesis methods in my design toolbox:

• Affinity Diagramming: clustering information in an organized manner is one of the most valuable methods to employ during the design process, an affinity diagram is a collection of large amounts of data that is organized into groups or themes based on their relationships. The best way to create an affinity diagram is with the project team and the people who were involved in the previous research stages of the process. Using this technique, the data collected will be in a much more organized state and I find myself in a much better position to define a problem statement and move on to the next phase of the design process.

• Persona Development: our brains are hardwired to empathize with individual people rather than groups of people. Personas do a great job representing the different user segments that might use the service/product. When I create personas, I step outside of my own brain and recognize that different people have different needs and expectations. They ultimately help me to collate user research findings, to personify relevant trends and patterns in the data and to identify the group of people I want to design for, its needs, goals and characteristics.

“Only drug dealers and software companies call their customers users.” - Edward Tufte

• Empathy maps: in order to add even more depth to user personas and build a broader understanding of the “why” behind user needs and wants, empathy maps can be a nice tool to sum up what I learned from user research. They not only help me better understand users, but they also help me take things one step further and communicate my knowledge to others. This is particularly true and important when colleagues and stakeholders are yet to be convinced by or educated about the design.

I do usually find it useful to add two additional sections for pains (problems) and gains (goals) at the bottom of my empathy map after having populated the most common quadrant (says, does, thinks, feels).

• Stakeholder Mapping:drafting a stakeholder map outlining everyone who’s either involved in, affected or influenced by the design process (both internally and externally) ensures the team has got everyone in the field of vision during the design process. A visual representation of the various individuals and groups involved come in incredibly handy when I want to identify the core parties to collaborate with throughout the rest of the design process and understand where the power and influence might come from in regard to design decisions. Once I’ve identified the stakeholders, a good way to prioritize stakeholders is to plot them on an influence vs. interest chart. The actions I take in regard to each stakeholder will depend on which section they fall into.

After the prioritization step it’s a good idea to talk to them to gain a better understanding of how they will affect or be affected by the design project and how to win their support or manage their opposition if they have negative opinions.

• Storyboarding & User Journey Maps: Storyboarding can also help in visualizing the user experience. It helps identify essential touchpoints, interactions and pain points that should be addressed in the solution design. Typically, I create storyboards and scenarios to demonstrate how users might interact with potential solutions in real-world contexts. I also analyze and organize the user journey steps, taking into account the environment in which the user will be interacting and the devices they will be using. Storyboards, App Flows and Journey Maps can also be annotated with MoSCoW tags in order to prioritize the value they bring to the users.

Here's the result of a user journey storyboard I created for a phygital fashion project.

• User Stories: defining short, specific and goal-oriented user stories is key to better frame the problem or task I want to design. I typically use a one-sentence statement that tends to have the following structure:

Later in the design process, I will enhance these stories with a prioritized list of acceptance criteria to guide the agile team in understanding the inner mechanics of the design. These criteria will also serve as valuable collaborative design tools, allowing stakeholders to actively participate in defining and sorting user stories. This helps keep the entire team engaged and ensures everyone's voice is heard.

• Value Proposition Canvas: this framework helps me analyze and improve the value of a product or service. It consists of two main sections:
  • Customer Profile: This section defines the customer's jobs-to-be-done (functional, social or emotional), pains and gains.
  • Value Map: This section defines the products/services and how they act as gain creators or/and pain relievers.

It can later be used to prototype, test and iterate until I identify what truly resonates with the end users. By connecting gain creators with gains and pain relievers with customer pain points, I can sharpen the product's focus and ensure it addresses key needs.

Identify users’ needs is a crucial stage of the process because it helps to define the design challenge and enable me to reflect on how the product or service can help fulfill some of those needs (in point of view and how might we activities, for example).

In this design phase I can carry out this task by creating clear, coherent and actionable problem statements commonly known as the Point of Views (POVs) that can provide a wide enough scope for me and your team to generate solutions which can go beyond the status quo. A challenge well framed is a challenge half solved, thus creating a sense of possibility and optimism can encourage team members to generate human-centered innovative ideas during the ideation stage. A meaningful and actionable statement is created by combining users, needs and insights:

As a transition step between the Define and Ideate phases I combine POVs with How Might We? questions to identify topics that represent subsets of my POVs that can spark the imagination of the whole team and align well with the core insights and user needs uncovered by user research. HMW questions optimistically suggest that a solution to the problem is possible and because these questions offer the chance to answer in a variety of ways they don’t suggest a particular solution since there is not yet an answer. I won’t settle for the first idea that comes to mymind and instead the optimal solution will most likely come from collective and collaborative teamwork.

My design approach is iterative, therefore I am not afraid to revisit and reframe POVs and HMWs whenever I uncover new insightswhich indicate I should frame the problem in a slightly different way, for example after I have tested out some prototypes.

With the solid background of the previous stages, It’s time to let the mind run free so I can come up with as many weird, wonderful and creative solutions that address users’ problems as possible (ahead of picking some to put into practice).

“If at first the idea is not absurd, then there is no hope for it.” - Albert Einstein

In the ideation process, POVs should be the guiding statements since they focus on the insights about users and their needs. The key is to start looking at the problem from different perspectives and to ideate innovative solutions to the user centric problem statements with help of the overall project team by generating a large quantity of ideas in a critique-free environment.

Now it is the right time to answer the HMW questions related to each POVs problem statement. At the end of the generation sessions I filter and cut ideas down into the best, most practical and most effective ones in the hope they can inspire new and improved design solutions and products.

The overall goal of ideation is to eventually generate a high-quality solutions to meet the needs of the end users, but the best solution is rarely the first one. Particularly early in a design project, divergent thinking helps in gathering a wide range of ideas to choose from, from the sensible to the downright weird. This will increase the chances of finding and focusing on an idea that will eventually lead to a truly effective design solution, thus the more, the craziest (and potentially the best) ideas, the better!

Sometimes it makes sense to visibly display personas, stories, scenarios and other design deliverables to keep the ship moving in the right direction during ideation sessions.

Hera are some of the best methods I love to use, sometimes alongside and in conjunction, to ideate for solutions with the project team leveraging the unique perspectives and experiences of the various people involved:

• Brainstorm: is about setting a safe, creative space for people to feel like they can say anything and be wild so that new ideas can be born. I set a time limit, then start with a problem statement (POV, HMW question or a goal) and facilitate the team to stay focused on the topic, aiming for as many new ideas as possible and defer judgement or criticism (including non verbal) by being positive and building on the ideas of others instead.

"It is easier to tone down a wild idea than to think up a new one.” - Alex Osborn, father of the Brainstorming technique

• Braindump: flattening the organizational structure, even just momentarily, is necessary for creative channels to open up sufficiently. In this variant I ask all participants to write down their ideas as they come individually and silently. After reaching the time limit I facilitate each participant to say a few words about their ideas and to stick them on a board or wall grouping duplicates together. When all team members have presented their ideas, I usually like to let the team vote for the best ideas that will be elaborated in next sessions.
• Brainwrite: in this variant I let participants write ideas onto cards and then pass their idea cards on to the next person, moving those cards around the group in a circle as participants build on the ideas of others forcing them to build on, instead of criticizing, leveling the playing field. In order to keep the energy level up sometimes I find it fun to adopt the brainwalk variant where participants have to get up from their seats and move to another spot around the brainstorming table.
• Worst possible idea: this fun variant helps break the ice when no one wants to say anything by flipping the brainstorm on its head helping those not so confident in expressing themselves. Instead of going for good ideas and putting the pressure on, I call for generating as many terrible ideas aspossible and then challenge the group to turn those horrible ideas into good ones.

“To invent, you need a good imagination and a pile of junk.” - Thomas Edison

• SCAMPER: this methods consists in a series provocation that act as a thought sparker and help innovate on existing products, services or situations by looking through different lenses:
  • Substitute: what can I substitute or change in my product, problem or process?
  • Combine: how can I combine two or more parts of my product, problem or process so as to achieve a different product, problem or process to enhance synergy?
  • Adapt: which ideas could I adapt, copy or borrow from other products?
  • Modify/Magnify/Minify: what can I modify or put more or less emphasis on in my product, problem or process?
  • Put to another use: what are new ways to use the product or service?
  • Eliminate: what can I eliminate or simplify in my product, design or service?
  • Rearrange/Reverse: how can I change, reorder or reverse the product or problem? What would I do if I had to do this process in reverse?

I go down the list and ask questions regarding each of the seven elements, applying and adapting the questions to values, benefits, services, touch points, product attributes, pricing, markets or any other related aspect that has relevance to the ideation needs.

• Challenge assumption: assumptions we make about how things should be and how they should work may well be what is preventing the positive change we seek. The key is to take a step back from the challenge the team is tackling and ask some important questions about the assumptions we have about the product, service or situation where we're trying to innovate. I facilitate the team to list all the assumptions about the problem statement then challenge the team to overcame them in new ways.
• Analogies: metaphors and similes can encapsulate insights in a rich picture. Analogies are a great way for us tobuild empathy with users, to synthesize and define information and to generate new ideas around a problem. I often use analogies to gain a fresh way of looking at an environment or in instances where direct observation is hard to achieve. It all boils down to exploring unrelated concepts for an insight, which I can apply to my own problem's context. Some designers say: all design is re-design. I think it is fine borrow ideas from elsewhere (nature, unrelated industries,…), or building on others’ ideas and remixing them into new formats and combinations.
• Sketching: I often use sketching as my first line of attack to crack a design problem in the early stages of the design funnel to explore multiple design directions at low cost. It is a quick, timely, cheap, disposable and easy way that does not require any software (that brings on the table its own limits) and lessens the chance to reuse a digital solution already created, giving you more freedom to explore new ideas starting from a blank page.

Sometimes bringing on the table a draft digital solution can make people feel like it is already all done and they have no part in the process, a sketch leaves lot of room for improvements and feedbacks from other teammates. It can also be a digital sketch on an iPad, but the idea here is to leverage the freehand freedom and the option to discard them without much effort (removing the fear for other teammate to give you an honest opinion that can ruin hours of work on a digital prototype).

Once ideation sessions end, it’s time to collect, categorize, refine and narrow down the best idea, solution or strategy. Here I use different methods to wrap up the session with my teammates:

• Dot voting: allows every member to have an equal say in the shortlisted ideas.
• Four Categories: consists in picking a couple of ideas for each category according to their relative abstractness, ranging from the most rational choice 🧠 to the long shot 🚀
• Bingo selection: in this method I encourage the participants to split ideas according to a variety of form factors, such as their potential applications in a physical prototype, a digital prototype and an experience prototype.
• Idea Affinity Diagrams:consists in clustering similar ideas together and make connections between them that will help in uncovering patterns or themes that may be promising. This helps in the process of selecting the best ideas or idea themes.
• Now Wow How: consists in clustering ideas evaluating feasibility and originality: if they can be implemented immediately but lack novelty (Now), can be implemented and are innovative (Wow!) or could possibly be implemented in the future (How?)
• Six Thinking Hats: It involves purposely evaluating and considering ideas through various mindsets so as to uncover the widest range of possible angles on the ideas being assessed. It helps break participants out of their set styles of thinking and forces them to look at the ideas being assessed from multiple viewpoints and assessment criteria based on the color of their hat:
  • White Hat:calls for information which is known or needed. It’s all about the facts and nothing but the facts.
  • Yellow Hat:symbolizes optimism, confidence and brightness. It’s all about exploring the positives and probe for value and benefit.
  • Black Hat:it’s is all about judgment. When you put on this hat, you’re the devil's advocate where you try to figure out what or why something may not work, spot the difficulties/dangers and ask yourself where things might go wrong.
  • Red Hat: calls for feelings, hunches and intuition. It’s all about focusing on expressing emotions and feelings and share fears, likes, dislikes, loves and hates.
  • Green Hat: focuses on creativity: the possibilities, alternatives and new ideas. It's an opportunity to express new concepts and insights.
  • Blue Hat:it is the facilitator hat and it is used to manage the thinking process ensuring guidelines are observed.
• Lean Startup Machine Idea Validation Board: the premise of this approach is starting off with a set of related hypotheses (Customer HP; Problem HP; Solution HP) and testing these three related hypotheses. If the team cannot validate them, it pivots on them so as to move towards a more valid set of hypotheses that will help build an innovation foundation, one which is viable and addresses a real need.

I usually pick one of these methods based on the nature of the teammates, on the problem statement and on the kind of ideas previously generated.

Prototypes are one of the most useful tools to go from thinking about ideas to executingon them. In early iterations, I use prototypes to make my ideas concrete and explore alternatives adopting a “thinking by doing” mindset; in later iterations, I use them to test my designs and make improvements.

“One of the big problems in corporate North America and Europe is that people think that innovation is a thinking activity. You don’t innovate through powerpoint. You innovate by building things.” - Tom Wujec, Fellow at Autodesk.

However, diving into the first good idea is not a good idea, because most problems we want to solve are more complex than they look on the surface!

Prototyping has several strengths: it makes ideas concrete, tangible; it provides other people with a view into my thinking so they can contribute to it; it shows what I know and what I don’t know, allowing for an iterative process to continue to refine a solution early in the process; it lets me fail quickly and cheaply, so I can help my clients invest less time and money into a bad idea or a feature that does not bring real value to the users.

Prototypes help us communicate our ideas to other team-mates. I usually first share and test these prototypes within the team itself, in other departments or on a small group of people outside the design team. When I am able to show an image or sketch of what I propose, then I can more easily get buy-in from stakeholders and address their concerns especially if they don’t have a background in design.

However, I think prototypes are not just meant for validating the design by getting stakeholder feedback and buy-in. They are a powerful and flexible way to gain deep insights. Before prototyping I always ask myself what is the purpose of the prototype I am building identifying the key questions I want answered. Sometimes I can use prototyping to gain an understanding of the problem as well as the users’ mindsets. For instance during interviews I can ask users to create the prototype and use their designs to understand their thinking, or I can build a prototype to help my team step into the users’ shoes or to move the process forward helping the team decide between two options comparing competing ideas.

In general, I create low-fidelity prototypes (which usually don’t look like the final product) when want to quickly and cheaply test some design ideas. I create high-fidelity prototypes (digital mockup which look and behave more like the final product and may even be interactive) when I already have a good idea of what to create and want to test and finalize the details of an idea. Sometimes, I can also create prototypes with different parts with varying levels of fidelity. For example, I can build a prototype with high visual fidelity but with low functional fidelity, which I use to test only the visual aspects of the prototype.

Hera are some of the best methods I use to create low fidelity prototypes:

• Sketches: they can be done everywhere, they are incredibly easy to create and even easier to discard. However they are almost never of high enough fidelity to be useful with people outside of the team, since they rarely have the context to understand what the sketch is meant to convey.
• Paper Prototypes: If I am looking at novel solutions, then paper prototyping is a great way of starting. They are easy to create modify (and animate!) because every teammate can do all that by hand without having high sketching skills. However they may be less helpful if the product design follows commonly used user interface patterns. In any case they are a quick way to test whether people understand my solution and they are very obviously unfinished, therefore stakeholders are unlikely to hold back their critiques for fear of hurting my feelings.

• Digital Wireframes: they allow me to ignore the visual and interactive aspects of my prototype and focus on content structure and functionality letting me easily communicate the relation between different pages in the product. Since wireframes don’t contain details such as images, fonts and colors they can be quickly changed. I use them when I am ready to focus on the content and to think about topics such as how to create optimal user flows, what kinds of templates I should use for various screens and pages and how much space to allocate various elements on a screen.

• Wizard of Oz / Flintstoning: the idea of “fake” prototypes is to get users to believe that the prototype is fully functional, so I can test it while saving time and resources. This is done with the help of team-mates that mimic complex interactions rather than by coding a piece of software for it.

Later in the design process, where I want to test the final details of an idea (images, animations, fonts, final copy, …) I go for high fidelity prototypes. Hera are some of the best methods I use:

• Digital mockups: which look close or identical to a finished app and may even be interactive. They help me get more meaningful feedbacks from users, who can understand exactly what the product looks like. This prototypes are more engaging, so stakeholders can instantly see their vision realized and will be able to judge how well it meets their expectations, wants and needs.

I usually build UI interactive prototypes with tools like Figma or Adobe XD to test the design with user or to support presentations during design reviews demonstrating the navigation and interaction flows to stakeholders, product managers and developers. It is way easier to persuade clients (especially to get funding) with a beautifully designed prototype, as opposed to a rough sketch! In addition to this high-fidelity prototypes are even a necessity when I have to hand your designs over to other dev teams.

• Coded prototypes: sometimes it makes sense to invest in a basic feature or creating a functioning app/interface to test with users. It is usually the more costly choice but it also can be done cheaply going for a boring simple solution or for a minimum viable change in an existing product. Since I have a background in computer science and engineering sometimes I even find it cheaper to code a fake analytics dashboard using a JS chart library with hardcoded real JSON data rather than designing a graph on Figma.

• Live Prototypes and Pilots: I use live prototypes to test parts of the solution in real-life environments and conditions. They can last for days or weeks, depending on the aspect I want to test. When I feel confident in my solution (perhaps after a few runs of live prototypes), a pilot of the product or service can be launched to test the entire system. Pilots are exceptional in giving me a firm idea of whether the solution would work in the long term, to discover even hidden logistical and legal consideration. It is key to first define the various metrics that should be monitored in order to better assess the feedbacks from users and other parties involved to figure out what works and what doesn’t.

If the prototype is a success, congratulations! 🥳

However failure and prototyping often go hand in hand. After all, we are likely to discover mistakes when we test your prototypes.

“I have not failed. I’ve just found 10,000 ways that won’t work.” – Thomas Edison, American inventor.

Thus is important toreframe the idea of failure in prototyping into a learning mentality. Wrong ideas and failed prototypes allow us to learn more than successful tests and prototypes do. Although we might spend time building prototypes, they actually allow us to move faster in the long term making us see earlier whether our ideas would work out, allowing us to refine or abandon them eventually reaching the ideal solution faster.

The end goal of my design process is to create a solution that is desirable, feasible and viable. This means that the products I design should satisfy the needs of a user, be feasible to implement and have a financial model as well so that they can be sustainable.

Technically, almost anything is feasible, depending upon how much time and resources you have! I really value early communication with the developers (about software capabilities) and marketing (about distribution channels) so as to come to up a compromise that the whole project team can live with while executing an idea.

I think the commercial viability of the product is key to determine its long-term success, even for non profit organization or project that rely on funding from donors or government. To conduct an evaluation of my solution’s viability, I analyze in this phase the value proposition the product or service provides (how much users are willing to pay), think of potential revenue sources (all the actors that are willing to pay) and consider various stakeholder incentives or disincentives (ways in which I can tweak the product in order to encourage their participation).

Testing is crucial in any design process in order to validate ideas, find usability problems and create a final design that works much better.

User feedback is priceless and without it the iterative design process will fail since the testing stage is the one that most often feeds into other stages.

Testing early and often is key to discover major usability issues, fix them and eventually launch a product that people can use with ease. When briefing participants, in order to gather honest feedbacks, I deflect any perceptions about your personal involvement and I de-emphasize how close I am to the work and clearly let them know that we are testing the design and not them. It is key for getting accurate feedback from test participants (and to allow them to contribute ideas) to beas objective as you canand refrain from trying to sell your ideas or defending your prototype.

To get the best results, I alway try to test on the right peopletrying to gather a representative sample of users to get the most relevant feedback. On top of regular users, when I have a chance also test on extreme users to uncover problems that affect regular users, because they tend to be more vocal about their love (or hate) of doing things.

These are the common types of usability tests I use:

• Heuristic evaluations / UX audits: they are usability reviews where you use experts to evaluate your design based on a list of heuristics, guidelines or usability principles. They are often quicker to conduct than lab usability tests since you don’t have to spend as much time to recruit participants and moderate test sessions. However they are not as effective as testing with real users. Nothing beats sitting down with a user of your product to find out usability flaws and probe into their behaviors.

To maintain time efficiency, it might be beneficial to integrate frequent, micro-sized audits into the development process. This approach could have a faster impact, especially if audits are performed each time a new feature is introduced.

I refer to this checklist following a structured audit process to ensure consistency in addressing key areas of improvement effectively.

I then categorize the issues into four colors (thoughts on what is good, new ideas, areas of improvements and things to be fixed) in order to prioritize issues and facilitate collaboration among team members. Regularly revisiting and updating the audit process ensures that the product stays aligned with user needs and evolving industry standards.

I experienced that reporting findings in a clear and concise manner is crucial for gaining stakeholder buy-in and driving action. Highlighting key takeaways, proposing an action plan and providing supporting evidence through screenshots and recordings enhance the effectiveness of the report. Here is an example of a UX audit I conducted on the YouTube app:

• Guerrilla usability tests: quickly grab someone to conduct a short usability test, then you’re better off than if you finalized your design without conducting any tests at all. The idea is that some testing is better than no testing. They are often the a cheap solution if there is a tight budget or timeline, however they are not good enough for thorough tests of the designs, for that I have to conduct more formal usability tests with participants recruited to fit the project personas.
• Lab usability tests: sessions where I invite the participant to a controlled environment to record and observe them perform tasks with my product/prototype. They can help in finding rich insights into users’ mindsets and behaviors because I can ask them probing questions. However they require a lot of time to plan the test, create a script and moderate the sessions.
• Contextual usability tests: similar to the lab-based but they are usually done in the participant’s natural setting (their home, office, school or a public place), wherever they would use the product. They can be more expensive and time-consuming than other tests because they require the team to travel to where the participants are located.
• Unmoderated remote usability tests: conducting usability tests remotely and without active guidance allows for cheaper tests the can be assigned to a larger sample size (since you don’t have to manually moderate each test session).
• Remote moderated usability tests: they are very similar to contextual usability tests, except I am communicating with the participant through screen-sharing software rather than in person. However I don’t get to see the participant’s environment in the way that you would with a contextual session and there can be technical difficulties that interrupt the testing session.

Sometimes when the participants don’t have much experience with giving constructive critique the “I Like, I Wish, What If” method is useful to invite them to provide open feedback and to end every testing session with a post-test interview letting them provide additional feedbacks. Because people naturally feel good about finishing a test I always ask them to talk through the process, so I can collect feedback at each stage.

I do usually use scorecards to gather information for each step of the process I am testing, taking note of general thoughts, sentiment, pain points and opportunities. These scorecards can then be used to improve the design, simplify it if necessary or even decide to unship a particular functionality if it's not meeting user expectations.

In order to present these results to the team, after I’ve done a round of tests with my prototypes, I find it engaging to convey them by sharing inspiring stories as they are powerful tools that to inspire the other stakeholders. In the context of a usability test, stories are even a great way to allow the team not only in focusing on the results of participants completing their tasks but also on the journey they took to get there.

After the launch, data coming from real world usage is key to iterate on the product or service I designed. I use a couple of addition methods at this stage:

• Reviewing Issues: it can help in gaining valuable insights into how real people are interacting with the product. This feedback loop ensures that design decisions are grounded in actual user experiences and can also help identifying frictions points while using the product (and even help prioritizing improvements). Reviewing issues also helps building trust and loyalty with final users, making them feeling heard strengthening their relationship with the product.
• Data validation: reviewing usage metrics is key to ensure the product is viable (delivering a positive return on investment with a sustainable business model) and to understand which aspects of the user’s behavior needs to be further investigated via additional user research.

I always start testing with a set of few questions I want answered about my products. However I think it is key, at the same time, to keep an open mind. Many times, test sessions can reveal key points on issues that the team did not even know to focus on. Therefore after testing, I evaluate the feedbacks and decide if there are new questions that I should ask during future test sessions.

Testing really is the key to success a good product design. The secret here is adopting a flexible mindset, not getting too attached to your own ideas and always being ready to dismantle, change or even abandon them.

Here are some additional methods and activities I value in my design process that can be integrated into the overall design thinking methodology.

Sometimes, particularly during presale activities, when business goals are still unclearand stakeholders need guidance to identify the problem space and explore potential long-term strategic opportunities, I also employ future-thinking design activities in addition to those outlined by the design thinking methodology.

I organize workshops and brainstorming sessions with stakeholders focusing on future trends, challenges and opportunities augmenting each phase of the design thinking methodology with additional less user centric point views. For instance during the Ideate phase I encourage participants to form groups of 3-4 people and think creatively and collaboratively about potential future scenarios performing this kind of activities:

• Trend Analysis: analyze emerging trends in relevant fields such as technology, demographics, economics and culture to uncover potential future developments and innovation opportunities.
• Weak Signals Detection: pay attention to early indicators of emerging trends or changes that may not yet be widely recognized, gaining insights into potential future developments and opportunities.
• Wild Cards Analysis: explore low-probability, high-impact events that could disrupt the status quo. I consider how they might shape future scenarios to develop strategies that mitigate risks or capitalize on opportunities.

At the end of the session stakeholders vote on the best ideas from each group. These ideas might then become the starting point for their digital strategies and business models.

Understanding the competitive landscape, identifying best practices and uncovering opportunities both for innovation and differentiation can be a good way both to generate new ideas and to gather user needs by analyzing existing similar products or services.

Here are some standard benchmark activities that I usually implement:

• Competitive Analysis: Conduct a thorough analysis of competitors' products, services and experiences. Evaluate factors such as features, functionality, user interface, user experience, branding, pricing and distribution channels.
• User Testing of Competitors' Products: Carry out user testing on competitors' products or services to understand their strengths and weaknesses from a user's viewpoint.
• Feature Mapping: Construct feature maps or matrices to compare the features and functionalities of competitors' products or services.
• Benchmarking: Set benchmarks for key performance indicators (KPIs) based on the features that each competitor offers, thereby identifying areas where our offering excels or falls short compared to industry standards. Monitor their user feedbacks inside reviews or forums in order to better understand their needs and frustrations.
• SWOT Analysis: Perform a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis of competitors' products or services for strategic insights and implications.

I review the analysis with stakeholders and designers, comparing and contrasting competitors' offerings. We identify strengths, weaknesses and areas for improvement. This process helps define high-priority features for the first MVP and other desirable features.

A clear understanding of the product's business model is crucial for setting project goals, priorities and focus, making sure that the final product will be viable. My design approach involves defining or refining this model, demonstrating how the solution aligns with the value proposition and revenue model, while considering risk assessment and mitigation. Typically, I also establish metrics for guiding the development and evaluation of the solution. These encompass usability, accessibility, performance and user satisfaction metrics, as well as business KPIs such as conversion rates and engagement metrics.

A visual representation of the ecosystem surrounding digital products or services is essential. It illustrates the diverse stakeholders, interactions and relationships within the product's community. In my design process, I use community mapping to align stakeholder goals with the product's objectives. This ensures that we meet the community's needs and expectations while allowing the product to evolve according to user feedback and market trends. It is also a valuable tool for strategic planning and product development prioritization.

Here's what my mapping process typically includes:

• Stakeholders: The map identifies key stakeholders (users, customers, back-office staff, administrators, third-party service providers, etc.) in the digital product's ecosystem. I refine user personas based on user research insights, including detailed behaviors and preferences, to accurately represent the target audience and their needs.
• Interactions: The map details the interactions and connections between different stakeholders, how users engage with the product and their interaction with various features and functionalities.
• Touchpoints: The map identifies where users interact with the product across different channels and platforms. This can include websites, mobile apps, social media, customer support channels, physical locations and third-party integrations. It also highlights ecosystem partners and third-party integrations that contribute to or extend the product's functionality, such as integration partners, API providers, plugin developers and service providers.

Organizing and structuring information is vital for crafting intuitive and effective user experiences. My background in computer science and engineering aids me in considering boundaries such as technical limitations and budget constraints. This helps steer innovative problem-solving while keeping ideation activities grounded and feasible.

Here are some common design activities I put in place to define the information architecture:

• Content Audit: This involves evaluating the quality, relevance and effectiveness of content assets on the entire platform. During this evaluation, I consider privacy implications and establish security standards needed to protect data.
• Taxonomy and Information Hierarchy: In complex projects I organize content into meaningful entity-relationship diagrams (e.g. https://dbdiagram.io/d/S1-FSTech-Innova-61dea66c4c9a8944ec8d46a6 ) that the development team can review and enhance. This method helps me establishing the connections between different content elements and assists me in designing interfaces using common design patterns that aid users in effectively navigating the digital product.
• Cloud Architecture: as a digital product designer with a strong foundation in computer science, I leveraged my background in both disciplines developing a holistic approach to designing digital platforms that extends beyond user interfaces to encompass the underlying cloud architecture. My process involves collaborating closely with cross-functional teams, including architects, developers and stakeholders, to ensure that the cloud architecture aligns with user needs, scalability requirements and business objectives. By integrating user-centered design principles with technical proficiency, I deliver digital platforms that are not only visually compelling but also robust, scalable and optimized for performance. Here it is an example of 3-layer architecture that can be a starting point for new projects:

During these activities, I highly value receiving feedback and additional information about technical constraints or user research context. This allows me to better evaluate and adapt my design, while considering the best user experience and understanding the impact of these constraints from a user perspective. This can be a phase where differing opinions may conflict. Therefore, proactive communication is key to effectively assess design change requests and decide how to proceed.

From my designer's perspective, a design system is more than just a style guide with a component library. It should encompass principles, tools and component patterns that enable designers to create a consistent user experience across various products and functionalities.

The ideal design system is the result of a balanced collaboration between design and development teams, it is not a designer only resource. This requires a synchronized approach, sharing responsibilities at different stages. Designers and developers should work together using the same tools and languages to create the optimal user experience and interface for the end user.

I also believe that not every project requires a new custom design system. For products targeting an internal company community, which doesn't need strong, recognizable branding, using a standard design system or adapting an existing one can reduce the risk of not meeting deadlines and the testing effort. One advantage of using publicly available design systems is that they usually already considers web/mobile accessibility guidelines, making the product access easier for all users.

Written documentation, in addition to visual prototypes, holds immense value in the handoff with stakeholders.

It serves as a practical tool that can significantly reduce interruptions from colleagues, especially during crucial work hours. We often find ourselves in situations where we aren't able to respond quickly to a call or an instant message and having a well-documented guide can prevent us from becoming a bottleneck in such scenarios.

In addition to this, there are several other advantageous aspects of maintaining written documentation. One of the most notable benefits is that it forces us to undertake a self-assessment of how the design should ideally function. This introspection nudges us to delve deeper into our work, dissecting and understanding the role of each component that contributes to the overall design. By promoting clarity and providing an easy reference point, written documentation improves efficiency and productivity. It encourages us to scrutinize our designs, understand their workings and thereby strengthens our comprehension of the project as a whole. Thus, it's not just a resource for others, but also a reflective tool for our own understanding and personal growth.

I typically create blueprint documents in Word when they need to be printed or formally validated. However, for flexibility and collaborative editing, I prefer using web-based documentation tools like Notion. These documents contain comprehensive information about the product's operation, including the information architecture, navigation flows and user interactions, which are supported by visual layouts from prototypes. I outline the purpose of each section and the behavior of each component on every screen. For instance, I detail how filters should function, the default ordering and pagination of tables, field types and constraints and the effects of clicking on call-to-action buttons.

In creating the documentation, I first review the initial project requirements. I then collaborate with developers to establish the product's technical architecture and implementation details, including database design, APIs and integration with external systems. In addition, I include security features and best practices to safeguard the product from potential threats and vulnerabilities.

Since the design will likely evolve based on user feedback, I prefer to use version control systems. This helps manage changes to design assets and ensures collaboration among team members. The documentation can also serve as a foundation for user manuals and a reference for testing activities.

In my daily job, I often find myself in the role of project manager. I regularly track the progress of activities using agile tools like Jira, where I plan sprints and populate the backlog with various tasks. For projects not following an agile approach, I also use Excel spreadsheets to track activity completion, ensuring adherence to the project scope. You can find the templates I use here:

Occasionally, I use checklists to keep track of non-design related project activities in order to check if all were planned insider Jira. You can find an example of my checklists for organizing the deployment of UAT and production environments: