Digital Product

1. Problem Definition

1.1 Product Brief

The product brief is basically a sum up of what, why and how. What we need to build, why we are building it, and how we are going to do it to maximise success. Having the process written down and documented gives us and the people we work with the context and focus needed to achieve the goals and make smarter and better-informed decisions.

1.1.1 What Are We Doing?

Sometimes we face a feature improvement or a completely new implementation because someone had a disruptive idea or received some specific feedback (which is totally legit) but we don’t actually stop to think about what the scope of the job really is. This section is meant to define what we need to do and what we don’t, and clarify any uncertainty around that.

1.1.2 Why Are We Doing It?

This one should be easy but, from experience, I can say that sometimes it is not all that clear. To simplify, I like to divide this step into two sections:

➡️ The ‘why’ for user personas
➡️ The ‘why’ for the company

Doing it this way we are able to differentiate the reasons behind the necessity to develop the feature or product in hand, and also be more precise when thinking about the possible solutions.

1.1.3 Metrics And Success

Equally important as the reason why we are doing something is the way we measure its success. It’s crucial to establish the hypothesis, what metrics we expect to change, and what the current status of that metric is. By defining success we can set better goals and direct our efforts to accomplish them.

1.1.4 User Stories

“My friend doesn’t like the password input” is, by no means, a valid user story. User stories must derive from user personas and therefore address the goals and solve the pains established for those profiles.

A valid user story could be based on this structure:
As [user persona], I [want to], [so I can].

So, “As [Sarah], I [want to compare bike models], [so I can make a better decision]” sounds a bit more like a precise story that could be actioned. To see how user stories could be estimated and prioritised, check out the template below. I’ve used that template to organise the tasks among the product manager, the development and design teams to be more transparent about the workload and goals.

1.1.5 Alternatives And Competition

Is anyone doing anything similar? How are they doing it? Can we replace them? A bit of research and benchmarking will help us add more reasons to the WHY question (e.g. The why for the company: It sets and advantage for them, as no other competitor has developed anything similar) and validate our assessments, pushing us to make better-informed decisions.

1.1.6 Deliverables And Timeline

Pretty straightforward: what do we need to deliver, and when? Splitting this information and assigning it to different teams can help everyone visualise the general effort needed. Make sure also to establish feasible deadlines and track them during the key steps of the process.

2. Production

2.1 Flows

Before jumping straight to the wireframing phase, it is necessary to create user flows (as many as needed) to understand how the user interacts with the product and how those stories that we have elaborated fit in the big picture.

Here, we will be able to identify pain points, issues in the architecture, as well as define the multiple possible behaviours within the product in hand.‌

To create these flows and most importantly share them, I like to use Miro. With Miro we can create from a simple flowchart to complex customer journeys and it allows us to share them with our client or team, which is very important, especially if we are working remotely.

2.2 Wireframing

A wireframe is an extremely low-res representation of how the flows might look and how the information will be built around the page, app, or whatever it is we are designing. ‌

If we are working with a client or team in a collaborative environment, I would recommend using whiteboards so that everyone can see and contribute sketching ideas. If that was not the case, I’d recommend using Freehand from InVision. ‌

With Freehand we can invite the team to our board and have them collaborating in real time. I know, this can go terribly wrong, but I use it mainly for sharing or collaborating purposes while being in a call.

2.3 Content

At this step, it’s really important that we have clarified what the content of our design is going to be, or at least a draft of it. Sometimes we will have a content editor providing this, but it can also be the client who will decide on it. If that’s the case, make sure you both agree on the final edit to avoid last time changes in the prototyping phase. ‌

If the content is not provided by a content editor, and the client doesn’t have a clue either (that’s something to be concerned about), then it might be a good idea to provide a placeholder. I’m not a big fan of doing it myself and I would totally avoid filling up the page with a Lorem Ipsum. My advice is to try to find a professional to write it. I’m not a master content editor, a genius copywriter nor a UX writer expert, so I prefer to partner with people who actually are.

2.4 Prototyping

2.4.1 Sketch

I like to use my tools according to the needs of the job that has to be done (crazy me). I’ve used both Figma and Sketch for different projects and I can say that most of the time I tend to work with Sketch, especially if the development of the product in hand requires a design system with a strong library of components.‌

Once the screens are ready, I export everything to InVision using the Craft plug-in. But before doing that, it’s really important to consider the naming of the screens and how they are sorted.

Screen naming

The final naming of a screen would look like this:
[sectionName] – [screenName]‌

➡️ [sectionName] matches the name of the page section, duh (e.g. Discover).
➡️ [screenName] must be short but contain enough information to understand the purpose of that specific screen. (e.g. Home Screen, Reviews Opened or Details)

Screen sorting

I always use the left to right, top to bottom sorting so that my screens are exported as desired and following the flow that will be prototyped. This makes things easier in InVision with the sorting of the screens and therefore the connections among them.

2.4.2 InVision

I use InVision for several things. One of them is to build the prototype that is going to be shared and hopefully tested out. To do this, I first make sure that all screens have been re-named properly, and then I create an InVision prototype.‌


I prefer to connect the screens in InVision rather than in Sketch to eliminate noise from the visual components and screens. This also gives me more freedom to change screens or modify the flow in my Sketch file without having to deal with the connections too. If the changes are meaningful enough, I create a new prototype in InVision for the new version.‌


One more thing we need to consider, especially when helping our dear developers, is to mark every asset as exportable. The needs here might change depending on the device we are designing for. But as a general rule, I offer them from @1x to @3x PNG or JPG plus SVG format, as required.

2.4.3 Principle & AE + Lottie

I’ve used Principle when needed, but I’m starting to experiment with AE + Lottie. I use Principle because it’s faster, gives every stakeholder an idea of the type of interaction we want, and offers more flexibility to the developers to choose the way they want to do their job. ‌

Lottie potentially generates better animations — as AE is way more powerful than Principle — but it also creates a bit of a harder design process if you come from Sketch. I would not recommend it for the interface itself but rather for loading animations, illustrations, or corporative pages that need to shine.

3. Delivery

3.1 Design System

A design system is conceptually similar to a brand handbook. It obviously stands under the shelter of it.‌

A design system is basically a systematic approach specifically oriented to product development and everything that implies: product guidelines, behaviours, and ideally code.‌

Its benefits have been described by many professionals coming from different backgrounds, and go from more consistent, to cheaper and higher quality products. I think a design system well developed also improves the relations among co-workers and provides a healthier environment to work at.

3.1.1 Grid & Columns

Some of the first elements that help us define the edges of our product are the grid and the columns. They help us organise the information across the artboard and must be defined in Sketch. They are the basic structure of our design and should be considered the master layout to follow in future implementations.‌


The number of columns needed is totally subjective as it should be defined following the nature of the product in hand. This means that for a content-heavy site we might need more columns to split the information having different layout options, and for something simpler we could reduce them or increase their size to create more balance or use the white space with more intention.‌

Anyhow, the column layout and the size must be well documented and specified in the design system.‌

Do not forget that columns help us organise the content horizontally in a consistent way. For the vertical arrangement of elements, we might use the grid.‌

The 8pt Grid

The 8pt grid is another technique widely used and implemented across several digital products. It’s well documented and spread, and the reason why is because it is the rule used by the Google Material Design System.‌

Why the number 8? Well, in a digital environment and considering the most common and used resolutions (1920, 1600, 1440, 1280, 1024, 768…) we quickly come to the conclusion that all of them are divisible by 8. This makes an 8pt grid the most suitable option to sort information in a space with a size that is multiple of 8.‌

But, why not use 4pt or 2pt or 1pt? Good question, they can also be used, and actually the 4pt grid is usually combined with the 8pt to deal with typography scale. But the idea to not go smaller than 8pt comes from the urge to not bring excessive complexity to the grid and offer too many minimal variations that wouldn’t provide any meaning and would most likely result in a confusing, less maintainable and hard-to-use product.‌

Exception: The 5pt Grid

I’ve also used a 5pt grid when designing specific mobile applications with iOs as the main platform to focus on. Why is that? The main reason is, again, the resolution sizes. Having phones with resolutions that are not divisible by 8 (375, 750 or 1125) makes the use of an 8pt grid completely ludicrous.

To sum this up, I would say that the main mantra should be: adapt to the platform you are designing for.

3.1.2 Styles


When defining colours for design systems, we need to meticulously consider accessibility. These colours must be the same as the ones defined in the brand handbook (that hopefully will be contrasted enough already), but sometimes they need to be slightly adapted to pass at least the AA WCAG because accessibility wasn’t considered. We must think carefully about this and about what the needs of the product are. We don’t want to be changing the whole colour palette just for the digital product, as that would generate huge inconsistencies.

These colours must yet again be well documented. To do that, I create colour symbols in Sketch.


The most important thing when talking about typography is to establish hierarchy. As I mentioned before, the base grid must be the element that defines how to deal with typography scales. Once we have defined our grid — let’s say 8pt with 4pt for text — it’s time to generate the different sizes that are going to be available. To do that, I create text styles in Sketch that are based on three values:

➡️ The usage (heading or body)
➡️ The text alignment
➡️ The text colour

So the final structure of those styles might look similar to these:

➡️ H1 / Center / Green / lightGreen
➡️ Body / Left / Greyscale / Black

All these meticulously organised colours and typestyles set the foundations of the systematic approach to digital product design.

3.1.3 Tokens

The next step in the scale is the tokens. I consider tokens to be what Brad Frost calls atoms in his atomic approach. Tokens are the basic building blocks of the system and cannot be broken down without losing their meaning. This category includes simple things like buttons, inputs or single checkboxes, for example.

Tokens must be meticulously documented as they shouldn’t change very often. To do that, I create symbols following a similar structure to the styles. The symbols of a button, for instance, could look like:

➡️ Tokens / Button / Primary / Text
➡️ Tokens / Button / Primary / Icon
➡️ Tokens / Button / Secondary / Text
➡️ Tokens / Button / Secondary / Icon

3.1.4 Components

From tokens, I jump directly to components, which are basically assemblies of tokens that work together as one and with a goal. These elements go from simple forms to more complex cards or filtering lists. Components are a bit more likely to change based on the implementation of new features, but thanks to Styles and Tokens, any change performed should ensure great consistency. The symbols of these components could look like:

➡️ Components / Card / Product
➡️ Components / Filtering / Search

3.1.5 Templates

The last step of this systemic approach is templates. Templates are a sum of tokens and components that build a distinctive part of our product. We could say that a header with the logo, a search bar and a few links is a template. Or the sum of components listing different filters with a button to expand them, and all the checkboxes for individual filters is also a template.

3.2 Design System Manager

To manage all these symbols for styles, tokens, components and templates we need to create a library, and that’s pretty easy to do in Sketch or Figma.

The complexity comes when we need to deliver this to all the stakeholders involved, and for that, I like to use the Design System Manager from InVision. With the DSM you make the library accessible for every member of the project where all styles, tokens, components and templates are listed with the exact same naming convention you established in your Sketch file. This guarantees that everyone will speak the same language when referring to a specific component.

Another reason why I like to use it is that you can write notes, and those are really handy to specify the use and behaviour of specific elements. For example, in a checkbox token, you can write down a note explaining the behaviour, when to use it and how.

One more cool option about the DSM is also the possibility to add the code snippet for the element that was documented. That transforms the library into a collaborative and bidirectional source of information, from design to tech and vice-versa.

4. Follow Up

I have experience conducting qualitative testing, using Hotjar or receiving direct feedback from customers. In my previous experiences, all the quantitative testing was always performed by the product manager/owner and shared later with the product team.

4.1 Quantitative Testing

Quantitative metrics try to define all the “how many”. How many people clicked? How many people bought? How many people completed the process? How many left the site right away?‌

Some of these tests are based on quantitative data: ‌

Task-Completion Times

Conducted by providing a specific task to the user and tracking how long it takes for them to complete it. The numbers are written down and analysed to see what the average is. Additionally, a qualitative test can be performed to try to identify the elements that slow down or confuse the users.‌

A/B Testing and Conversion Rates

A/B testing (or A/B/C/D… testing) is a technique that helps us determine which of the two, three, four or infinite versions that we want to test performs better. I’ve worked at places where we were using this mainly to determine which version had a better conversion rate.‌

The formula to calculate conversion rate takes into account conversions (sales) and visitors.

Conversion Rate = Number of Conversions / Number of Visitors

So if you have 25 conversions and 100 visitors, your conversion rate would be 25%.

My concern with this kind of testing is that it becomes really hard to determine the causality of the bad or good performance of the versions. Is it just a design change? User behaviour? Time of the day when they were visiting the site? Real interest in the product?‌

I’m not saying this is not useful, but it has to be carefully performed to understand the reasons behind the successes or failures and not be used to drive the product vision. And please, if you appreciate your identity (or the one that you are working with) avoid testing button colours, different typographies, and stuff that should be defined by who you are.

Must-Haves for a Quantitative Test

➡️ Many participants
➡️ Sharing impressions is not needed
➡️ Be well-defined (hypothesis) and strictly controlled‌


These can be really good numbers to have, but as numbers, they are hard to understand without a context. It’s very important to understand that the data we collect might not always be accurate, so we need to consider the costs of acting on data that is incorrect.‌

I’m not a crazy expert in quantitative testing. If you are not one of them either, just team up with someone that can do it thoroughly and you might find really interesting insights in your journey together.

4.2 Qualitative Testing

Qualitative data offers a direct assessment of the usability of a system: this is about observing users struggle with specific UI elements or flows and inferring which aspects of the design are problematic and which work well.‌

Heat Maps or Eye-tracking

Heat maps are a data analysis tool that uses colour to highlight the parts of your site that get attention and user interaction. Heat maps are commonly used together with mouse tracking and scrolling behaviour. Here, I definitely recommend taking a look at Hotjar‌

Eye-tracking is a rather new technique that compliments heat maps and mouse behaviour. This technique consists of a technology that makes it possible for us to know where the user is looking. This can be used to know if the hierarchy of your product is working and how the user really behaves.‌

System Usability Scale

This is similar to a satisfaction scale. What we do here is to list several statements and ask the user about their level of agreement with the affirmation. At the bottom of the document, you can see how many points were attributed to positive or negative statements.

Focus Group or Direct Feedback

Direct feedback has always been provided to me in single sessions. I have experience in meeting with potential clients or customers (usually 1 or 2 people in the room). These sessions always start with a small introduction about what we are seeing (prototypes, wireframes or final designs) and the definition of the goal or task that they need to complete.‌

Here, instead of measuring the time that it takes for them to finish the task, we measure the pains and smooth moments that they go through while testing the product. The most important thing is to let them speak, and interrupt or ask them questions only when necessary, without trying to influence their input. This is a really useful way to get quality insights about UI components, possible use cases and user flows.‌

Must-Haves for a Qualitative Test

➡️ Few participants
➡️ Share impressions and think-aloud
➡️ Flexible conditions that can be adjusted according to the team’s needs


I appreciate way more the value of qualitative data, even though both are really useful to bring user insights to our decisions.‌

I guess you might be asking yourself if the anecdotal nature of qualitative data is good enough. Good question, I don’t know either. It surely depends on your goals. Are you looking for quality feedback or just quantity? Does quantity bring quality decisions? It depends. Here I’m gonna hold myself back and just quote something Seth Godin wrote on his blog in 2016.

They got us hooked on data. Advertisers want more data. Direct marketers want more data. Who saw it? Who clicked? What percentage? What’s trending? What’s yielding?

But there’s one group that doesn’t need more data…

Anyone who’s making a long-term commitment. Anyone who seeks to make art, to make a difference, to challenge the status quo.

Because when you’re chasing that sort of change, data is the cudgel your enemies will use to push you to conform.

Data paves the road to the bottom. It is the lazy way to figure out what to do next. It’s obsessed with the short-term.

Data gets us the Kardashians.‌