Search results for ''

Effective management of font licenses is crucial for ensuring compliance and protecting both Infinum and its clients from legal issues. It is important to understand the following:

Licenses are embedded in the font files and can be easily checked by type foundries.

License type

Desktop License: Allows you to install the font on a computer and use it in desktop applications such as Figma or Pages to create documents or designs. Desktop licenses are often tied to the number of users.

Webfont License: Permits you to embed the font into websites using CSS. Many webfont licenses are priced based on the number of page views the site receives each month. The license should cover the site’s traffic, meaning if the site grows, it will have to be upgraded.

App License: Needed for embedding fonts in mobile apps or software. Usually, one license per app and/or software is needed, and the license coverage should reflect the anticipated total monthly active users of this specific app or software. Depending on the type foundry, web apps sometimes fall under app licenses, not webfont licenses.

Commercial vs. Non-commercial: Non-commercial use includes personal projects (concept and visual exercises, hobbies, Dribbble shots, etc.), while commercial usage includes profit-driven activities, generally requiring a commercial license to comply with legal standards. Not all open-source fonts are free for commercial use, so always check the licensing.

Modifications: Some licenses prohibit altering the font file itself, but they may allow modifications to the typography in design.

Duration of License: Most font licenses are perpetual, but some might be time-limited.

All in all, always read the fine print. Licensing agreements can vary from type foundry to type foundry, even from font to font within the same foundry.

When Clients Provide Fonts from Existing Branding

When the client has an existing brand, you will encounter two situations:

Custom fonts – created for the client under which they have complete license ownership,

Licensed fonts – acquired from a type foundry.

In both cases—custom-made or licensed fonts—the client must provide the correct license. If the client is unsure about licensing, our team should guide them in obtaining the appropriate license. PMs will collect documentation from the client to confirm they have the necessary font licenses.

Do not install, use, or forward any font files until they are officially provided by the client or a PM. In the meantime, use a commercially free open-source placeholder font and clearly indicate in the Figma file and any related tasks or emails that the proper license and font files are pending, along with any other outstanding decisions or items.

Once obtained, PMs will store all licensing documentation and communications about font usage in the project’s Google Drive folder. The font files should also be archived on Drive to ensure we use only the files provided by the client and not from a third party.

Once the fonts are received, PMs must maintain a record of all licensing documentation and communications about font usage in the project's Google Drive folder. This is essential for managing audits or disputes. Additionally, the font files should be archived in the Drive to ensure that we are using only the files provided by the client and avoiding any third-party sources.

Upon offboarding, remove the font from your computer after confirming it's stored in the project's Drive folder. This ensures compliance, proper license management, and a smooth transition for the next designer.

When Joining an Ongoing Project

If the previous designer has rightfully obtained the font files, it is safe to transfer them to you. However, if you’re unsure where the file came from, consult with the Project Manager to confirm whether the client holds the appropriate license and files. Do not download or install any fonts if you don’t have a proper license.

When Infinum Provides Branding Services, Including Font Selection

When suggesting fonts for a new branding, use:

Test or trial fonts from type foundries (e.g., HotType test fonts)

Open-source fonts - Often the preferred option for secondary font, smaller-scale projects, and back-office solutions. Keep in mind not all fonts are free for commercial use - some can be used only for non-commercial purposes, so check the licensing. Some well-regarded open-source font libraries are Google Fonts, Open Foundry, and Fontshare.

Adobe Fonts - an online service included in Adobe CreativeCloud subscriptions that offers a wide range of fonts. Those with a CC license can access and activate fonts from this extensive library on their computers. Once the font is decided upon, a proper license needs to be purchased.

After selecting a font, identify the appropriate license and assist the client with the purchase. Highlight the importance of proper font licensing and the consequences of using unlicensed fonts. The client must purchase their own font licenses, as the license holder is the one who makes the purchase. If we buy the license, it will belong to us, not the client.

Offer guidance on purchasing and managing licenses if clients decide to handle this independently in the future. Make sure they understand their responsibilities for ongoing license management, including:

Scalability: Determine if the license needs to be upgraded as the user base or company grows.

Renewal: Clarify whether the license is perpetual or requires periodic renewal.

Communicate the final information regarding licenses in written form, ideally through email. Keep the PM in the CC.

Font licenses quarterly check

Every quarter, the designer responsible for font licenses reviews the Projects Overview table (🔒Internal use) for any new projects. If new projects are identified, they update the Font licenses Google Sheet (🔒Internal use) with the relevant project information and create a new sub-task in this Productive task (🔒Internal use).

If Infinum is not handling the design work for a project, the PM is assigned to obtain the font and license information. Each person tasked with this needs to update the Font licenses table with all relevant details. Although this information typically remains unchanged from quarter to quarter, any rebranding or design changes affecting the fonts used must be documented.

Documenting typography and license information

For projects where Infinum handles the design work, the primary designer must document all typography and licensing information within the design system. This documentation should specify the type of license required (Desktop, Webfont, or App License).

If the fonts used on the project require a license, include a link to a Google Drive folder containing the license and font files. For fonts needing a desktop license, check with the PM before installing the font files to ensure the current license permits it.

Be safe out there

Proper font licensing is not only a legal requirement but also a critical aspect of professional reputation and client relationships. By adhering to these guidelines, Infinum ensures that all font usage in client projects is legally compliant and ethically managed.

Guidelines for using stock photos in client work

When creating design proposals that require placeholder images, you may use:

Images already available on the client's websites and social media, ensuring they hold the rights and proper licenses to those assets,

Free watermarked images from paid services such as Shutterstock, or

Photos from publicly available sources such as Unsplash, Pexels, or similar platforms.

Please note that purchasing photos via the Infinum account is not permitted if these photos are intended for definitive use in client applications or websites. If we make the purchase, we will own the license, not the client. The license is held by the purchaser, plain and simple.

If you decide to use stock photos for a client project, follow these steps to ensure proper licensing:

Obtain client approval for the specific photo(s) that will be used.

Determine the necessary license type for the intended use (e.g., web, mobile, print).

Assist clients in setting up their own stock service account.

Guide clients through the process of purchasing and downloading the licensed photos.

Guidelines for using Shutterstock for internal projects

You can use Shutterstock photos for Infinum Web, internal projects, or any promotional materials related to Infinum, provided the images are properly licensed. Please contact the Marketing team to purchase the necessary licenses for the images you wish to use.

Free services

Unsplash

Moose

Pexels

Pexels Videos

Burst by Shopify

Pixabay

Paid services

Shutterstock

500px

Everyone can get a little lost or stuck sometimes, and it can make an impact on your workflow. If (actually when) that happens - fear not; try some of the creativity/productivity block-handling methods and kickstart your process again.

💬 Critique

“A design critique refers to analyzing the design and giving feedback on whether it meets its objectives.”

Giving each other helpful feedback is one of the most important parts of being a team. Critique usually represents a group conversation with the ultimate goal of improving the design. It is not merely judging a design; instead, it's giving constructive feedback and improvement ideas for the general betterment of the final product.

Bad feedback should be avoided, for example:

“This is bad.” That is blunt negative feedback. You aren’t given any insight into how you could improve. This kind of feedback only serves to demoralize.

“This is good.” That is blunt positive feedback. You aren’t given any insight into what about the thing you did was good, so you can’t learn from it. You feel good, but on the whole, it’s not super useful.

Good feedback should be relevant, timely, constructive, and concise:

“This isn’t great because…” “This could be better if…” That is sharp negative feedback. It explains why something isn’t great and how it could be better. That makes the feedback actionable. Note that this doesn’t mean you’re “solutioning” for the presenter (which is almost always counter-productive in reviews)—you could be giving them potential areas to explore.

“This is awesome because…” That is sharp positive feedback. It lets you feel good while learning what to keep or continue doing.

When you have a dilemma that can be explained briefly and solved without hands-on work, you can always turn to your team to hear some opinions. Write up a brief explanation of the task (or project) and what you're unsure of, and take a screenshot. Post it to the #team-design-feedback channel, and the team will work their magic.

If you have a more complex problem that requires hands-on designing and iterating, gather a couple of brains and initiate a brainstorming session.

🏓 Ping-pong

Sometimes, you get to a point where you realize you are nudging elements around on screen for an hour, only to find yourself right back where you started. It can be a pain point in the design process, but not an unusual one. Most of the time, the problem lies in the fact that you have been looking at the same design/project/task for too long and got stuck in finding the right solution for the issue you are facing.

The rules are simple: once you realize you are stuck, pass your design along to a colleague who can help. Onboard them to the task (or project) briefly and explain the problem you are currently facing, link your Figma screen, and let them work their magic. A fresh pair of eyes will find some outside-of-the-box solution quite fast and efficiently, or at least point you in the right direction.

Track time spent on working up a solution for a buddy on the project (check with the PM), or (if the project has a tight budget) on Team: Design → Team activities.

📚 Recommended reading

Design Critiques: Encourage a Positive Culture to Improve Products

Dealing with creative block – 10 strategies to get back on track

A brief guide to design feedback

For a good workflow in a project, it is essential to have a feedback process and a basic set of rules according to which the whole project team will behave.

First, select one person on the client team, a product owner or a decision-maker, to synthesize and deliver all client feedback so that you’re not getting it in from multiple people.

Everyone on your team should know where you are in the cycle of revisions, what is the time dedicated for iterations/change requests and when it’s the last call for final feedback.

Feedback Instructions

Whenever you request feedback from clients, you can provide them with these basic instructions:

While reviewing this proposal, please focus on reviewing [UX, UI, animations, flows, whatever you worked on at this phase]. If you have additional comments regarding any other phases, please leave it in the last section of the feedback.

While reviewing this proposal, please start by returning to the original goal to help filter the feedback. It will also help us avoid the scope creep.

Please make sure to deliver all feedback in one place.

If you are the decision-maker, please leave comments in the Figma file, on the appropriate screen.

If many stakeholders are involved in giving feedback, please synthesize it, so we don't need to resolve the conflicting opinions. Also, please write down the complete feedback in a document or in an e-mail to make sure we can reference it later.

Translate the feedback into the language of design. For example, if a site feels too “crowded” to you, think about what does that mean to a designer? Are you concerned about color, photos or illustrations? Are you worried about the lack of space? Write the feedback as direct as possible.

Provide timely feedback by baking it into your schedule and internal process. Plan time after presentations to synthesize and swiftly deliver any additional feedback. Our workflow is highly dependable on your feedback delivery.

Requesting feedback in a workshop or at a meeting

If you are presenting design proposals at a workshop or a stakeholders’ meeting, what you need to get is objective feedback on your work. To achieve that, always include a few feedback exercises after the design presentation.

1. Three gut-feeling adjectives

Let the stakeholders write down what attributes suit a particular design proposal best. They can choose attributes from a presentation slide you will display on the screen.

2. One good thing and the reason why

The stakeholders need to write down what they liked about a specific proposal and describe why they loved it.

3. One bad thing and the reason why

The stakeholders need to write down what they didn’t like about a specific proposal and describe why they didn’t like it.

4. Overall grade

The stakeholders need to rate a proposal on a scale to state their overall impression.

5. Questions (for later)

The stakeholders need to write down any additional questions and concerns regarding specific proposals to discuss with the team after you've finished with the exercise.

Also, please provide the stakeholders with these instructions for giving silent feedback:

Don't comment aloud, so you don't influence others

Be honest and direct

Don’t peek what others wrote down

Write your questions regarding proposals as they pop up in your head

It will help us and the clients get an objective, non-influenced feedback on the proposals, and better instructions for the next steps.

📚 Recommended reading

A brief guide to design feedback

Design documentation is what a brand book or a graphic standard manual is for graphic design projects – but for your website or app.

We use design documentation to keep the UI consistent, to quickly onboard new designers or team members and to ease the UI setup for developers.

A web or app design documentation may include:

1. Styleguide

color styles

typography styles

effect styles (shadows, blurs, etc.)

grids and layouts

standard spacing elements

brand assets

communication tone&voice

icon set

photos

guidelines on using these elements

categorized UI components

2. Component library

categorized UI components

component specification, including variants and states (default, hover, focused, empty, loading, error, etc.)

3. Pattern library

categorized patterns

pattern specifications, usage guidelines, and examples of how to use them

When to document?

In short – always. But how you approach the documentation process will largely depend on the project size, complexity and, sometimes – timelines. Smaller, shorter projects may not require more than a concise set of guidelines, while complex, collaborative projects need more detailed and structured documentation to ensure consistency and quality in design.

Design pattern documentation, in particular, is useful for larger projects that involve multiple designers and developers, as it helps to ensure that everyone is on the same page throughout the project lifecycle. It can also help with projects that are intended to evolve, as it provides a solid foundation of building blocks for future design decisions and ensures consistency.

How to document?

There is no one-size-fits-all approach to design documentation. However, there are some best practices and general guidelines that you could try to follow.

For example, if you are working on a short, in-and-out project, let’s say – a web one-pager, chances are that you don’t need a particularly detailed design documentation. What you might do instead:

Create a single UI design file in Figma

Include UI of all screens in their various states (empty, loading, error, etc.)

Screens linked with arrows: Use arrows or connectors to indicate the flow between screens, clarifying which components lead to different parts of the application.

Add a separate page for your basic styleguide (e.g. colors, typography, grids and spacing, etc)

Add a separate page for your main components, with basic specifications, such as component states

If needed, add small notes for developers as a reminder of how a specific pattern is meant to behave and interact

On the other hand, if you are just now building a foundation of what promises to be a complex, long-term project, with a potential to evolve even cross-platform, this is what you might want to do:

Create a Figma project

Create a separate file for UI design

Create a separate file for your styleguide, as a Figma project library

Create a separate file for your components and patterns, as a Figma project library

Map out and design all component variants

Map out all distinct design patterns

Add detailed specifications and guidelines for all design patterns

Show examples of pattern usage

Provide specifications for animations and transitions

Create a separate file for interactive prototypes

Useful links

Here are some best practice examples to get you started:

Material Design 3 - Web guidelines

Material Design 3 - Figma Design Kit

Ant Design System

IBM Carbon Design System

Shopify Polaris Design System

Design systems publication by Figma

Designing, but with words

A UX writer’s job is to write every piece of text (also called “copy”) in the app or the website in a human-friendly and conversational way. Combined with an appealing design, it provides a delightful and seamless experience to users. Result: achieving the client’s business goals.

“You’re not the user.” - that’s the mantra of a good UX writer. They do user research (usually with a UX researcher in the team) and research the product (e.g., its revenue model and competitors). UX writers need to know the users’ context, how users got to a specific screen, what they’ve seen already, which options we can give users, and which option we want them to choose.

How to recognize a good UX copy? It’s:

Clear: no technical or business jargon, easy to understand for everyone.

Concise: people mostly scan the text and don’t read it, so the copy needs to be as short as possible.

Useful: it provides critical information, explains the context, or provides a way out.

Getting there

Knowing both users, product, and the client doesn’t happen overnight. In most cases, it starts during the discovery workshop. This is where we get to know the client, discuss their overall communication and set the product’s tone and voice (we’ll get to Tone and voice, don’t worry).

Usually, the next step is creating black and white wireframes. UX writer creates copy for these screens, and this is the first road-test of tone and voice. Writing the copy this early in design aligns both design and client’s team around the final product’s look and feel.

We use wireframes for usability testing. That's how we get authentic feedback to copy from real-life users and catch any problem early on, saving our clients time and money. Using this feedback, we make final tweaks and finish the whole UI.

An example of user feedback to our copy. We aimed for a slightly enthusiastic and neutral on funny - serious dimension. It seems we got it right.

After the product’s launch, the UX writer is not done. When new features and screens are added, they make sure the copy is consistent with previous screens while still doing its job, e.g., getting people to sign up for a free trial.

Tone and voice

Tone and voice define how a digital product talks about topics of interest and how it addresses users. Think about how your mobile banking “talks” differently than Spotify or Wolt.

Usually, we use Nielsen Norman’s framework of digital tone and voice. It’s backed by research, and with four main dimensions, it’s easy to understand and define. The tone and voice become part of the client’s brand book, making it easier to have consistent digital communication on all channels.

Funny vs. Serious: Varies from a joke on every corner to no humor at all.

Casual vs. Formal: Varies from very conversational and laid-back to something you would find in a 19th-century English novel.

Irreverent vs. Respectful: The respectfulness of the approach to the topic, not the reader. Varies from seeing the topic as totally irrelevant to painting it as the most crucial thing in the world.

Enthusiastic vs. Matter-of-fact: Varies from very hyped and showing both positive and negative emotions to the “cold hard facts only” approach.

We already have a name for this: copywriting?

UX writing is an easy-going cousin of copywriting. Where copywriting tries to grab your attention, UX writing assumes it’s got it. Where copywriting is flashy and over the top, UX writing is helpful and doesn’t get in your way. Where copywriting tries to push you into something, UX writing removes the friction of you getting somewhere.

Still, there are a lot of similarities between them. Both try to be motivating and engaging; they try to create a positive brand experience and aim at being conversational to facilitate users’ (or readers’) understanding and emotional involvement.

Tips

Front-load your content: people scan each row’s beginning, so make sure the first words carry the most critical part of your message.

Give a reason why: explain to people why you are asking them to do something. Adding a “because” is very powerful; just look at this research.

Be a copycat: UX writing is not about being unique but being understood. If everyone is using one word to mean something, use it that way also.

No dead-ends: check all use cases, especially edge ones, and brainstorm with developers how you could keep users flowing instead of leaving them stuck.

Learn six persuasion principles: they’ll give your creativity a framework and make your writing more impactful. Start with this video.

UX writing in action

First, let’s start with something we’ve done for Productive, our sister company. When we did Tone and voice for them, we also set a few do and don’t examples. This was helpful in the first wave of writing copy for their app and helps their team keep communication consistent afterward.

Now, let’s explore some examples of copy for two of our clients. Here you’ll see the state “before” and “after.” “Before” was our first draft of the text, and then we iterated on it, trying to hit the right tone and voice and achieve business goals.

📗 Case 1

Users have come to a video streaming platform to watch scientific lectures and live panels. In some cases, the video doesn’t load properly for users from mainland China. They can switch to alternative servers, but that’s more costly to our client.

Doesn’t label people - Are you from China vs. Visiting from Mainland China

Says it’s the system’s fault, not users - can’t see this video vs. video isn’t starting

Explains what happens next - click here vs. switch streaming source

📙 Case 2

Users are using this app to connect with potential customers and business partners. Our client provides this networking feature to paying users, while guest users can only see basic info about other people.

Talks about the benefit, not feature: use the Networking feature vs. Don’t miss out on opportunities

Shows exclusivity: none vs. only users with official accounts

📚 Recommended reading

The most important part of your design is actually the text

Did you ever...

... felt like you were doing something just because it’s expected of you?

... spent many hours on a task but questioned whether it was worth it?

... realize that there was a misunderstanding in initial requirements?

We consistently strive for excellence in our design work, be it a well-documented design system, or flows in which we cover all possible outcomes, not just the happy ones. However, obstacles such as budget limitations, time constraints, and plan changes can sometimes interfere with our goals.

In those situations, it is important to remember that although we are designers, we are not in the business of designing. We're in the business of building digital products. Designing them involves managing technical limitations, user requirements, and business requirements. It's important to keep these aspects in balance. If one dominates, the project may run out of budget and become unprofitable.

Products we create should be feasible, useful, and profitable. We must be flexible and adapt to the project's specific needs. Our focus should be on solving project issues, not just design problems. To do that, we need to apply value-focused thinking.

Value-focused thinking is designed to focus the decision maker on the essential activities that must occur prior to “solving a decision problem.” Value-focused thinking helps uncover hidden objectives and leads to more productive information collection. It can improve communication among parties concerned about a decision, facilitate involvement of multiple stakeholders, and enhance the coordination of interconnected decisions.

In product design, value focused approach can be applied to three levels:

Feature level

Technical level

Process level

Feature level

A team working on a recipe app with a comment feature was tasked by the product owner to design a user flow for individuals banned due to inappropriate behavior. The team invested significant effort in creating a polished experience for banned users. However, they later realized this added little value to the broader user community or the business. In the end, thousands of euros were spent on an overly refined solution when a simpler banning process would have been more effective.

Lesson learned: Consider the business value of the features and users you are designing for. Always consider efforts to be proportional to the value.

Technical level

Our task was to improve the experience of the existing back-office dashboard for the hotel asset management app. The app had a very outdated UI and messy design file.
In this case, we created the new file using the Ant component library, which closely resembled the app’s existing components. This approach allowed us to maintain focus on UX and save some valuable time.

Lesson learned: Think about how to efficiently solve the project problem. Not a design problem.

Process level

We were in the initial phase of defining an IoT app. The client had a tight budget and deadline, but we needed to do thorough design and usability testing. We decided to rush the design, focus only on happy flows, do rudimentary UI, and skip the design system to test the value proposition early.

Lesson learned: Be flexible, find where the biggest value is, and invest time in that.

How to achieve and nurture this mindset?

Stay flexible: Adapt to changing circumstances and requirements.

Be proactive: Anticipate potential problems and propose solutions ahead of time

Focus on the benefits: Consider the end value of each design decision you make

Think critically: Don’t follow design process blindly, question and refine them when needed

Adjust level of detail: Understanding the project scope and goals helps in deciding how much detail to go into

Communicate transparently: Maintain open, honest communication with the client

Challenge the client when necessary: Don’t blindly listen to the client, it’s okay to respectfully oppose when their ideas might not align with the project’s goals

Collaborate effectively: Communicate with your project team, design colleagues and team leads to share insights and align efforts

When making decisions, remember to consider important product aspects. This involves understanding the technical limitations, what the users need from the product, and what goals are required for business success. By thinking about these things, you can make decisions that meet both user and business expectations.

Once we have the whole app or website structure in place, it's time to use some color, photos, icons, illustrations, and beautiful typography.

If you don't know at the moment what these elements are, meaning there is no branding for the app or website, you need to define the whole visual identity before digging into UI design details.

Through UI design, our task is to:

make the user experience easy, enjoyable and delightful

make the app recognizable and stand out from other apps

make the app communicate the same brand values as the company does

achieve consistency throughout the features and mobile platforms

Iterating on the UI

Before you dig into the UI design of every screen, make as many versions as possible to find the right visual fit. Present 2 (3 at most) polished versions to the client. You don't want to confuse them with too many ideas and variations. You are the expert, and you need to show your skills and expertise in the best light.

Testing the UI with users

If you're working on a project highly influenced by user opinion, you can use the desirability testing method to ask the users which version of the UI design is better. Desirability testing helps us get objective feedback from users. We usually show them 2-3 versions of the UI and ask them to choose terms from the list of adjectives that describe the version best. The proposal which overlaps the most with the objectives we have set for UI design wins.

Finalizing the UI design

While approaching the end of the design phase, make sure you have:

a styleguide with colors, typography, brand elements and components

all the screens set in color and typography styles organized in components

screens organized in flows separated into different pages

archive page or duplicated file with old iterations and unused versions

comments with specific behavior and flow descriptions for developers

App Store and Play Store icons, screenshots, and featured graphics for mobile apps

Complete UI stack (↓) of the screens and components

Type foundries

Paid foundries

Type Foundry Index

Fonts by Hoefler&Co.

Type Network

Typotheque

Klim Type Foundry

Darden Studio

Colophon Foundry

Order

Free foundries

Google Fonts

Velvetyne

Fontain

Use & Modify

Fontshare

fontfabric

Free Faces

Useful typography links

Fonts In Use

Fonts in the Wild

Typographica

Typewolf

WhatFont or Font Ninja

Color palettes

pigment.shapefactory.co

vanschneider.com/colors

artsexperiments.withgoogle.com/artpalette

Brand logos

Simple Icons

World vector logo

Icons

Free icons (No attribution required)

These icon sets are free to use and are open-source. You can use them freely in your projects without worrying about licensing fees and restrictions. There is no limit on the number of icons you can use per project. They can be used across various platforms, including mobile and web apps, WordPress sites, and in webpage builders. While attribution is appreciated, it is not required.

Material Symbols & Icons - Gooogle Fonts

Feather icons

CSS Symbols

Mono Icons

Ikonate

Free icons (Attribution required)

These icon sets are also free to use and are open-source, meaning that you can use, modify and distribute them freely, provided you include the original copyright and license notices in your project. There is no limit on the number of icons you can use per project. They can be used across various platforms, including mobile and web apps, WordPress sites, and in webpage builders.

Tabler icons

Phosphor Icons

Atlas Icons

Freemium (Attribution required)

These icon sets are available in both free and paid versions. In most cases, the free version requires attribution, so it's recommended to include the original copyright and license notices in your project, just in case.

Streamline

Streamline's licensing terms permit usage of free icons in unlimited projects, both personal and commercial, including mobile and web apps. However, free license prohibits using the icons as assets in applications like webpage builders or 'Canva-style' apps that allow users to integrate the icons into their designs. That includes our WordPress projects as well. It is also important to notice that some free icon sets are open-source and some are not. Open-source sets permit you to share and adapt the icons for any purpose provided that appropriate credit is given and a link to their website is included.

📚 Recommended reading

Handbook: Learning materials/UI Patterns + Inspiration

How to fix a bad user interface

Visibility of System Status

Wireframes are screens that represent a simplified skeleton of an app or website.

These screens serve as a blueprint for future UI design and development.

We usually design wireframes before any visual design to keep the focus on the flow, information, and usability of the app or website. Only when we have smoothed out all the issues in these areas can we continue working on UI design, motion, and transitions.

Wireframes help us with:

get feedback from clients and developers before we're deep into the final stages of design

figure out any technical restrictions and staying within the scope for development

getting feedback from the clients and project team.

Wireframes are also useful for creating quick prototypes, which we often use during usability testing with users.

It's not necessary to design all the screen states during the wireframe phase. It's just important to get the structure and the flows right.

Please use real data and information similar to the final content; don't use Lorem Ipsum or other dummy text.

Prototypes serve as a demo of connected screens so that the team, stakeholders or users (during usability testing) have a clear understanding of the flows, since flows are hard to explain in words.

If you're designing in Figma, it's best to keep the prototype there. We won't get too technical as tools often change, so check out these resources:

Figma's prototyping resources

Interactions are an integral part of the user experience. Make sure that:

Tap zones need to be large enough.

Modals appear from the bottom and you dismiss them downwards.

The screens behave according to navigation and flow placement (previous, next) (Material's navigation transitions).

The dialogs have a transparent overlay behind them and can be dismissed anywhere outside of the dialog box.

When prototyping, take into account additional UI elements that are hardware and/or software dependent. For example, someone viewing a website on the desktop will have an OS bar at the top (or bottom) and browser UI elements at the top. Designing at the default frame height 1440px differs from the real experience so keep that in mind.

Figma's interface already takes up enough space at the top when viewing a website on a desktop. Still, for mobile, we need to mock extra OS and browser interface elements to have a more natural and realistic preview.

Prototype instructions

When sharing the prototype with clients, ensure they understand how to navigate it. Here is everything you need to cover so they have a good viewing experience.

The prototype is a clickable Figma file that we use to showcase interactions on the screens still in design.

Getting started with the prototype

In the sidebar (A), located on the left side of the screen, you can find all prototype links – different
design flows (e.g. Login flow, Registration flow, etc.) you can access in this file. Clicking on those
links switches to the starting point of the selected flow.
You can hide or show the sidebar by clicking the sidebar icon on the top (B).
By pressing the “Options” dropdown (C) you can:

change the preview options (if the prototype is cut off or isn’t fitting your screen as intended)

hide/show the top toolbar

show/hide comments

Navigating through the screens

Interact with hotspots (blue areas that appear on the screen when you click) to move to the next
screen/page. You can also use arrow keys to move from one screen to another or arrows on the
bottom of the screen (D).
Pressing “R” key on your keyboard returns you to the starting point of the prototype flow.

Leaving feedback

Press “C” on your keyboard or click the comment icon on the top (E) to open the comment dialog.
You can click anywhere on the screen to leave feedback.

Viewing prototype on mobile

To view the prototype on your mobile device you will need a Figma account. It is recommended that you download the Figma mobile app (iOS version or Android version) to have a better experience with viewing the prototype.

Once you open the prototype, long pressing with two fingers opens the prototype menu where you can control the prototype. Here you can find the options to switch to another prototype flow, restart the prototype and go to the starting point of the prototype flow, and leave feedback using comments.

Onboarding clients

To avoid worrying if your clients memorized everything you explained, send them these instructions (which you can find on Google Drive) along with your prototype. You can adjust the instructions in the Pages document and export it as PDF before sending it off.

Recommended reading

NNG: UX Prototypes - Low Fidelity vs. High Fidelity

Figma: 5 ways to improve your prototyping workflow

Information architecture is a part of the design process where we define the complete screen flow and necessary information for the new app or website.

It helps us keep the app simple and structured so that users can navigate through different features easily. Having a defined information architecture before designing screens helps us stay focused on the screen content and elements.

We usually keep system attributes and flowcharts in the same Figma file as the wireframes, for reference.

System attributes

One of the main benefits of defining information architecture is to have a complete list of necessary information which needs to be visible in a single feature or on a screen.

A list of attributes for the Instagram profile feature can include, for example:

first name

last name

Instagram handle

profile photo

biography text

number of followers

number of following

edit profile action

my posts

tagged photos

The attributes help us remember all the relevant information when we get to design a profile screen.

Flowchart

A flowchart is a flow diagram that represents the complete map of an app or a website. That means it precisely shows how screens in the flow are connected.

We usually create a flowchart for the features based on the previous customer journey map.

You can draw flowcharts in Figma with the help of the Autoflow plugin.

Each square in a flowchart represents one screen of an app or a website.

You can also have more flowcharts for different use cases. For example, a first-time user login will have a different flow than a regular user login.

Flowchart usually helps us sync with the backend team, clients, and developers on how to set up the whole system. It is also a good time for them to ask if we can organize or connect some features differently.

Since the introduction of smartphones, motion design has become a vital UX tool. When utilized right, it makes using technology feel natural, responsive, and more enjoyable.

Adding motion to user interfaces means doing a lot more than decorating. Animation is a functional element used for giving feedback to an action and helping users understand the app's hierarchy and flow of information.

When to use motion

Before adding animations to a web page or app, ensure that their goal and purpose are well-defined. When considering an animation, contemplate the following questions:

Where would the user’s attention otherwise be focused at the time when the animation occurs?

How frequently will one user encounter it during one session?

Is it triggered directly by a user’s action or indirectly (upon page load, while scrolling, or by some other unrelated activity)?

Is the goal to:

attract users’ attention, so they notice something and act on immediately?

show continuity in a transition between the states of an object?

indicate a relationship between objects that are already in the user’s focus of attention?

Once you worked out the purpose, think about how to visually approach solving the problem by using motion:

Feedback - Provide instant and relevant feedback about a completed action and keep the user enlightened about what is happening..

State-change - Draw attention to and explain changes on the page. Changes in the state of an element, revealing and hiding of content, or shifts to another area of content are all common areas for transitional animations. Communicate state changes that are not triggered by users’ actions.

Spatial and navigation metaphors - Signal to users the direction in which they are moving within a process or hierarchy; this supplemental cue can make navigation through a complex IA more intuitive and understandable.

As a signifier - Help users understand how to interact with UI elements. The direction (or other attributes) of the motion signifies the type of acceptable actions. For example, a card that expands from the bottom of the screen towards the top signals to the user that it can be closed by pulling down. A new card that comes from the right of the screen signals that it can be closed by swiping it to the right.

Animation types

Transitions

Motion design comes in to help users understand the app flow between screens, making the navigation easier. Another way to use motion design in transitions is during loading times. Why not shorten the waiting time with an interesting animation? Animations help hold users' focus while the device is downloading the necessary data.

Micro-interactions

Micro-interactions are events used to create an engaging moment with the user. Most of the time, the animation starts with a trigger (user action) that causes a reaction, letting the user know what’s happening, making the navigation inside an app or a website easier. We can divide micro-interactions into four steps:

1. Triggers — Initiates a micro-interaction

User-initiated trigger — the user has to initiate an action (e.g. buttons)

System-initiated trigger — software detects certain qualifications are being met and initiates an action (e.g. notifications)

2. Rules - what happens once a micro-interaction is triggered

What happens when the user clicks this button? Are they directed to a new page? Will it add a product into their shopping cart? The same goes for system-initiated triggers.

3. Feedback - Lets people know what’s happening.

Anything a user sees, hears, or feels while a micro-interaction is happening is feedback.

4. Loops and Modes - determine the meta-rules of the micro-interaction.

What happens to a micro-interaction when conditions change?

Micro-interactions have to be unobtrusive, brief and subtle.

Superfluous animations

Surely, animations can also be simply decorative – as long as they don’t negatively affect user experience. These animations can create a positive experience for the user on a page that's inherently negative (empty states, onboarding flow).

The workflow

Step by step guide

Before diving into the motion part, figure out the time and budget constraints:

Upcoming projects - should have ballpark estimates for motion included,

Current projects - Project Designer checks with PM if there’s a budget for motion on the project.

The Project Designer discusses the animation and works out concept ideas together with a Motion Designer.

Motion Designer creates an estimate and a brief direction description. When figuring out an estimate, make sure to include:

buffer time for importing and exporting assets,

time for 2 critique check-in points with the Project Designer (first draft and polishing),

in case of a more complex animation, the motion designer might create a proof of concept and re-estimate the project if needed.

An estimate is sent off to the PM.

When the PM gives the green light, we schedule it via Operations.

The Project Designer or PM creates a task stating the estimated hours and due date.

The Project Designer prepares assets and hands them over to the Motion Designer. Upload or link assets in task.

Motion Designer gets to work! ✨

🎯 1st check-in point: Draft - The first draft needs to be reviewed early on in the process, so we’re sure we’re on the right track. Keep in mind that motion iterations take longer than those in static design. Include devs in this step also, so we make sure our idea is feasible and won’t run into issues in development or under-estimate the needed effort.

Motion Designer continues working.

🎯 2nd check-in point: Polishing

Motion Designer works on final touches hands it off to developers via Productive tasks. The final versions need to be stored in the project's Google Drive folder as well.

After implementation, the Motion Designer should review the implementation.

Project info (provided by designer and/or PM)

Who's who on the project (designer, design coordinator, PM)

Productive: project and billing point

If it's a client project: state its purpose (pitching the idea or actual project that will be handed off to devs)

If it's an internal project then knowing the budget (available hours) is a must

Preparing assets for handoff to Motion design

Properly name layers and groups that need to be animated

Avoid clipping content in masks whenever possible

Prepare states for all elements that animated elements (if they aren’t part of the provided flow)

It’s ok to use auto layout

If you are preparing assets for the Lottie animation, make sure to flatten elements (CMD ⌘ + E in Figma) - especially if you have elements with border-radius because Lottie has some problems on iOS and Android with rendering it correctly

If you are preparing assets for dribbble, you don’t have to flatten elements

Access to project files

Access to Google Drive folder

Access to Figma files

Access to fonts

Access to production and/or staging

Authorisation for staging when needed (banking apps)

Achtung!

Designers, keep in mind that we need to schedule motion in advance. If you don't prepare assets on time, we'll need to reschedule the booking.

PMs, AfterEffects changes aren't as swift as iterations in Figma. Rendering takes time, mid-animation changes result in moving a lot of stuff around, Lottie export might have bugs, and so on. Try to round up all client comments at once and not iterate on an animation bit by bit.

The tools

Principle

Principle — ease of creating animated flow from different applications or web screens through predefined animations allows motion designers to quickly and easily create an animated prototype.

Another big advantage of this software is the easy way of importing screens from the other design software, such as Figma.

🔗 Principle: Documentation

🔗 Principle: Tutorials

After Effects

Adobe After Effects has always been the most widely used animation tool. Being a more complex tool than Principle, more oriented towards explanatory videos and long-term animations, it is emerging as an essential interface animation tool.

While Principle allows us to create a fast flow and prototypes to present the main interactions of an application, After Effects lets us explore the creation of more complex effects and interactions.

ZXP

Free installer for CEP (Common Extensibility Platform, which enables developers to build integrated panels in Adobe desktop applications). It will work with any ZXP extension (e.g. aeux, bodymovin, overlord...). It is a great tool to instal and keep all of your plugins organised in one place. Just drag and drop the .zxp file to the ZXP interface to install any new plugin.

AEUX Plugin

You have created your design in Figma, and now is time to transfer it to After Effects. The easiest way to transfer layers with the least friction between visual design and motion is by the AEUX plugin.

AEUX is a set of panels for Figma, and After Effects. Spell it out or say it like A-Yo.

Although AEUX is not available as a community plugin, there are a few steps you need to do before you start using it.

Instructions:

Make sure your elements are inside of a frame in Figma

Open the AEUX plugin (Plugins > Development > AEUX)

Select the frame

Press the button “Send selection to AE” (Make sure you already have created the composition in the AE)

Do your magic inside of the AE

Check it out here.

OVERLORD Plugin

You can easily import illustrator files to after effects by dragging and dropping the file in the AE animation pane, but there is also a helpful plugin to speed up your workflow - Overflow.

Transfer shapes as you need them without importing, converting or redrawing.

Check out the whole set of features here.

Useful after effects plugins for animation:

Motion4

Flow

Bodymovin

Once you have installed the Bodymovin plugin through the ZXP installer, you’ll find it in AE - Window > Extension > Bodymovin.

It is important to select the composition you’d like to export as Lottie and select the folder where you’d like to save it.

If you press “Settings”, you’ll see multiple export modes. Check the “Standard” option and “Demo” to preview the animation in the browser.

Lottie

Lottie renders animations exported from After Effects through the bodymovin plugin. This makes integrating animated assets in apps and websites quick and easy.

Although some After Effects features are not yet supported, this library is growing, allowing for the export of more complex shapes, masks, trim paths, solids, and alpha matte effects.

The community is continuously growing – check out more great examples already created by the Lottie community.

Check the list of supported features.

Motion libraries for web projects

Here are a couple of libraries that can come in handy when creating landing pages with Wordpress:

GreenSock

anime.js

barba.js

Locomotive scroll

📚 Recommended reading

UI Movement (Examples of UI Animations)

Creating Usability with Motion (Article)

How Motion Design Applies to UI (Article)

Motion Design Is the Future (Article)

Motion Design School (Course)

Material design - The motion system

Human-interface-guidelines - Motion

As a designer, you hand off your work to the development team, and they move on to implementing your designs. However, that doesn’t mean you can close Figma and call it a day. You want to ensure your designs are implemented correctly and meet the outlined requirements and specifications. This is where a design implementation review comes in.

Design implementation reviews, or design reviews, keep everyone (designers, developers, and software testers) on the same page. They help ensure that your carefully envisioned designs are implemented precisely as they should be.

What is a design review?

A design implementation review evaluates the current state of a project’s implementation and is usually performed at the beginning of the development process.

The golden rule is: review early and often. Identifying potential bugs and UI issues early in the process reduces the chance of major problems going unnoticed until later in development.

Making changes early in development is much more cost-effective than altering a product later in its lifecycle. Additionally, reviews and feedback at any stage of digital product development are crucial for the product's success.

There is no one-size-fits-all approach to design reviews, so you should customize them to fit your project's specific needs.

How often should you do design reviews?

The frequency of design implementation reviews varies with the project's complexity, timeline, and workflow. Regular check-ins throughout design and development are recommended, often scheduled around milestones like the initial design phase, feature completion, or completion of new components.

In Agile methodologies like Scrum, these reviews are typically part of sprint cycles, occurring at the end of each sprint, within user stories, or as part of the Definition of Done (DoD) for specific tasks.

Synchronous design reviews – live or remote

Synchronous design implementation reviews involve everyone present simultaneously. The project’s designer, developer (at least one per platform), and software tester pull the latest build to compare it against the design documented in Figma.

Whether they’re taking place live or remotely, the jist is the same – designers or developers walk everyone through the design or demonstrate how it’s implemented.

Pros:

Immediate feedback: Identifying and addressing issues promptly reduces the chances of a misunderstanding.

Faster decision-making

Minimized risk of misinterpretation

Live-fixing minor issues: If we notice a small detail that can be easily fixed, we can take care of it immediately instead of creating a task and addressing it later.

Improved relationship between design and development

Cons

Time-consuming: Design reviews can be quite time-consuming, especially on complex projects.

Scheduling bumps: Scheduling meetings can also pose a challenge and lead to delays. A designated time slot is the key to minimizing scheduling bumps with synchronous design reviews.

The pressure of on-the-spot feedback

Pro-tip for synchronous design reviews: Whether reviews are conducted live or remotely, it is good practice to determine who is responsible for taking notes during the meeting. This ensures that nothing important is missed and makes it easier to assign tasks for development fixes after the meeting.

Asynchronous design reviews

Scheduling live or remote reviews can be a hassle at times. Asynchronous design implementation reviews offer a way to review and give feedback on a design or its implementation without everyone having to be available simultaneously. This can be convenient for distributed teams across different time zones or when stakeholders need more time for a comprehensive evaluation.

Pros:

Saving time and effort

Flexibility: The designer can provide feedback on their schedule, accommodating different time zones and the development team's work hours.

Written feedback: Written feedback provides a clear and permanent record of the review process.

Iteration: Asynchronous reviews allow for multiple rounds of feedback, enabling iterative improvement. Developers and testers can respond at their own pace without feeling pressured.

Cons:

Issue resolution time: They may delay issue resolution because participants are not simultaneously available to discuss and address concerns in real-time.

Potential for miscommunication: Since there is no opportunity for immediate clarification or real-time discussion of feedback points, there is a higher risk of miscommunication or misinterpretation of the written feedback.

Reduced collaboration: Without real-time communication, team members have less dynamic interaction.

For some features, live and remote reviews work better, while for others, we can thoroughly review the implementation working asynchronously.

Way of Working for asynchronous design reviews

A standard method for asynchronous reviews is for designers to compare implementation screenshots with the original designs in Figma. Here are a couple of general tips that will help you on your way:

Before starting the review, specify what build you were using. You want to ensure you have the latest build installed on your testing device, as you don’t want to test bugs and issues that have already been fixed.

Make sure to take screenshots while going through flows. Alternatively, you can screen-record everything and then screenshot specific frames.

If you’re doing a design implementation review for mobile, compare the implementation on iOS and Android.

To simplify the process, we have created a template for asynchronous design implementation reviews, ready for your next review.

When we review, we find it best to categorize issues and fixes into three groups: things that must be fixed, things that should be fixed, and “nice-to-haves.” This categorization helps developers prioritize tasks and fix critical issues first.

🔴 “Must fix” issues typically relate to critical UX or UI issues likely to disrupt the user experience.

🟠 “Should fix” issues usually relate to UI issues caused by a slight deviation from the original design during implementation.

🟢 “Nice to haves” relate to improvements or fixes that are not critical or essential but can enhance the quality, usability, or performance of the whole product.

Document all the necessary changes with as much detail and clarity as possible so developers can understand precisely what needs to be improved. Your design review documentation can include notes next to the screenshots you have taken and more detailed information in the appropriate place.

After annotating the implementation and design screens, you must align with the developers and testers about task handling, development fixing, and further testing.

When you designate a task for the development team after a review, make sure to link the Figma file where they can find your design review documentation. For better file organization and clarity, it is better to have a separate Figma file just for design implementation reviews. When the feedback is received, there may be a follow-up meeting to discuss and clarify individual points and make decisions based on project needs or technical limitations.

Checking implementation during testing phases

As our software testers test flows and functionalities, they either screen record everything or take screenshots and attach them while creating tasks for the development team. Whenever they address issues in those tasks, take a look at the provided screenshots or videos and try to catch any UI issues that also need fixing.

“Mini design reviews” can be a great addition to your usual review practice, but they cannot replace the benefits and impact of a comprehensive review.

Review as you see fit

Design implementation reviews aren't "one size fits all." Choose an approach that suits your project's needs. You can also combine synchronous and asynchronous reviews to take advantage of their benefits at different stages. Flexibility is key—adapt your review process as the project evolves and based on team feedback.

Naming convention

Follow the naming convention below:

| Platform | Web | iOS | Android |
| ------------------- | ------------------- | --------------------------- | ------------------------ |
| Icon | ic-name | icon-name | icname |
| Background | bg-name | background-name | bgname |
| Image | img-name | image-name | img_name |

Promotional graphic assets for App Store and Play Store

To publish an app, we need to create promotional images or videos for the App Store and/or Play Store. Each platform has a specific set of requirements, so these graphics must be made accordingly.

App Store

The App Store shows promo images according to the device you are viewing it from. That is why we need to create App Store images previewing the app for different devices.

You can find the list of devices and their corresponding static screenshot sizes here.
If you create a promo video, follow these guidelines.

Goole Play Store

The requirements for Play Store are a bit simpler, especially for static images.

As for the video, you can add a promotional YouTube video within your gallery.

Mockup templates

Apple Design Resources

Devices from Design at Meta

Diverse device hands from Design at Meta

App icons

App icons are a crucial part of a product’s visual identity and are often included in the Styleguide to ensure consistency across platforms. When creating app icons, it's essential to design versions for both iOS and Android, adhering to each platform's official guidelines and templates. Here you can find their official Figma templates to help you design app icons for your app:

Figma template for Android app icons

Figma template for iOS app icons

However, when developing apps, we (especially developers and QA) work with different environments like production, staging and development to manage various stages of the process. To avoid confusion and make it easy to tell them apart, when needed, we have to create app icons with ribbons that show which environment they belong to. These icons help the team quickly identify the right version of the app and prevent mix-ups. Here is our Figma template (🔒Internal use) which you can use to quickly add environment ribbons to your app icons.

Favicon generator for websites

Favicon Real Favicon Generator

Ground rules

To help you use AI tools in design safely, we expanded on the ground rules we have as a company. Please read them carefully:

Enter only public data into services such as ChatGPT, nothing that an NDA protects:

Don’t enter any client-specific information (e.g., brand or service names).

Don’t enter anything that can be considered intellectual property, either ours or the client’s.

Don’t enter a unique selling proposition or feature of the service.

Don’t enter raw research data. Make sure you are not sharing any data that is under GDPR.

Don’t enter characteristics of a target group or some customer insights that are unique to our client.

Don’t enter workshop inputs/findings or anything that was part of some other activity we did with the client.

If you are working for a client that already has strict data protection rules, consult with your PM first.

It is mandatory to fact-check all results generated by AI tools:

ChatGPT is learning from the text data provided by users and the online results it was trained on, so it is prone to misinformation and outdated data.

This is not meant to discourage you from using AI. On the contrary, the goal is to keep up with technological progress and explore different ways of adding AI to our design process. You can use the mock data if it helps make the output more actionable (e.g. using a mock brand name).

Data protection

Before using a new AI tool, check its data policy (this is a good principle for all new tools).

ChatGPT

ChatGPT uses inputs from its users for model training. Because of that, it is possible that someone can access the information you put into it. There’s a mandatory step on your end to use ChatGPT as safely as possible. To protect your data, please make a Privacy Request. OpenAI will stop using your input for model training once you make this request.

You can also turn off Chat History & Training in your account settings, but this will prevent you from seeing your past conversations in the sidebar.

Check the latest information on ChatGPT data controls here.

Notion AI

When using NotionAI, your data is protected under Notion's standard data protection practices. Notion AI will not use your data to train models. Check the latest information on NotionAI here.

Prompt writing tips

Ask to assume the role of an expert:

Act as a UX/UI designer / Product Strategist / UX writer and [insert prompt].

Provide the context and some examples (if possible, without breaking the NDA):

The project is a [brief project description]. Its primary goals are to [list goals]. The target audience includes [target demographic].

Give a tone of voice and length requirement:

Write a one-sentence interaction description for [specific interaction] in active voice, using a clear and formal tone.

Ask for answers to be in a specific format, like a table or bullet points:

Generate a UX best practice checklist of a [specific feature] on a [desktop] in a [table format]. Include a column with sources.

Ask for more than one result and then compare (3–5 results are usually enough):

We recently came up with a [user problem]. Suggest 3 possible solutions and list the pros and cons for each.

Ask for prompt formulas:

Suggest 5 prompt formulas that a UX/UI designer could use when working on a [e.g. new feature request].

Always double-check the information an AI tool provides. Don’t accept the first result; use the regenerate response function, refine your initial prompt, and save your successful prompts for future reference!

Don’t put AI-generated outputs into the files that clients can access unless you’ve reviewed (and amended) them. Don’t mislead clients into thinking that some output was yours if you used some AI tool to generate it.

Analysing a brief or feature request

Here are some prompts you can use in your next task:

Write a concise problem statement based on the text below: [insert text]

What's the best way to design a solution to this brief as a UX/UI designer: [insert text]

As a UX/UI designer, what questions could I ask a product owner / developer / stakeholders to get better insight into design requirements for [feature], based on the text below: [insert text]

Create action points for UX/UI designer based on this feature request: [insert text]

Define key [business] metrics for a [feature]

Where to start?

Start by going through Figma's Help Centre - they’ve created an incredible library of easy to follow tutorials which concisely cover all of Figma’s functionalities. For advanced use, check their Best Practices library.

To stay up-to-date, follow them on YouTube for video tutorials and check their What's New for the latest updates.

Versioning

Figma autosaves all your work and creates versions on its own, but it’s not so easy to navigate through auto-generated versions. Make sure you save versions on your own after finishing a specific task or a chunk of work. Versioning in Figma is as easy as it gets; just click File → Save to version history and name it in a way that makes sense and it’s easy to find.

Ownership

Figma supports permissions at a team, project, and file level, which means we have to make sure all our files exist inside Infinum’s workspace, so nothing gets lost in the shuffle.

When you create a new project (and file inside the project), the file ownership is automatically assigned to you. You'll need to the following for the project and each individual file:

Click Share

Invite Infinum to the project (or file)

After it appears on the list, click the dropdown next to its name and select Owner

A dialog will pop up, click Transfer ownership

Repeat this for every file you created.

More on permissions can in Figma's documentation.

Privacy

If you’re working on a project where the client does not want anyone from outside of the project team to see the files, select the Share option and restrict access to the team members (Remove team access option). It is still important that the project is owned by the Infinum account. If the file is in a project that's shared with everyone on the team, then you cannot restrict access to an individual file in that project.
More in Figma's Help Centre.

Recommended plugins

01. Building design from scratch

Autoflow - draw flows by selecting 2 objects and a line will be magically drawn between them

Wireframe - browse through the many wireframing kits this plugin offers, and make wireframing easy-peasy

Content Reel - create library content (names, addresses, photos...) and apply them to layers

Unsplash - gives your placeholders a splash of color — wether it's giving personality to grey avatars, or a realistic photo grid

Feather Icons - an icon library with some basic icons

Contrast - makes it easy to check the contrast ratios of colors as you work

Stark - contrast checker and colorblindness simulator

Typeout - provides rich, relevant and quirky library of UX copies to make your designs more conversational and meaningful

Lazy Load - lets you generate skeleton loading screens in one click. Now you can save enough time while designing loading screens for developer handoff

Blush - Create and customize illustrations in your designs

02. User interface design magic

Remove BG - remove the background of images automatically with a single click

Mesh Gradient - generates a gradient image with an underlying 2d mesh, and lets you edit the vertices and edges of the mesh

To Path - if you want a text or shape to follow a curved path

Chart - uses real or random data to create the most popular charts

Dark Mode Magic - plugin automatically generates colors for Dark mode from a light palette and applys them to elements

Isometric - allows you to create isometric layers without manually having to set them up

03. File organisation

Find and Replace - earch for texts on your page and replace them just like a text editor.

Instance Finder - find all Instances of a Component used in your file

Design Lint - finds missing styles within your designs on all your layers

Stark - contrast checker and colorblindness simulator

Rename it - keep your Figma files organized, batch rename layers and frames

Sorter - organize layers by name, position (top to bottom, left to right, etc.), reverse them or get back to square one by randomizing the order

Style Organiser - display and organise colour & text styles

Master - create, attach, clone and move components in a couple of clicks without losing overrides

Batch Styler - change values of multiple (text and color) styles at once

Useberry is a user-testing platform that uses your clickable prototype to get actionable insights from real users. You can use it for both moderated and unmoderated sessions. It supports Card Sorting, Tree testing, Surveys, and 5-second tests as well, so you can go wild and combine different techniques in your study.

Useberry works with prototypes for desktop, mobile, or tablet products. You can import the prototypes from Figma simply by copying the URL of the prototype. Then you create tasks and pose questions to see how they react to your product. There are some Useberry-specific prototyping rules that can help you avoid troubleshooting.

To conduct research with Useberry, you can use Infinum’s professional Useberry account. Set your research goals, sign in, add a project and let the tasks flow! There is a dedicated handbook chapter that can help you define user tasks that will allow you to achieve research goals.

After the testing, you get a UX report based on the participants' behavior and the answers they've given. Useberry tracks and records user interactions, such as clicks, scrolls, and taps. This allows you to see exactly how users are interacting with the product or system, and to identify any issues or pain points that users may be experiencing.

Additionally, Useberry provides heatmaps, which provide visual representations of user behavior and can be used to identify patterns and trends in user interactions. All data can be filtered and segmented based on different criteria, such as demographics.

If you like looking at spreadsheets, you can get a .csv file with results; if you like vibrantly visualized and interactive results, Useberry prepares a lot of graphs for you.

To summarize, creating a Useberry is a mid-game move. You'll first have to cover the foundations of usability testing by doing these three:

Defining research goals and checking with the client if they're ok with it

Defining user tasks that would allow you to achieve research goals

Preparing a Figma prototype that lets you do 1. and 2.

Preparing the Figma prototype for Useberry

Some Useberry-specific prototyping requirements need to be respected if you want the two to work together. And it’s not really a 2-minute plug & play action, be ready to spend some time working on this.

After a couple of years of trial and error and Useberry troubleshooting, we have distilled some advice that can help you prepare your prototype for Useberry. Please let Nina know if you think we need to update or add some of the advices 🙂

Start with creating a separate Usability testing prototype file in Figma. Uploading your regular (usually huge) design file to Useberry will probably end up in Useberry crashing, and you in troubleshooting. Unlink component libraries from the prototype file as it contributes to information overload.

Useberry supports interactive components as well. In this case, please be careful to enable interactive components manually on every single task that uses them! Otherwise, the heat maps will not be synced with the screens users were clicking on.

Clean unnecessary screens and flows, leave just the ones you need for the testing (plugin Clean can help).

Sometimes, you might even need to compress your high-resolution images and videos to optimize your Figma file and prototype. Plugin named Downsize can help you with this part.

Useberry supports Figma overlay functionality. So feel free to use it!

All the components that are on the screens have to be in the frame.

Untangle different tasks’ flows. If you have two or more intersecting flows, participants can jump between tasks in the middle of the mission, and get stuck in a maze. This also means that sometimes you will have to make three homepages, each for a different flow/task.

You can create more than one flow for each mission, as Useberry lets you test multiple paths that represent different ways your users can achieve their goal.

Keep it real and remove any placeholder or dummy content. Trust us on this one, participants tend to fixate on illogical placeholder content, which makes their feedback less useful. Try to align the content with tasks participants have to perform during the study and keep the information consistent on all screens (names, phone numbers, payment amounts, language, etc.).

Don’t test keyboard, data picker and other standard interactions. When the user taps on the input field, just fill it in with data. You don’t need to mock the process of typing on the keyboard. The user presses any letter on the keyboard and input miraculously appears in the input field.

Design a simple success screen. It can help your research participants review and comment on the last screen of the mission at their own pace, as Useberry would remove it after a delay of a couple of seconds.

Name your screens meaningfully. In Useberry, you have to manually select the starting screen for each mission. When you have more screens that look the same, naming them meaningfully can help you select the right one (by meaningfully, we mostly mean naming them “Task 1”, “Task 2”, etc.).

Set the permissions for your Figma file and prototype to "Anyone with the link can view". If you don't, the prototype preview will not load and testers won't be able to view your prototype in the test. When the sharing permissions are set right, simply copy the Figma prototype URL and paste it into Useberry to start building your test.

If you make any changes after importing the prototype, sync it manually. Your Figma prototype will not be updated automatically in Useberry.

Check the study preview before putting it in the hands of users. Previewing is a great way to ensure your study flows nicely, and that your users see what you want them to see. So, test the prototype yourself (or ask for a new couple of eyes) to make sure there are no broken links or missing elements.

Check the study preview on different-sized devices and adjust the design if needed. Keep in mind that your prototype is not that responsive. Sometimes it happens that users don’t see the button at the bottom of the screen as their screen size is too small.

Duplicate the Useberry file before publishing it. Otherwise, you won't be able to correct that small mistake you made while prototyping when you find it.

We hope these 2300 tips helped you import a prototype and publish study without a lot of hassle. If you end up with an error screen after going through all of these tips & tricks — ping Nina, or check Useberry’s help resources.

Prolific is a user recruitment tool that allows you to easily find and recruit participants for your studies. It is a platform that connects you with a large pool of potential participants, who have already signed up to take part in research studies and filled out a surprisingly comprehensive screener survey.

The first step in using Prolific is, of course, to sign in. You can use Infinum’s professional account to do so. Then you can create a project on the platform. This involves providing basic information about the study, such as the number of participants needed and the time commitment required. Here are tips on filling out the project brief on Prolific (for the steps that are not always self-explanatory):

When Prolific asks you to describe what participants will be doing in this study, describe it in a few sentences. Use the same section to copy-paste NDA and consent to participate from the statements folder in our internal usability testing kit (🔒Internal use). Our Dora the legal put her stamp on it so you can let the clients know that the legal part is taken care of.

If the study is unmoderated, attach the study (Useberry, Typeform…) URL at the dedicated spot in the data collection section.

When Prolific asks you how you want to record Prolific IDs, select the “I'll add a question in my study” option. At the beginning of your survey, add a question asking participants for their unique Prolific ID. This is the only way you can connect prolific data to study data, and approve someone’s submission.

When Prolific asks you how you want to confirm participants have completed your study, select the “I'll give them the Completion Code to copy & paste” option. As a last step, give participants the completion code Prolific will generate for you. Participants will enter the code on their Prolific account when they finish the study.

The fun part is specifying demographic criteria for participants. When we say the Prolific screener survey is comprehensive, we couldn’t be more serious about it. You can screen your participants based on different criteria connected to their age, gender, work, hobbies, income, investment experience, experience with different technologies, shopping habits…

The not-so-fun part is everything related to the study cost. Based on the length of your study, the number of participants needed, and their characteristics you should calculate the total study cost. You can use this calculator to get a sense of the amount that will work for a specific case. From experience, going 50-65% below the calculator’s suggestions still works well.

Once you know the costs, go to your PM, discuss the study cost, and make an invoicing plan. Once the client gives you the green light, ping Monika or Jurica to top up your Prolific account with the right amount.

So, once the project is created and the account topped up, Prolific will match you with potential participants who meet your specified criteria. Participants will get an email invitation, and you can track their progress and participation through the platform. If needed, you can also contact your participants directly through Prolific messages.

When you are done with the study, review responses, and approve submissions of participants that completed their research tasks adequately.

Keep in mind that Prolific has a cap on the number of rejections you can do. If it goes beyond 20-25% submission, you won’t be able to do it without reaching out to Prolific support. Pro tip: instead of rejecting, reach out to participants and ask them to return their seats, or you will reject their submission. Rejections affect their Prolific score so most participants rather return their seats.

Prolific can also help you when analyzing research data. When the study is completed, you can download a .csv sheet with demographic information about participants.

You probably filled out your fair share of surveys. You remember an endless list of questions staring back at you, waiting for you to click the smallest dot in the world that would indicate if you agree with each and every single one of those statements.

This is why we use Typeform. It makes filing out surveys as easy as it could be – given you’re still filling out surveys, not enjoying a Mimosa in Vegas’ Dome.

You’ll find credentials in the Design team’s 1Pass vault.

Typeform has a great help page with detailed instructions so we won’t go into too much detail. Instead, we’ll cover some key things you need to know about using Typeform:

Create your study within the UX research folder in Typeform

Usually, it’s best to start from scratch instead of reusing a previous survey

Make all questions required. When a question is optional, mention that in the question’s text as well

Randomize options unless you have a very strong reason not to do so (e.g., options describe a rising level of something like time spent on social media)

Multiple- and single-choice, and ranking questions are better than open-ended ones

Pose questions as short as possible

Try to make available options to be of similar length

Avoid leading and biased questions unless you have a very strong reason to pursue one specific angle in a question

You can recall answers to previous questions by typing @ and then choosing a question, for instance, “How come @favorite brand? Is it your favorite brand?”

Use question logic to ensure participants don’t answer irrelevant questions

Customize the link’s share information such as headline and body copy – avoiding using Typeform’s default copy

Set to be notified when someone fills out your survey – it’ll give you peace of mind about the pace of turnaround

If you are sending out the survey to the real end users, add a new template using the products brand artifacts

Illustration

Adobe Illustrator

Affinity Designer

Procreate

Photo editing

Adobe Photoshop

Affinity Photo

Motion design

Adobe After Effects + Lottie

Prototyping

Figma

Compression

ImageOptim - supports both lossless and lossy compression, lossy being a great choice for large photos

TinyPNG - lossy compression for PNGs and JPGs

Handbrake - video compression tool

Sketch or Figma? They are both great designing tools, and each has fantastic functionalities. Last year our team decided to work in Figma because the export is easier and it doesn’t take so much time.

When you need to switch from Sketch to Figma, Figma provides great import options for Sketch files. You still need to edit your imported document later, but it’s not such a big mess, and it's worth the effort.

First things first

Create a new project inside Infinum Team. If you don’t have the access to the team, contact one of the team leaders to add you. Inside the project, you can add multiple files. We advise you to invite your Project Manager, developers and clients with view-only permission.

In the sharing settings turn on access only to people invited to file, so your file isn’t seen by everyone outside the company. Everyone at Infinum Team will still be able to view your project and files, and that's ok for most of the projects which are not strictly under NDA.

Here we go

Save the latest version of your Sketch file locally from Abstract. Then open up Figma and add a new file to the project. Then go to File → New from Sketch File. After you select that, it will take some time for Figma to upload your file. ⏳

Now, that your file has uploaded, it’s time to do some file organizing and cleaning up. The design system library is the first thing you need to create. If this is confusing, a library is just like a Symbols page in Sketch, only stored in another file which you connected to your working file. Figma uses Components over Symbols that you can use across your design files. When you reuse them, they are called Instances. We differentiate them by their symbols. Also, you access Instances in the Assets panel.

So, how a library works with an imported file? It is necessary to create a library and connect it with an imported file which is now actually only one file. But how to separate that file into a library and a working file with screens?

First, open your imported file and go to Assets → Team Library and then click on Publish. Now click on Move to Team Library and choose your team. The next step is to add a short description if you want, then click on Publish, and there is your project library. ✨

Now that you have published your project library, in the project, go to File → New. You need to create a new working file in which you will copy all your screens from the library (Page by Page) and only leave the Symbols page in the original library file. Here you will find all of your project Components.

But if you want this to work, you must connect your New File with the Library. To do it, go to Assets → Team Library in your new working file and activate the library which you published just minutes ago.

Now, it’s time to copy and paste. In the new working file, create a New Page and start copying your screens (Page by Page). When you copy the first batch of screens, click on your one of the instances (ex symbols). Then right-click and choose Go To Master Component. If you automatically switch to another tab in your library file, you have done everything correctly! And don’t forget to delete your screens from the library file. Leave only the Components page.

What to do next?

Cleaning, cleaning and organizing. Probably you’ve realized that some of your Icons or Text / Color Styles are messy. To clean that, open your library file and do this step by step:

Create Color Styles

Create Text Styles

Apply Color and Text Styles to your Components

Please go through all components and organize them by usage or features

And voilà!

The great thing about your library file is that now it is Components and Style Guide are in one place! Rearrange your components by their usage or features, but separate them by using Frames (Artboards).

Figma is handling Text Styles much easier. You don’t have to create additional styles for text colors or alignment. They can be adjusted right inside the instance so no more duplicating and getting lost in the file.

Tips and tricks

If you haven’t organized your Sketch file neatly, please don’t bother organizing it in Sketch if you will transfer it to Figma. Figma handles some situations differently, so the best thing would be to start from scratch in Figma.

Remember to expand all strokes and icons in the Sketch file. That way they maybe don’t mess up during the import.

Make sure you remove duplicate icons that may have been left from the Sketch file since you can override the icon colors in Figma.

P.S. if your file is large and you have a lot of components, maybe you can add color and text styles next time you work on a specific project task. You will save some time by this process if you won’t be using all of your instances for new design tasks. And don’t forget to write down a note for yourself or your team, so no one forgets to do this later.

Useful plugins

Instance finder- Find all Instances of a Component used in your file.

Quantizer - This plugin is for quick arranging and rearranging selected layers in columns.

Similayer - This plugin takes Figma’s in-built ‘Select all with...’ command to the next level. Select similar layers; based on a whole range of properties.

Font Master - This plugin scans your project then shows you all of your font styles and where they have been used. You can select your texts and group them under a style quickly.

You’ll spend a lot of time during a workshop in FigJam. FigJam is Figma’s digital board solution. If you used Miro or something similar, you’ll have no problems using FigJam.

Since FigJam features are on par with competitors, its edge, in our case, is the easy sharing of Figma assets to FigJam and vice-versa. It makes life easier for both product strategists and designers.

FigJam has a great guide, so we won’t go into too much detail.

A few important things about the logistics of FigJam:

Make sure that the FigJam file you’re creating is within that project or client’s folder in Figma. If you’re unsure, ping design team leads to help you out

Re-use as many FigJam template exercises as you can.

Invite client team members as viewers to the file when it’s ready

A few minutes before the workshop, turn on the Open session

Be sure to update access privilege on a daily basis and be careful sharing an editable link with non-workshop participants or collaborators

Most important commands in FigJam

Clicking on an avatar in the top right corner – follow that person on the board

S – create a sticky note, the third option from the right in the toolbar

Shift+s – create a section that you can shape, great for organizing content

E – stamps and emoticons that you can use to quickly get feedback from participants

cmd/ctrl + d – duplicate any element on the board

Right-click + “Copy link to” – share a link that lands the person on a specific asset within the board

Nielsen Norman Group: Training & UX Certification

Nielsen Norman Group (NN/g) offers a respected UX Certification program through its UX Conferences, which are available both in person and online.

NN/g’s UX Conferences cover various topics:

Interaction Design

UX Research

UX Management

Courses are 1-2 days long and provide both theoretical and practical knowledge. They cater to all levels, from beginners to advanced practitioners. Courses use tools like Zoom for classes, Google Drive for materials, and Slack for networking. They feature interactive sessions, breakout rooms, and engagement through polls and discussions.

The certification process requires participants to attend five courses and pass an exam for each. Upon passing, participants receive a certification badge and are listed on NN/g’s website.

Interaction Design Foundation

All courses are pre-recorded and accessible through a monthly subscription. Upon enrolling in a course, one lecture is unlocked each week. There are no deadlines to complete the lectures. After finishing each unit or course, you must take an open-ended test, which will be graded by the instructors. Upon passing the test, you will receive a certificate.

UX:

User Research – Methods and Best Practices (Beginner, Intermediate) 

Emotional Design — How to Make Products People Will Love (Beginner, Intermediate)

Mobile User Experience (UX) Design (Beginner, Intermediate)

Affordances: Designing Intuitive User Interfaces (Intermediate, Advanced) 

Information Visualization: Getting Dashboards Right (Intermediate, Advanced) 

Accessibility: How to Design for All (Intermediate, Advanced)

UI:

The Ultimate Guide to Visual Perception and Design (Intermediate, Advanced)

IDEOU

Online self-paced pre-recoded courses.

Prototyping for Digital Experiences (All) 

Low-fidelity prototyping methods for digital products and services

Power of Purpose (Intermediate, Advanced) 

Learn to work and lead with purpose

Skillshare

User Experience Strategy Masterclass - Become UX Strategist (All levels)

Designing for the Future: UI/UX Prototyping (Beginner)

Intro to UX: Designing with a User-Centered Approach (Beginner)

Intro to UX: Fundamentals of Usability

Awwwards Academy

Awwwards Academy offers specialized online courses in web design, UX/UI, and digital development, taught by industry experts. The courses include video lectures, practical assignments, and live Q&A sessions, culminating in certificates of completion that enhance professional credentials.

Purchased courses (🔒Internal use)

A list of courses our team mates went through and their ratings/recommendations.

Welcome to the design team glossary! If you hear a buzzword in the office, read some gibberish on Slack or get an instruction from the developers and you’re not sure what they are referring to, please visit this amazing page.

Here you can find:

Terms that you encounter when working with your project team. Miscommunication sometimes happens inside project teams because different people use different names for the same things.

Terms that PMs, Organizations team and your Team Leads use every day when scheduling and leading projects.

The language of designers.

The language of developers.

Business and Sales terms.

💡 Use ⌘CMD+F to search for a specific term

Abbreviations

API (Application Programming Interface) - Roughly said, an API is defined as a development specification of possible interactions with a software component. #dev #tech #projects

CI (Corporate identity) - a brand or visual identity from a company or corporation. Usually comes with a set of strict branding guidelines. #design #marketing #projects

CTA (Call to Action) - usually refers to a button or other UI element which prominently invites the user to take action on a website or in an app (i.e. buy, add to cart, etc.). #design #projects

DP (Density Independent Pixels) - an abstract unit that is based on the physical density of the screen. These units are relative to a 160 dpi screen, so one dp is one pixel on a 160 dpi screen. The ratio of dp-to-pixel will change with the screen density, but not necessarily in direct proportion. #design #projects #android

EOD (End of the Day) - usually refers to a deadline set by yourself or your project manager. #projects

EOY (End of the Year) - usually refers to a project deadline or quarterly goal deadline. #projects #team

FAT (Factory Acceptance Testing) - a form of user acceptance testing common in the industry. #agile #scrum #qa #projects

FT (Full time) - eight working hours per day. #scheduling #projects

HT (Half time) - four working hours per day. #scheduling #projects

IoT (Internet of Things) - is a system of interrelated computing devices, mechanical and digital machines provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. For example smart home system and devices. #tech #projects

KPI (Key performance indicator) - a measurable value that demonstrates how effectively a company is achieving key business objectives (goals). #projects #management

MVP (Minimum viable product) - a version of the product with just enough features to satisfy the needs of early customers and provide feedback for future product development. #projects

OKR (Objectives and key results) - a goal-setting framework for defining and tracking objectives and their outcomes. The intention is providing teams with visibility of goals with the intention to align and focus effort. #projects #team

PM (Project Manager) - a member of the project team which has a responsibility of communicating with the client, following the budget and deadlines and keeping track of work delivered on the project. #projects #role

PoC (Proof of Concept) - realization of a certain idea in order to demonstrate its feasibility, or a demonstration with the goal of verifying that some concept or proposal has a great potential in the real world. #design #projects

PR (Pull Request) - Pull requests are part of the usual development process. They let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. #dev #projects

PX (Pixel) - A unit for measuring dimensions on a screen and is used when precise design is required. Move the card by 8px to the left. Increase the font by 2px. #design #typography

QA (Quality Assurance) - a member of the project team which has a responsibility of testing the apps and websites, finding bugs and reporting to developers and designers what needs to be fixed tech-wise and UX-wise. #projects #role

QT (Quarter time) - two working hours per day. #scheduling #projects

RFP (Request for Proposal) - before we sign the official contract, the clients want to see a business proposal from our sales team. Usually our proposal includes time estimates, process overview and budget ballpark. Sometimes an RFP can also include a request for a few screens. Then, it becomes more like a pitch, where we need to show off our skills and expertise. #business #pitch #sales

ROI (Return on Investment) - is a financial metric that is widely used to measure the probability of gaining a return from an investment. It's the ratio. between net profit and cost of investment, one way of relating profits to capital investments.
#business #projects

SDK (Software development kit) - a collection of software development tools in one installable package. They ease creation of applications by having compiler, debugger and perhaps a software framework. To create applications with advanced functionalities such as push notifications, photopay, OCR scanning etc; most application software developers use specific software development kits. #dev #tech #projects

SS - just a screenshot. #design #everyday

SWOT (Strengths, Weaknesses, Opportunities, and Threats) - a SWOT Analysis is a technique for assessing these four aspects of the business. #projects #discovery #marketing

UAT (User Acceptance Testing) - high-level tests to verify the completeness of a user story or stories 'played' during any sprint/iteration. #agile #scrum #qa #projects

UT (Usability Testing) - often refers to usability testing.

UX (User Experience) - the process design teams use to create products that provide meaningful and relevant experiences to users. #design #projects

WCAG (Web Content Accessibility Guidelines) - a set of recommendations for making Web content more accessible, primarily for people with disabilities — but also for all user agents, including highly limited devices, such as mobile phones. #design #dev #projects

A

Accessibility - Accessibility is the concept of whether a product or service can be used by everyone— however they encounter it. Accessibility laws exist to aid people with disabilities, but designers should try to accommodate all potential users in many contexts of use anyway. Designers usually need to keep an eye on: color contrast, font sizes and font legibility, screen ergonomics and element hit areas, haptic feedback, photosensitive content, etc. #design #dev #projects

Agile - refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end. It works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations. Usually it’s organized in two-week design sprints followed by development sprint. #projects #management #agile

Alert - Alerts convey important information related to the state of your app or the device, and often request feedback. An alert consists of a title, an optional message, one or more buttons, and optional text fields for gathering input. Aside from these configurable elements, the visual appearance of an alert is static and can’t be customized. #design #dev #ios

App environments - An environment is the application's mechanism for bringing together components with the agent that deploys them. Environments are typically modeled on some stage of the software project lifecycle, such as development, QA, or production.

Development (local)

Test - environment for QA testing. Doesn’t have anything to do with the final app.

Staging - web environment for testing and content before the official production release

Production - final environment that companies launch to the users

Artboard - A name for a page (screen) in Sketch design software and Adobe products. On an artboard you design the screen elements and you can link them into prototypes. #design #projects

B

Backlog - a list of tasks/requirements for a software product in development. If something is in the backlog it is usually low on the priority list. #dev #projects #agile

Ballpark estimate - A ballpark estimate or figure is a number that is a guess, but one that you believe is near the correct number. #business #sales #projects

Box model - In CSS, the term "box model" is used when talking about design and layout. The CSS box model is essentially a box that wraps around every HTML element. It consists of: margins, borders, padding, and the actual content. #dev #web

C

Card - A UI element with a simple layout consisting of the background, an image and a few containers. These containers might hold an image, a CTA button, a title or subtitle. It is an interesting solution to designers when it comes to visually representing information in content heavy situations. #design #dev #projects

Contrast - In WCAG, a contrast is a measure of the difference in perceived "luminance" or brightness between two colors (the phrase "color contrast" is never used). We check color contrast to make sure our designs are visually accessible to most of the people. #design #projects

Copy (Text) - Content written in specific tone & voice for a certain magazine, service, app, website, advertisement, etc. #design #projects #marketing

Copywriting - the act or occupation of writing text for the purpose of advertising or other forms of marketing. UX copy is written content that aims to increase usability and engagement and ultimately persuade a person to take a particular action. #design #projects #marketing

D

Decision maker - a person, usually from the client team, responsible for making key decisions that move the project forward. #projects #role

Dialog - Dialogs inform users about a task and can contain critical information, require decisions, or involve multiple tasks. There are four types of dialogs: Alert, Simple, Confirmation, Full-screen. The alert style is the only style supported on iOS. #design #dev #android

E

Edge case - a use case or a situation which can rarely happen, and is often unexpected or overlooked while designing or programming. While designing, you need to make sure you cover all edge cases. #design #dev #projects #qa

Em - a unit of measurement that originates from the world of printed type. Using this as a unit in typography, this measurement is equal to the currently specified point size. For example, one em in a 16-point typeface is 16 points. This unit is the same for all typefaces at a given point size. When you see 1.5 em, that would make it 24 pixels. Using em and rem units gives us flexibility in our designs, and the ability to scale elements up and down, instead of being stuck with fixed sizes. #design #typography #web

F

Feature - in software development features are the “tools” you use within a system to complete a set of tasks or actions. Functionality is how those features actually work to provide you with a desired outcome. #design #dev #projects

Font - In metal typesetting, a font was a particular size, weight and style of a typeface. Each font was a matched set of type, one piece (called a "sort") for each glyph, and a typeface consisting of a range of fonts that shared an overall design. In modern usage, with the advent of digital typography, "font" is frequently synonymous with "typeface". Each style is in a separate "font file"—for instance, the typeface "Bulmer" may include the fonts "Bulmer roman", "Bulmer", "Bulmer bold" and "Bulmer extended"—but the term "font" might be applied either to one of these alone or to the whole typeface. #design #typography

Font Weight - The weight of a particular font is the thickness of the character outlines relative to their height. #design #typography

Frame - A name for a page (screen) in Figma design software. With frames you design the screens, screen elements and link them into prototypes. #design #projects

Framework - A software framework is a concrete or conceptual platform where common code with generic functionality can be selectively specialized or overridden by developers or users. Frameworks take the form of libraries, where a well-defined application program interface (API) is reusable anywhere within the software under development. The purpose of software framework is to simplify the development environment, allowing developers to dedicate their efforts to the project requirements, rather than dealing with the framework’s mundane, repetitive functions and libraries. A good example of framework is ant.design. #design #dev #projects

F-shaped pattern - The F-Pattern describes the most common user eye-scanning patterns when it comes to blocks of content. ‘F’ means fast. That’s how users scan content on the web. This pattern came out of an NN Group eyetracking study. Users first read in a horizontal movement, usually across the upper part of the content area. This eye movement forms the top part of the ’F.’Next, they scan a vertical line down the left side of the screen, looking for points of interest in the paragraph’s initial sentences. When they found something interesting they read a line and this eye movement forms a second horizontal line of the ‘F.’ The second line typically covers a shorter area than the previous movement. Finally, users scan the content’s left side in a vertical movement. #design #projects #web

G

Gamification - the application of typical elements of game playing (e.g. point scoring, competition with others, rules of play) to other areas of activity, typically as an digital marketing technique to encourage engagement with a product or service. #design #projects

Grid - a grid is a structure (usually two-dimensional) made up of a series of intersecting straight (vertical, horizontal, and angular) or curved lines (grid lines) used to structure content. The grid serves as an armature or framework on which a designer can organize graphic elements (images, glyphs, paragraphs, etc.) in a rational, easy-to-absorb manner. #design

Growth hacking - Growth hacking is a relatively new field in marketing focused on growth. It started in relation to early-stage startups who need massive growth in a short time on small budgets, but has since then also reached bigger corporate companies. The goal of growth hacking strategies is generally to acquire as many users or customers as possible while spending as little as possible. A growth hacking team is made up of marketers, developers, engineers and product managers that specifically focus on building and engaging the user base of a business. #projects #business #marketing

H

Heading - a title at the head of a page or section of a book. #design #projects #web

Hex code - A color hex code is a hexadecimal way to represent a color in RGB format by combining three values – the amounts of red, green and blue in a particular shade of color. For example #D8262C. #design #projects

Highlight Text - The ability to change colors and highlights of individual words opens a lot of possibilities for your content. It can bring life to an otherwise monotonous tagline. It can also be used to emphasize branding points that are important to you and your audience. #design #projects #web

Hit area - touch target; a touchable area of an interactive element such as a button or an input field. The bigger the hit area, the better for the user. #design #dev #projects

Hover - A hover state in an interactive element communicates when a user has placed a cursor above an interactive element. #design #projects #web

I

Icon - a graphic symbol on a computer display screen that represents an app, an object (such as a file), or a function (such as the command to save). #design #dev #projects

Illustration - a picture, drawing or diagram that helps make something clear or attractive. #design #projects

Input field - text fields which allow user input. Input can be free text, a number stepper, etc. #design #dev #projects

J

JavaScript - JavaScript is a scripting or programming language that allows you to implement complex features on web pages — every time a web page does more than just sit there and display static information for you to look at — displaying timely content updates, interactive maps, animated 2D/3D graphics, scrolling video jukeboxes, etc. — you can bet that JavaScript is probably involved. It is the third layer of the layer cake of standard web technologies, among HTML and CSS. Don’t ever mix JavaScript with Java! #design #projects #web

K

Kerning the spacing between letters or characters in a piece of text to be printed. #design #typography

L

Layout (hr. prijelom) - A design layout refers to the way in which we arrange the elements on a page which makes up the content of a design. The aim of layout is both to convey the message correctly and to present information in a logical, coherent way making the important elements stand out. #design #projects

Leading - the space between adjacent lines of type; the exact definition varies. In hand typesetting, leading is the thin strips of lead that were inserted between lines of type in the composing stick to increase the vertical distance between them. #design #typography

Library - A software library generally consists of pre-written code, classes, procedures, scripts, configuration data and more. Typically, a developer might manually add a software library to a program to achieve more functionality or to automate a process without writing code for it. #dev #projects

Ligatures - Two or more letters combined into one character make a ligature. In typography, some ligatures represent specific sounds or words such as the AE or æ diphthong ligature. Other ligatures are primarily to make type more attractive on the page such as the fl and fi ligatures. #design #typography

Lining figures - Lining figures are commonly offered in two spacing formats, proportional and tabular. Proportional lining figures are the preferred style for all-cap settings, such as headlines, titles, and such. They are also effective anywhere that additional emphasis is desired for the figures, even in running text. Tabular lining figures are the preferred style for columns of numbers, such as tables, price lists, financial data, and listings. #design #typography

M

Margins - Margin is a page layout term used in both print design and Web publishing. In print, "margin" typically refers to page borders, while on the Web it describes the spacing between elements on a webpage. #design #projects #web

Modal - In user interface design for computer applications, a modal window is a graphical control element subordinate to an application's main window. It creates a mode that disables the main window but keeps it visible, with the modal window as a child window in front of it. Users must interact with the modal window before they can return to the parent application. #design #dev #projects

N

nnn - the sound of dissatisfaction. #mario #designteam

O

Old style figures - Oldstyle figures (also known as non-lining, lowercase, hanging, or text figures) have varying heights and alignments, as opposed to lining figures, which are of uniform height and alignment. Oldstyle figures are similar to lowercase characters in that they share the same x-height and have ascenders (the 6 and 8) and descenders (the 3, 4, 5, 7 and 9). They also come in proportional and tabular spacing formats. #design #typography

OpenGraph images/graphics - Open graph is a protocol first created by Facebook in 2010 for extracting the title, images, URL, and meta-information from a web page and displaying it in a social media post. The usual dimensions of an OG photo are 1200x630px. #design #web #marketing

P

Padding - A page element's padding area is the space between its content and its border. #web

Page - sections inside the design file that help in organizing different screen flows or other design sections into separate documents inside the file. #design

Pitch - A presentation of a potential solution to a potential or existing client. Larger projects are usually advertised so that several potential cooperation partners can apply for the job. The various participants then prepare their concept and present it. There are different forms of pitches and representation possibilities. #business #sales #design #marketing

Q

Quarter (hr. kvartal) - A quarter is a three-month period on a company's financial calendar that acts as a basis for periodic financial reports, team reports, employee feedback, etc. A quarter refers to one-fourth of a year and is typically expressed as "Q1” for the first quarter, “Q2” for the second quarter, and so forth. #business #management

R

Raise a flag - Raise a flag means "bring something to notice". The phrase Raise a flag is originated from "raise a red flag" which means to alert someone about a potential danger or trouble ahead, the origin being that red flags are often literally used to warn people of possible peril. You should raise a flag every time you feel stressed out with projects or something goes wrong with clients, features, etc. #design #dev #projects

Refactoring - In computer programming and software design, code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality. Usually, older projects need code refactoring. #dev #projects

Rem (Root Em) - Using em and rem units gives us flexibility in our designs, and the ability to scale elements up and down, instead of being stuck with fixed sizes. With rems all typography units are based on the root element size we set (1rem). If we want to scale everything up, we just adjust the root element size. #design #typography #web

Release - A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. #dev #projects

Rollout - Rollout is an informal business term for the introduction and integration of a new product or service to the market. A rollout often refers to a significant product release, which is frequently accompanied by a strong marketing campaign, to generate consumer interest. #dev #projects

S

Safe area - Safe area is a term used in television production to describe the areas of the television picture that can be seen on television screens. #design #motion #video

Scope - It is a total amount of the web or mobile features included in the project. Each scope has its duration and budget. #business #sales #projects

Screen - a part of the app or website flow; also refers to an artboard or a frame containing design elements. #design #projects

Scrum - Scrum is one of the implementations of agile methodology. In which incremental builds are delivered to the customer in every two to three weeks' time. Many associate scrum sprints with agile software development, so much so that scrum and agile are often thought to be the same thing. They’re not. Agile is a set of principles and scrum is a framework for getting shit done. #projects #management #agile

Sentence Case - Sentence case is the conventional way of using capital letters in a sentence or capitalizing only the first word and any proper nouns. #design #typography

Slicing - In fields employing interface design skills, slicing is the process of dividing a single 2D user interface composition layout (comp) into multiple image files (digital assets) of the graphical user interface (GUI) for one or more electronic pages. #design #handoff #dev #projects

Smoke test - Smoke Testing is a software testing process that determines whether the deployed software build is stable or not. Smoke testing is a confirmation for QA team to proceed with further software testing. #projects #qa

Snackbar - Snackbars provide brief messages about app processes at the bottom of the screen. #design #android #projects

Spread - In printing and prepress a spread is the general description for a pair of facing pages, typically the left- and right-hand pages in a publication, such as a book, magazine or newspaper. #design #print

Sprint - A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies. #projects #agile

Storyboard - A storyboard is a graphic organizer that plans a narrative. Storyboards are a powerful way to visually present information; the linear direction of the cells is perfect for storytelling, explaining a process, and showing the passage of time. At their core, storyboards are a set of sequential drawings to tell a story. By breaking a story into linear, bite-sized chunks, it allows the author to focus on each cell separately, without distraction. #design #projects

System attributes - A concept in information architecture; Attributes are the details we use to describe something, such as describing a person by height, weight or gender. Information can have attributes that describe its packages or the objects within that package. These could be physical attributes such as the number of characters in a paragraph, or abstract attributes such as the appropriate context for displaying that paragraph. For an information architecture to work efficiently, attributes should be applied consistently to packages and their contents. The IA might also include logic for how attributes relate to each other. #design #dev #projects

T

Tabular figures - Tabular lining figures are the preferred style for columns of numbers, such as tables, price lists, financial data, and listings. Tabular affects the character spacing. Each glyph is equally wide and therefore convenient for tables, because you can compare the amounts vertically. #design #typography

Text area - an element which allows users to input text containing multiple lines. It is useful for creating a form field for visitors to leave comments or messages. #design #dev #web #projects

Text box - Alternatively referred to as a text field, a text box is a section or object on a page that allows a user to enter text. It can be one line text box and text area. #design #dev #web #projects

Title Case - Title case is any title or heading text where the first letters of major words are capitalized. #design #typography

Toast - (blueprintjs) A toast is a lightweight, ephemeral notice from an application in direct response to a user's action. Toasts can be configured to appear at either the top or the bottom of an application window, and it is possible to have more than one toast onscreen at a time. #design #web #projects

Top-up - an additional or extra amount or payment that restores something to the level that is required. Often used in telecom projects. #design #projects

Typeface - A typeface is the design of lettering that can include variations, such as extra bold, bold, regular, light, italic, condensed, extended, etc. Each of these variations of the typeface is a font. #design #typography

Type foundry - A type foundry is a company that designs or distributes typefaces. #design #typography

Typesetting - Typesetting is the composition of text by means of arranging physical types or the digital equivalents. #design #typography

Typography - Typography is the art and technique of arranging type to make written language legible, readable, and appealing when displayed. #design #typography

U

UPPER CASE - If letters are in upper case, they are written as capitals; opposed to lowercase letters. #design #typography

Usability - the degree to which something is able or fit to be used. #design #dev #projects

Usability benchmarking - UX benchmarking refers to evaluating a product or service’s user experience by using metrics to gauge its relative performance against a meaningful standard. #design #projects

Use case - A use case is a written description of how users will perform tasks on your website. It outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user’s goal and ending when that goal is fulfilled. #design #projects

User flow - User flow is the path taken by a prototypical user on a website or app to complete a task. The user flow takes them from their entry point through a set of steps towards a successful outcome and final action, such as purchasing a product. #design #projects

User story - In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded in project management software such as Jira. Depending on the project, user stories may be written by various stakeholders including clients, users, managers, or development team members. #projects #agile

V

Vendor - A vendor, or a seller, is an enterprise that contributes goods or services to another company. For example, Infinum can be a software development vendor to a big corporation like a bank or telecom. #business #projects

Versioning - With version control systems, file versions are stored in a special database (usually called a repository). The fact that the history of a file is stored separately from the file itself adds extra safety: even if the file becomes corrupted, you can always restore any of its other versions from the history. If you’re using Sketch then Abstract tool can do version control for you. If you’re using Figma, versioning can be done inside the tool. #design #projects

W

White-label apps - White-label apps are applications built by a white or private label app development company, re-branded and resold by other businesses. White-label app services are solutions wherein an application is ordered from Re-seller Company by their business client but actually built by third-party service provider Company. If you’re designing a white-label app that means you have to design a styleguide flexible enough to cover different business and branding cases. #business #projects

White space - White space is the area between design elements. It is also the space within individual design elements, including the space between typography glyphs (readable characters). Despite its name, white space does not need to be white. It can be any color, texture, pattern, or even a background image. White space can cause problems between designers and clients. Design theory promotes the use of white space for elegance and ensuring a quality user experience. Sadly, many clients and managers consider white space wasted space. They think it could be used to house more information or other visual elements. On the contrary, white space is a great tool to balance design elements and better organize content to improve the visual communication experience. #design #projects

Widget - a small software application that is designed to provide a specific piece of information (such as news, weather, or traffic updates) or a specific function (such as taking notes or controlling another application) on demand. #design #dev #android

X

X-height - In typography, the x-height, or corpus size, is the distance between the baseline and the mean line of lower-case letters in a typeface. One of the most important dimensions of a font, x-height is used to define how high lower-case letters are compared to upper-case letters. #design #typography

Y

Yoast - is a search engine optimization (SEO) plug-in for WordPress platform. #dev #web #marketing

Z

Z-shaped pattern - A z-pattern design traces the route the human eye travels when they scan the page— left to right, top to bottom. First, people scan from the top left to the top right, forming a horizontal line. Next, down and to the left side of the page, creating a diagonal line. Last, back across to the right again, forming a second horizontal line. When viewers’ eyes move in this pattern, it forms an imaginary “Z” shape. #design #projects #web

If you’re assigned to do design coordination on a project, this means you’re trusted as a responsible and experienced person who can follow up with other designers on the project’s design progress, quality and timeline.

The coordinators are experienced team members who:

Can be trusted as responsible and organized

Have good technical and soft skills

Have good knowledge of team processes and best practices

Are proactive and bring additional value to their projects - e.g., suggest process changes, point out when further discussion/clarification is needed, raise flags early and to the right audience, ...

Can follow up with other designers on the project's progress, quality, and timeline

Assigning coordinators to a project

Ongoing projects — On ongoing projects, the coordinator is usually a person who has excellent knowledge of the project (usually the designer who previously worked on this project) or someone familiar with similar projects

New projects — The coordinator is chosen based on domain knowledge, availability, or designer working on the project (e.g., someone’s TL)

Benefits of coordination on projects

The idea behind coordinating projects is to deliver consistent design (product) quality across the board and within the expected budget and timelines.

The coordinator’s responsibilities include:

Making sure that consistent design quality is delivered across the board and within the expected timelines and budget

Making sure that the design is aligned with business expectations and that design decisions are made with users in mind

Each coordinator is also a mentor who needs to make sure the designers grow and motivate them to show their best on the project, taking into consideration the project’s limitations

Promoting best practices and speeding up the adoption process of the new knowledge inside the team

Coordination goals

As mentioned, the coordinator primarily keeps track of the quality of the project, but still, there are situations where mentoring is more of a focus. Coordination is not necessary on all projects and should be decided case by case.

It should be clear why coordination on some projects is being done, and that can be one of the following reasons:

The project or domain is complex

The project is strategically relevant (important client, business opportunity…)

A less experienced designer needs support (mentoring)

The designer working on the project requested mentorship

Some examples of the coordination goals are:

Setting up a way of working

Mentoring a less experienced designer

Improving the UX of a specific flow in the following quarter

Improving communication inside the project team

Helping the new designer on a project understand the domain, etc.

For each project, the coordination objectives should be clear, and our way of working should be aligned with that in mind.

The coordination shouldn’t be done just for the sake of doing it without a clear goal. Also, if a project transitions into the support phase, it's likely that coordination may have become unnecessary, so periodic checks are needed to confirm this.

Starting with coordination

If you have just become a coordinator (congrats!), in order to fully understand what coordination is and how the process works, make sure that you go through these steps first:

Discuss the coordination process and a way of working on the project you are assigned with your TL

Have a meeting with a former coordinator on a project (in case you are taking over), discuss project setup and the general approach to the coordination goal

Have in mind general rules regarding delivering feedback (some mentioned in this chapter)

Coordinating project

Make an introduction meeting with the designer and PM working on the project. Meet the project team and find out the developer’s and QA’s points of view as well.

Join the project’s internal and client Slack channels and ask the PM to include you in important project reviews, demos, and client meetings.

Make sure you understand the project's following aspects:

Who is the client?

Who is on the project team?

What are the project requirements?

What are the client's expectations?

What is the timeline? What is the deadline?

What are the estimates sent with biz dev proposal?

What is the design process?

What are the project risks?

What is the client satisfaction so far?

Is the team delivering on time?

What weekly meetings do they have?

Do they have a Slack channel?

Schedule weekly/biweekly/monthly meetings with the PM and designers to check in on the project. Frequency depends on the project phase, and adjusting it based on the timeline is okay. Support projects need less frequent checks than new projects, which require more attention.

Coordinator’s activities

Recognize mistakes and challenges early

Keep track of time spent vs. time estimated

Dig into the design (screens, flows) and check the current progress

Help designers better understand their work and what they need to improve on screens, flows, ideas, etc.

If something needs to be changed regarding scope, process, or design, inform everyone on the team

Raise red flags to PMs or management

Make sure that best practices are being adopted and followed on a project

Red flags

🚩 in design

The design process covers more than we can fit into the estimated design scope

Design progress is too slow, or design quality drops below Infinum’s standards

The UX is too convoluted

The design doesn’t align with tech possibilities and/or business expectations

Designers aren’t doing regular design reviews

Best practices (e.g., technical, way of working, …) are not followed

🚩 in team and communication

Clients who are unresponsive, have unrealistic expectations or there isn’t a clear decision-maker on the client’s side

A lot of change requests or iteration requests from the client

Designers are swamped with work and can’t fit planned design work into current deadlines

The project team doesn’t acknowledge scope creep in design.

Developers/PMs are ignoring design reviews or there is no time/budget to do the necessary updates within the current deadlines

Designers are not getting the proper feedback.

A TL (of the designer working on the project) should be the primary contact for advice and handling problematic situations. Other than discussion with TL, use the #design-coordination channel on Slack for day-to-day discussions, questions, updates, etc.

Promoting best practices

Coordination should be a platform for promoting best practices and speeding up the adoption process of the new knowledge inside the team. When a new best practice is introduced (either through WoW on another project, critique groups, or team-wide education), it automatically becomes one of the coordination goals of the project. The responsibility of the coordinators is to:

Let others know about the new practice (on a project you are working on or coordinating) you find worth implementing on other projects. Discuss it with the other coordinators or Lead designer. Write the summary of the new practice in the #design-coordination channel and add relevant doc/presentation/link with more info

Keep an eye on the best practices promoted on #team-design-internal or #design-coordination channels

Motivate and help the designer on a project to implement these practices

Track the progress and adoption of new practices on the projects you are coordinating

Documenting coordination

The Coordination sheet (🔒Internal use) is the most important and primary source of truth for coordination.

The coordination sheet contains a project list with coordination-related info, such as

the project’s status

engagement per project

coordinator, PM, and designer names
→ Coordination sheet (🔒Internal use)

Also, as non-mandatory documentation, we can have the project charter linked to the coordination sheet and coordination notes.

A project charter (🔒Internal use) is a document that PMs plan to introduce on all projects and will be part of the project documentation in Productive. This is not our responsibility, but it’s good to be aware that this exists. This document contains relevant info about the project, such as:

general info (description, scope, deliverables, team, links)

milestones

financials (limited access)

risks, blockers, and dependencies
→ Project charter template example (🔒Internal use)

Coordination notes are not mandatory but can be added if the coordinator feels they are helpful.

Tracking time

Generally, coordination time should be tracked on a project.

If that’s not possible due to budget restrictions, the coordinator, PM, and one of the TLs should agree on a solution (e.g., tracking time internally).

Team Leads' involvement

In the case of a D1 designer working on a project, the TL should be the project coordinator (if possible). If that’s not the case, the TL should regularly discuss the designer's progress with the coordinator so that they have a better understanding of how this person is doing.

Benefits of TL coordinating projects with the D1 designer involved:

opportunity to be directly involved as a mentor

having a better understanding of how this person thinks and operates on a daily level

this way, a TL can mentor and guide a designer and be directly involved in the project

the potential of tracking 1on1 time on the client’s budget

Other than mentoring D1 designers, we should see to include TLs only in strategically important/complex projects. TLs shouldn’t coordinate more than 1-2 projects simultaneously.

When not a coordinator, a TL should be the primary contact for handling problematic situations and advice.

Team Leads

As you've become a member of the team, you got a Team Lead assigned to help you grow throughout your career at Infinum.

Reach out to them about any information or issues you have regarding work, uncertainties in the design processes, or your career growth.

The usual activities you will have with your team leader are:

Onboarding in the first days of your arrival to Infinum

Weekly or biweekly 1on1 meetings where you can talk about anything you want: projects, design, philosophy, personal ups&downs

Design sync regarding projects you are working on

Quarterly reviews where you will get feedback on your design, skills, working habits and career growth

Some random advice or chit chat on Slack

Here are some good pick up lines for your team lead:

Do you have a second (even though it might take longer)?

I'm not sure how this tool/design pattern/app/process works.

I'm not sure how Shutterstock / font / software licensing works

I'm having issues with design / project / client / PM / team member / private stuff, etc.

I need feedback on my work and communication.

I'm not sure how this thing in the office works.

Where is the conference room / toilet / dev team?

Who do I need to ask about ____?

What is the office alarm code assigned to our team?

Can we move this meeting?

I need a vacation on Friday.

I need a day or days off for upcoming exams, graduation, etc.

I'm not feeling well; I need to go home.

I'm hungry, let's have lunch!

I won't be able to finish this on time. Can you help me out?

It doesn't mean that asking anyone else in the team is off-limits. Everyone will be happy to help!

Design coordination

Occasionally, you will work on a project where a design coordinator is assigned to keep track of design progress within budget, deadlines and client's expectations. Most of the time, these are short term projects with a limited time frame, weird processes, or tight budget.

A design coordinator is there to help you and make things normal if stuff gets complicated on the project. They are also there to help if you need a second opinion, critique eye, or pair of extra hands on your project.

Check the Design coordination sheet (🔒Internal use) to see the most recent updates and project states.

Use Pocket or Matter to manage, collect and organize your to-read list!

Digital design guidelines & systems

Apple Human Interface Guidelines

Material Design

Atomic Design

Design Systems Repo

DesignBetter Books

Shopify Design System

Kiwi Design System

Intuit Design System

Design System Checklist

News and articles

Sidebar.io

DesignerNews

UsePanda

Nielsen Norman Group

Google Design

Medium

UX Collective

UX Movement

Prototypr.io

UX Myths

A List Apart

digitalwaveriding

UX Booth

UX Matters

Google Design

Spotify Design

Airbnb Design

Marvel Blog

Evernote Design

User Onboard

AIGA Eye On Design

Design Observer

Recommended reading

Which Input When

Line length

Design better data tables

Device metrics

Color in UI Design: A (Practical) Framework

Data visualization best practices

UX methods and workshop handbooks

UX Collective's Guide To Design

UX Design Methods In A Mind Map

UX Methods Bank

UX Design Methods & Deliverables

The User Experience Team of One: A Research and Design Survival Guide

Design Kit: Methods

The Co-create Handbook

Miro Academy

UX/UI Patterns

Mobbin.design - iOS

Pttrns - iOS/Android

scrnshts

UX Archive - iOS

Collect UI - selected Dribbble shots

Android Niceties - Android

Call to Idea - Web

UI Patterns

UI Sources

Little Big Details

PatternCollect - A curated gallery of patterns by awesome designers & illustrators

Page Flows - Web and mobile

Collect UI - Web and mobile

Nicelydone - Web

Land-book - Web

On brand and product

Brand essentials - What every product designer needs to know about brand

Brand cheat sheet - All the tools you need to build a brand

Brand vs Branding vs Identity

Building the Maze brand

What is a brand

Inspiration

Behance

Awwwards

CollectUI

Dribbble

Case Study Club

siteInspire

Under Consideration: Brand New

Information is beautiful - Data visualisation

Podcasts

Design Matters

99% Invisible

Dissection

DesignLife.fm

Wireframe

Illustration Hour

DesignBetter Podcast

NN/g UX podcast

UI breakfast

Design Emergency

User Defenders

UX podcast

Design MBA

High Resolution

Videos lectures and tutorials

TED: Arta + Design

Adobe x Behance Replay

Nordic.design - Conference talks

Books

Gestalten

Taschen

Phaidon

Blackwell's

💱 COUNTER-PRINT

💱 Draw Down

💱 Victionary

Note: Books with "💱" indicate shipping from countrires outside the EU.

Tech portals

The Verge

TechCrunch

Increment

Design + Code

Codepen

Codrops

CodyHouse

If you’re the leader during the workshop. Think of yourself as Gandalf. You’ve been given a hotchpotch of different experts, and it’s up to you to help them find the way to the end goal. You’ll need to leverage their strengths and overcome gaps in their knowledge or skills. The success of the workshop is your responsibility.

This means you must be assertive and clearly show you know where the group should be headed. You may not know what the end deliverable’s final shape will be, but you’re in the know about the steps needed.
Workshops come in many flavors, and each workshop will have its own specific twist to it. Still, there is one simple principle when moderating workshops: double diamond structure.

Double diamond has four phases:

Widen out - Explore the problem(s) you’re trying to solve

Narrow down - Pick the problem that’s the most valuable to solve

Widen out - Explore different solutions for that high-value problem

Narrow down - Sketch and vote on a specific solution

This structure looks a bit like 🔷🔷, and that’s where it gets the name. Your workshop agenda should make sure everyone understands the problem space and everyone provides a potential solution for that problem.

Keeping track of time

Workshop is a constant fight against time. You’re either too fast or too slow. Go too fast, and you’ll miss out on important insights and potential ideas. Go too slow, and you won’t have deliverables ready on time.

That’s why it’s your job to keep track of time and remind participants about the timebox dedicated to each exercise. In a live workshop, you should have our timer that’ll buzz once the allocated time has passed. On remote workshops, use FigJam’s time – you can even play some elevator music as participants are working.

Be nimble in your approach. Sometimes it might be worth your while to extend some exercise because you are getting valuable insights. Sometimes it might be okay to shorten an exercise. Important thing: keep your workshop goal in mind. If this change doesn’t affect it, go for it.

Steering back

You’re Gandalf, and sometimes Gandalf had to remind everyone of the goal and the purpose of their undertaking. The same goes for you. If some participant is steering away from the main goal of the exercise and the workshop itself, it’s on you to steer them back.

Be respectful but assertive, which is, of course, easier said than done. Here are some tips how to bring the group back to the topic at hand:

Remind them that this exercise is just a part of a larger story

Tell them how this exercise is connected to others

Reiterate that we’re timeboxing things to make sure we achieve our goal

Praise them for their work in previous exercises where they stuck with the agenda

Say “I’m just conscious of time” – this usually brings people back into the moment

In some workshops you might have an ally on the client side that can help you with steering the group. Establish a backchannel with them, like a Slack DM or an email only the two of you are in, and ask them for help. Your ally will know best how to approach people not abiding by the agenda.

If everything else fails, reach out to the project sponsor and ask them to get involved. Having someone from the C-suite reach out to the client team can help resolve these issues quicker.

Parking lot

This is the go-to method for avoiding fruitless discussions. Create a parking lot for ideas that are not related to the workshop goal. Whenever the workshop team starts discussing non-workshop-related things, you stop them and tell them you’re “parking that discussion for now.”

Parking means writing the main points down on sticky notes and adding them to an actual parking lot on the board – be it live or remote. Participants need to see you marking their comments so they feel heard. Otherwise, it might feel like you’re just shutting them off.

Ask them whose action point should a specific sticky note be and make a note of that. Once you’re done with the workshop you either add these parking lot comments to the report or you can send out a dedicated parking lot email to all participants where they can find all those ideas clearly documented.

For extra points: follow up on the notes related to our team even if they’re not strictly within the workshop’s scope and goal. Clients value such proactive behavior and it will show them we’re in it for the long haul.

Day recaps

In the heat of a workshop, over communicating is your secret weapon. Participants must be 110% aware of the progress, the next steps, and the workshop goal.

Daily workshop recaps are the best way to achieve this. Besides keeping your participants in the loop, it’s a way for client decision-makers and budget-holders to have a sense of progress.

A good daily recap should communicate this:

What did you do today, and what are 2-3 key takeaways

A bit of praise for the workshop team to keep their spirits high – mention something specific from the workshop, don’t provide a generic kudos

What will you do tomorrow and if participants need to prepare something

Homework (if there’s any), how they need to send it to you and by when

When a decision-maker or a SMEs is expected to join the session the next day – make sure to add them to the cc

Keep this email lightweight and skimmable. A few sentences for each of the points above should be enough, and bold the key pieces of information to ensure people notice them. Yes, just like we did in this paragraph, you observant cookie, you.

No agenda, no workshop. If you’re just spitballing ideas without a structure, you’re wasting clients and your time. The agenda is a timetable of exercises with the goal and inputs for each exercise clearly laid out. The agenda “forces” you to put your plan to paper and check whether you’ll be able to deliver what you promised to the client and our internal team by following it.

Sounds good, but how do you build one? You work your way backward – this should be your flow:

Define workshop goals

Define the exercises that will be your final deliverable – i.e., the ones you need to be able to achieve workshop goals

Define exercises whose deliverables will be used as input for those final exercises. Let’s call those once-removed exercises

Now repeat this for any twice- or thrice-removed exercises until you get to the beginning of your workshop

We have a huge repository of workshop exercises you can use to build your perfect agenda.

Planning resources

Three types of resources you need to plan out in an agenda – participants, time and materials.

Let’s start with time. For each exercise, you need to define how long it will take. You can rely on previous agendas and ask your colleagues what’s their experience with a specific exercise. As a rule of thumb, these are things that extend the amount of time needed:

Number of participants

Complexity of topic

Type of work expected from participants. No absolute numbers, but this is the rank of activities from the longest to shortest Ideation&sketching > discussion > voting and review

Timeboxing will help you be more productive and avoid discussions for discussion's sake. Participants, especially on the client side, need to understand that pushing past the timebox results in less time for some other important exercise.

The next thing you need to plan for is participants. Depending on the client, you might need to be frugal with their team’s time. In general, you have three types of participants from the client’s team.

Decision-makers → make sure they’re in for the voting and decision-making (d’uh) sessions. They probably won’t have time to be present for the whole workshop, so plan around their schedule

Subject matter experts → they can provide some niche knowledge no one else on the client team has. Involve them in activities where their inputs are essential, like “Ask the experts” or “Value-effort matrix”, but don’t press them to be present all the time

Core product team → you want them in all sessions, they’re the ones who’ll be ideation, reviewing and documenting things together with our team. They’re usually product owners/managers, UX designers and lead devs.

And finally, if you’re running a live workshop, make sure you have all the materials like post-its ready. We have a box with workshopping materials in our Zagreb and London offices. Always plan to have more workshop materials than you need.

One thing that’s easy to miss: have clarity on the actual venue where you’ll be holding the workshop. Some things to check:

How do you access that building and do you need to ping the front desk to let you in

Is there a whiteboard or some other surface you can write and put sticky notes on (a glass wall can serve that purpose)

How many chairs and tables do you have in the room

Will you need to change rooms between workshop days and whether there’s somewhere you can store your workshop materials

What are the facilities there (tap water, WC, nearby restaurants)

For remote workshops, things are a bit easier. Create a new FigJam file, and name it Client - Project name - Workshop. Add the workshop agenda to the board and add exercise templates to the board as well. And you’re all set to share it with the client.

Some participants will be workshopping veterans. Some might be newbies looking for guidance every step of the way. It’s your job to make sure that both types of participants (and everyone in between) do well in your workshop.

Start by sharing the agenda with the workshop team. Try sending it as soon as possible, as finding a 3-day time slot that works for everyone is not that easy. Make sure to flag who’s expected to attend which exercise and why. Ask the clients if they have any questions or feedback regarding the agenda.

If you’re running a remote workshop, either check on that call if participants can access the workshopping tool or follow up via email on this. Make sure that you can see that all participants' slots in FigJam are claimed and you can see that everyone has created their Figma account.

If you are running a workshop in FigJam, use the first 10ish minutes to onboard the participants on its core features. Ask them to follow a person who is talking, zoom in, browse around, post a sticky note, write something on it, and explore stickers and other fun (and useful) things,

Wrapping up the product discovery phase requires pulling different experts from Infinum. We’re talking POs, solution architects, designers, and analytics experts – all of them are needed to create a feasible plan for bringing this product to market.

There are a few key questions we need answered to be able to move into the delivery phase of the project. We’re now in the hard planning mode making both strategic and tactical decisions about the product.

What’s the minimum viable product? What’s the minimum marketable product? (And is there a difference between these two?) → MVP should really have the least amount of features, while MMP should be only a tiny bit bigger than the MVP. A huge difference between these two indicates there might be a mismatch between user needs and the product

What are organizational and tech risks, and how do we plan to overcome them? Who needs to be involved, when, and what are their deliverables? → The client and we need to have clarity on the negative pressures on the project delivery and have a plan on how to mitigate those risks. No risks detected signals that we did something wrong during the Discovery phase.

How do we plan to bring this product to the market? Who should be involved on both Infinum's and the client's side? → A robust and feasible plan for educating the user base, converting and retaining them that’s dipped in well-researched user needs.

What are business and user metrics of success, and how will we track them? → A focus metric that’s clearly connected to the product’s value proposition and a logical and actionable list of supporting metrics that will help guide product development post-launch.

Value-effort chart

The value-effort matrix chart is used as a way to help clients prioritize features and find their MVP. On a 4-quadrant chart, value is plotted on the x-axis and effort on the Y, or vice versa. The objective of the exercise is to place the previously created and refined user stories and plot them appropriately on the quadrant where they can be measured and assessed.

Start with value, as this is likely the more important element to consider. Once plotted, utilize a tech representative such as a solutions architect to estimate the effort of the user story best.

Once your top user stories are mapped, write down the stories in order from highest value and lowest effort to lowest value and highest effort. Implementing high-value, low-effort features is a strategic way to quickly add value to your product while knocking out low-hanging fruits.

For a summary of this exercise, see below:

Use the FigJam template for the value-effort matrix exercise. Ask the PO/PM to write down any user stories if this has not already been done.

Start by locating the collection of user stories in FigJam or ask the client to find the user story that’s the most valuable and then the one that’s the least. This gives you the relative scale.

Have the workshop participants collectively rank the user stories according to value. As a strategist, you should lead this discussion and ensure that all member’s opinions are voiced. Move story by story until you place them all within the chart. Once agreed upon, place the user story at the correct location.

Ask our SA to line up user stories or features on the effort scale.

Discuss if the story mappings fit the product vision.

Use the outputs of this exercise to create a user story map and phase roadmap with the PO/PM, based on the value-effort chart. Discuss this internally with the team.

User stories mapping

The roadmap vaguely resembles a table with labeled product phases such as alpha, beta, MVP, and MMP as columns and features or user stories plotted in the rows.

The idea is to plot user stories in order on a roadmap from left to right, top to bottom, in rows and columns. Rows have bigger features such as login, chat, and similar. Columns show how sophisticated each feature will be in each release and stage.

A rule of thumb is that as you progress right in the columns, each new column will represent a leap in product capability. Keep in mind that some features won’t be built or upgraded in some releases. Consider using Miro or Figma to create this roadmap.

Once the roadmap is complete, it is time to present it to the client as the v1 and the basis for discussions. If needed, show this to the stakeholders in the client company and make sure to get their sign-off.

Analytics framework

Analytics provide the basis for stakeholders to make decisions in the best interest of the company, and the users, according to the data. In order for analytics to be produced on a product, a data pipeline must first be established within your product and you must have an audience to use or already using the product.

Analytics colleagues can do their best work when they're provided user story maps and when they have some designs to reference. User journeys provide an opportunity to capture and collect various data within your product.

Once you have journeys created, sync with the analytics team and ask them to create a WIP analytics framework based on those and the various user personas within the product.

Plan this framework as one of the exercises in the last days of your workshop. Involve Analytics colleagues once you have the user stories map ready and let them prepare for the workshop. They’ll do most of the talking, while you’ll be there to support them in facilitating the discussion.

Some frameworks they might use are FMF or AARRR. It’s up to them to decide depending on a specific project. They’ll prepare a test set of metrics based on those frameworks, walk the client through those, and start a discussion.

Since implementing analytics costs time and money, clients need to see value early on. Allowing them to have a say in building the metrics framework does just that.

Stakeholder mapping

You need to know who’ll be talking to and what are the internal politics within the client's company. Understanding each person's role, seniority in decision-making, and level of involvement in the workshop will help you create this stakeholder map for you and your team to refer to during critical decision-making periods.

It is important to enable all participants to share their input but do not forget who gets the final say in some of these decisions.

When creating the map, you can split them on two axes: power and interest. Power implies the weight of that person in decision making whereas domain knowledge represents the expertise that person has to the particular challenge being solved.

Interest shows how important this project or product is to that person. For example, some stakeholders may dual as the product owner of a project, and may have a particular interest in the success of that project. Success could lead to a budget increase in that department, a salary raise, or a promotion, for example.

In reality, this means that this person might be able to dedicate a significant amount to time to working with you. Try your best to get them as involved as possible as these types of stakeholders should want the project to succeed as much as you do. Make these stakeholders allies and figure out how to best utilize them as a resource.

Power tells you if that person has decision-making power over the budget and the product. If someone can cut off the funding, then they’re someone you need to manage carefully.

Here you can find a template for this exercise.

Flowchart and information architecture

This one is a very designer-heavy exercise. You're trying to understand the informational underpinning of the app.

These most often include:

Sitemap: A tree-like visualization of different pages on a site (or within an app)

System attributes: A list of all the entities withing the app, their characteristics and the way those entities are connected

Flowchart: Visualization of all (or at least most) of the screens in the app and their mutual connections

Pro tips

To be effective at creating your information architecture, be sure to follow these recommendations:

Be sure to structure the information in a logical and meaningful way, often through hierarchies, categories, or other systems that make content easy to understand and navigate.

Be sure to clearly assign labels and names that are consistent to ensure that users can easily comprehend and identify content.

Be sure to create intuitive navigation so Navigation: Creating intuitive pathways for users to move through information, enabling them to find what they need efficiently. This involves designing menus, links, and other navigation systems.

Content Strategy: Develop a plan for creating, managing, and organizing content to ensure it meets user needs and business goals.

Here you can read more on the information architecture.

GTM canvas

A strong go-to-market strategy sets the stage to increase the potential to adopt your value proposition and convert a user or customer.
A GTM canvas is a blueprint for aligning internal stakeholders around what you want to accomplish and what you need to consider when bringing a new product, service, or venture to market.
GTM usually has two main parts: business landscape and go-to-market approach.

Business landscape

Market Need, or the problem we are trying to solve

Value Proposition, or the value of the product or service we deliver, from its benefits to how unique our differentiation is in the market

Competitive Landscape, or the product or company’s position relative to its competitors

Pricing, or the product's price point relative to the market and competitive landscape

Customer Segments, or the users or customers you serve (ideal & actual)

Communication Channels ie. how one expects to communicate with the customer and deliver the value proposition?

Customer Pains, ie. what user pains does our product solve?

Customer Gains, ie. what a user gains by using our product?

Go-to-market approach

Release strategy, or what will be the phases of releases, and what’s the rationale of splitting the product into those phases?

Goals, or what are we trying to achieve through a digital product, think: fewer calls to the Contact center, more subscriptions, bigger webshop basket, and similar

KPIs, or goals turned into measurable metrics

Distribution channels, such as digital and offline ones

Key messages, or what do we want customers to remember about us

Creative direction, or what will the supporting visual or visuals, how do we make this product stand out visually on the market

Here you can find a template of GTM canvas.

Tech limitations

Understanding the limitations of the technology used in creating your product is a critical step in this process. Many people overestimate the capability of technology while simplifying the amount of sophistication and complexity it requires to create basic applications that run smoothly.

Exploring and defining technology limitations begins with an understanding of what it is you are trying to build, the services and tools involved in making that a reality, and what is possible given the time, financial resources, and constraints.

This part of the Solution workshop is led by an SA.

Innovation framework

Digital products are similar to caterpillars, they need to eat a lot (of mental energy) to be transformed into something else. While caterpillars go from yucky to beautiful, digital products go from “just an idea” to “launched on production”. Same difference, if you ask us.

This is the list of key learnings we need to obtain and answers to these questions that would signal the idea is business viable.

What is the market size? → The more the merrier, and the higher the purchasing power, the better.

Do potential customers want this? → This should be a resounding yes.

Why do potential customers want this? → It should be aligned with our hypothesis, and it should be a considerable pain point.

Is someone else doing the same or a similar thing? → The good answer here is “no”. We want to be working in a market of one.

How do we monetize the product? → A clear plan needs to be devised.

The innovation framework is our way of visualizing that process. It’s more of a communication vehicle than something set in stone. It does ensure you get optimal results, but you’re free to tailor the approach to a specific client. As long as you're able to confirm a product passes innovation framework gates, you’re all good.

Gates? Yes, there are some claims about the product you need to validate. This is not just a philosophical exercise, it’s how valuable and profitable digital products are launched. By validating that product passes a specific gate, you’re ready to deploy a new set of exercises and activities to provide value to the client in the next stage.

These gates are no-brainers – they ensure that the idea can make money for the client, meet user/customer needs, and can actually be done using today’s technology. We’re not SpaceX, clients expect to see something in the AppStore within a few months.

Gates

Now we’ll dive a bit deeper into each of the gates and why we set them in this specific way.

Gate 1: Idea is business viable

This involves identifying an opportunity and shaping it into more of a business case than a digital product. We need to think about how this idea would provide value for the client.

There are three general ways it could do that:

Save them time and money by optimizing some process

Earn them money by expanding current market share or allowing them to enter some new market

Provide non-tangible benefits such as brand equity

Our focus is on the business viability of the idea. If the workshop team can’t devise a way to monetize this idea, there’s no point in pursuing it any further. To pass this gate, we’ll do some light touch desktop research and use business and product frameworks to put the idea to paper. This ensures we capture all the risky assumptions and can review and discuss those.

Gate 2: There’s market demand for the idea/solution

Instead of jumping straight to the design sprint, we’ll first validate if the solution has some legs with our target audience. Although an idea might look great business-wise, if no one has the user problem we’re trying to solve, it’ll all come to nothing.

By testing solutions explained in a few slides and sticky notes, we avoid the high prototyping costs while still learning more about our target audience and validating the value proposition.

Think of it this way: instead of designing the Uber app, we start by asking people what annoys them the most when visiting a city as a tourist. If they say it’s public transport and being ripped off by the cab drivers, we’re golden.

Gate 3: Product resonates with the target audience

Once the solution has been validated, it’s time to raise the fidelity of our idea. Now we’ll test if our specific solution to that problem, i.e., the digital product, resonates with the target audience.

The solution might be appealing, but it might need some tweaks, even a slight pivot in the value proposition. This is all much easier done before we start with agile sprints, and there’s no design or tech debt.

We’re trying to design and test the product with the target audience quickly. This higher fidelity of the idea ensures we’re getting the USP right and we’re ready to start planning the implementation of the product.

Gate 4: Such a product can be designed and developed

You passed all three previous gates: the product makes sense business-wise, there’s market demand, and our product seems to address that demand. We “just” need to define how we will bring it to market. It’s no longer “why” and “if”, but “how” and “what”.

We must create an activities roadmap that’s feasible tech- and operations-wise. Tech needs to be able to support such a value proposition, and both clients and our teams need to be able to execute that product vision.

Lean canvas

“Lean” comes from the concept of a lean startup – meaning you’re doing just enough to be able to market and sell the product. No bells and whistles, only the absolute core of your product’s offering. Lean canvas is here to document your assumptions and iterate through them if needed.

Canvas consists of 11 areas, you need to fill all of them with data:

Problem: Clearly define the problem or pain point that your product aims to solve. Be specific and focus on a single core problem. Don’t make stuff up, do the research on the problem.

Solution: Describe your product or solution that addresses the identified problem. Keep it simple and explain how your solution uniquely solves the problem. Remember, at this stage, the solution may still be a hypothesis or early concept.

Key Metrics: Identify the key metrics that will help you measure the success of your product. These metrics should align with client’s business goals and provide insights into AARRR (acquisition-activation-retention-referral-revenue) metrics.

Unique Value Proposition: Clearly articulate the unique value the product offers to customers. What sets us apart from competitors? Why would customers choose your product over alternatives?

Channels: Define the channels through which you will reach and engage with your target customers. Consider both digital and offline channels, such as websites, social media, partnerships, or direct sales.

Customer Segments: Identify your target customer segments or specific market niches. State their needs, demographics, and behaviors. It's crucial to have a deep understanding of your customers to tailor your product and messaging accordingly.

Cost Structure: Outline the key costs associated with developing, marketing, and delivering the product. Consider both fixed and variable costs to ensure a realistic view of your business's financial aspects.

Revenue Streams: Define your revenue model and how you plan to monetize your product. Explore different pricing strategies, such as one-time purchases, subscriptions, or freemium models. Consider how you will generate sustainable revenue in the long term.

SWOT

SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. It is an analysis technique used to assess the internal and external factors that can impact a product or organization. By conducting a SWOT analysis, you can gain valuable insights into the product’s current state and future potential.

To perform a SWOT analysis effectively, you should begin by examining the internal strengths and weaknesses of your product.

Strengths (internal) are the unique qualities and advantages that set your product apart from competitors. These can include features, technology, brand reputation, or any other factor that gives our product an edge.

Weaknesses (internal) are the areas that need improvement or pose challenges for our product. These can include limitations, outdated features, or any aspect that may hinder success. By identifying and analyzing these internal factors, we can capitalize on strengths and work towards mitigating weaknesses.

Opportunities (external) are outside factors that have the potential to positively impact your product's growth and success. These can include emerging market trends, new technologies, or changes in consumer behavior that align with our product's value proposition. Identifying opportunities allows you to adapt your strategy to capitalize on them.

Threats (external) are external factors that can hinder your product's success or pose risks. These may include competitive pressures, changes in regulations, or evolving customer preferences that could negatively affect your product. By recognizing threats, you can develop strategies to mitigate or overcome them.

Involve client stakeholders, our internal stakeholder ans SMEs, and (potential) customers. Their perspectives and insights can provide a more comprehensive understanding of the product's SWOT areas. Seek feedback and encourage open discussions to ensure all relevant information is considered.

The add-on to SWOT is analyzing the relationships between strengths and threats, and weaknesses and opportunities. You’re looking for a way you can leverage good factors to mitigate the risks of bad factors.

PESTLE

We’re going very macro on this one. PESTLE analysis will help you make sense of the business context surrounding your product. SWOT works on product level, while PESTLE goes to the bird eye’s view.

As in SWOT, each letter of this acronym stands for one area of the macro environment that might affect your product. Here’s a list of those areas you should research. Once you have the insights, you can tag them as favorable (+), neutral (0) and negative (-) for you product.

PESTLE can also inform the external factors of your SWOT analysis.

Elements of PESTLE analysis:

Political Factors: Consider the political landscape and government policies that may affect your product or industry. Analyze factors such as regulations, trade policies, tax laws, government stability, and political ideologies. Understand how these factors can influence market entry, product distribution, or business operations.

Economic Factors: Assess the economic factors that can impact your product's success. Evaluate elements such as economic growth, inflation rates, exchange rates, consumer spending power, and employment levels. Understand how economic trends and fluctuations can affect demand, pricing, and market opportunities.

Social Factors: Examine the social and cultural aspects that shape customer behavior and preferences. Consider factors like demographics, lifestyle trends, consumer attitudes, social values, and cultural norms. Identify shifts in societal attitudes or emerging consumer needs that may present opportunities or challenges for your product.

Technological Factors: Evaluate the technological advancements and innovations that impact your industry. Look at factors such as emerging technologies, automation, digitalization, infrastructure, intellectual property rights, and data security. Understand how technology can disrupt or enhance your product and industry.

Legal Factors: Assess the legal and regulatory factors that affect your product or industry. Consider laws, regulations, compliance requirements, intellectual property rights, product safety standards, and labor laws. Understand how these factors can influence product development, marketing, distribution, or any legal constraints on your business.

Environmental Factors: Examine the environmental factors that can impact your product and industry. Consider factors such as climate change, sustainability, natural resource availability, environmental regulations, and consumer demand for eco-friendly products. Understand how environmental trends and concerns can shape consumer preferences and business practices.

If this sounds more like a management consultant’s work than product strategist’s, you’re 100% right. Still, this framework should guide your desktop research efforts. Instead of googling around hoping to stumble upon something, you know know what to look for.

And regarding management consultants, use their content as a source. Big Four and MBB provide valuable resources for free that can help you speed up this process.

Porter's five forces

Porter's Five Forces analysis is a powerful framework that helps you assess the competitive forces within an industry. It provides a structured approach to understanding the dynamics and attractiveness of the market in which your product operates. Ideally, your product will be moving into an uncompetitive market.

Here’s a breakdown of competitive forces that might affect your product:

Threat of New Entrants: Assess the barriers to entry for new competitors in your industry. Consider factors such as economies of scale, capital requirements, distribution channels, brand loyalty, and government regulations. Evaluate how easy or difficult it would be for new entrants to compete with your product.

Bargaining Power of Suppliers: Evaluate the power and influence of suppliers in your industry. Consider factors such as the number of suppliers, uniqueness of their products or services, switching costs, and availability of substitutes. Analyze how suppliers can impact your business by exerting pressure on pricing, quality, or terms.

Bargaining Power of Buyers: Assess the power and influence of your customers or buyers. Consider factors such as the number of buyers, concentration of buyers, price sensitivity, and availability of alternatives. Understand how buyers can impact your business by negotiating prices, demanding higher quality, or switching to competitors.

Threat of Substitute Products or Services: Analyze the availability and attractiveness of substitute products or services that can fulfill the same customer needs. Consider factors such as price-performance trade-offs, customer loyalty, and switching costs. Evaluate how easily customers can switch to alternatives and the impact it would have on your product.

Intensity of Competitive Rivalry: Assess the level of competition within your industry. Consider factors such as the number of competitors, market share distribution, industry growth rate, and product differentiation. Analyze how competitive rivalry affects pricing, innovation, marketing efforts, and customer acquisition.

Porter’s five forces are also one of the tools from business management consulting toolkit. They will broaden your horizon when thinking about the product and make your product claims more immersed in business than simple UX best practices.

You’ll understand who else is trying to make money doing the same or similar things as you do. Speaking the “business speak” is the way to have more sway with your client.

Executive summary

Client team needs to be able to show to their superiors. That's why the report is important. Keep in mind that people won’t study your report as they would a textbook in college. Keep it simple — write the executive summary, outline the discovery process and link the deliverables.

An executive summary should entail the key information that a C-suite decision-maker needs to make an informed decision. No more, no less. 10 slides tops.

It should be the first segment of your report. If someone reads just that, they’re already up to speed with key insights.

Things to include in the executive summary:

Biggest decisions you made during workshopping

Key findings from the workshop

Initial designs or prototype

User feedback if you held user testing

Product roadmap or some similar plan for the next steps

Market analysis or competitor review

Avoid things the client team already knew before your engagement, like recaps of their brief, the current state of the market, or their product. Focus on the value that you brought to them.

When you're holding an oral presentation of the workshop findings, you can use an executive summary as your slides.

Link other resources

Not all deliverables will look good on a slide or in the deck. Think: prototype, analytics framework, customer journey, product roadmap.

In those cases, provide key insights about those deliverables in the deck, and add a link for readers who want to explore those deliverables in more detail.

Make sure that the link you’re sharing is open and accessible by anyone, or make sure that client team members are on the allowed list.

Oral presentation

Workshops are a very intense experience that requires time and money investment from clients. You need to provide a closure to that experience.

The best way to do it is to arrange a handover session with the client where both workshop participants and their decision-makers will be present.

This is your chance to showcase the value you brought, and the good work that workshop participants on the client side have done and explain the next steps in our engagement with the client.

Start by presenting the executive summary – there, you should have all the key insights.

Sometimes, it might make sense to present another segment of the report after the executive summary—for instance, the most important user testing findings or phase of the product roadmap or the champion screen design, for example. This is up to you; just make sure you’re in the know which slides you want to show and what their content is so that your presentation seems smooth.

It is important to first ensure that the meeting is agreed upon and that the presentation doesn’t take too long. Remember that the stakeholder audience may not have been directly involved in the workshop so they may not take particular interest in the findings other than those that are relevant to them. Be sure to showcase the presentation in a way that is exciting and highlights the value in an easy-to-understand and structured story.

Amend your report based on people's comments during the handover session. Once you finish the amendments, send the report to the client.

This is your the bread and butter of every feature and product discovery. Preparing, leading, and reporting on workshop findings is also the core methodology of product strategy.

A workshop is the best way to build rapport with clients early in the project and strengthen their perceived competence and authority in the product domain. Other than the client’s team, our internal project team will be present, so you’ll be able to establish rapport with colleagues that will be crucial for delivering value to the client.

The word “workshop” is being thrown around more than AI, but what exactly is a workshop? It’s a set of structured activities that help you achieve a goal or find answers. Let’s break this down into smaller pieces.

“Structured activities”: you need to know why you’re deploying some exercise or game, how long it’ll take, and what materials and participants you need; it’s not an improv session. You’re in the driver’s seat

“Achieve a goal”: you must know what’s the end goal, what are the deliverables you need to provide to the client or our internal team

“Find answers”: some workshops won’t be about getting things done, but about learning something from the client or the customers. You need to know which questions to ask and why these questions are important product- and business-wise

Virtue signaling is a part of the appeal of workshops. They are an environment set up to make you shine and make you appear as a worthy partner to the client’s product and business team. Add some showmanship into your workshops, crack a few jokes, and make sure the client feels catered to. This is usually their first impression of you, so make it count.

Make other colleagues shine too. You’re the front person during the workshop but don’t forget that at some point, a PM or SA might take over. The client needs to get to know them and see them in the best light possible. How do you do that? Run the agenda by your colleagues, help them make their exercises more engaging, provide feedback on their deliverables and praise them during the workshop as experts in their field.

PMs and client managers send out project satisfaction surveys to clients and project teams to catch any problems and improve our processes. We do the same after each workshop - we ask for client feedback.

After creating and presenting the workshop report, prepare a Google form and send it over to the client. Ask all workshop participants to fill out the survey. It takes just 2 mins.

Make sure to send the survey within 7-10 days after the workshop. Memory fades quickly so we won’t be getting as actionable feedback as if we had asked early enough. Sending the survey is also one of the items in the Project Lifecycle board.

You’ve been added as a collaborator to the form, search “Workshop satisfaction survey” in Google Drive, and you should see it. Using the same Google form for all workshop feedback makes it easier for us as a team to track our performance and find workshops with good practices.

Pre-filled link

Before sending out the survey, you need to pre-fill some workshop-specific data: client name, project name, and type of workshop.
First, tap on the three dots in the top right corner. Then select “Get pre-filled link.”

A new window that looks the same as the standard survey response will open, but the button at the bottom says “Get link” instead of “Submit.” Add client name, project name, and type of workshop. And then click “Get link.” Here’s an example of a mock pre-filled link.

Important note: share the exact link that Forms created after you clicked “Get link.” If you copy the link in your address bar, load it, and copy and send it to the client, the pre-filled data will be erased from the link. The link will load a standard survey without the pre-filled data.

Once you agree the idea is viable, there are multiple questions you need to find the answers to, and, once again, there are desired answers to these questions. Getting such answers would mean we’re ready for the last stage – planning the product development and launch.

What would this solution look like when turned into a digital product? → We need to be able to prototype such a product rapidly and create a facade of the product that looks convincing to stakeholders.

How appealing is such a digital product? Does it resonate with our target customers? → When interacting with the prototype, the target audience should report that the product is intuitive and that it addresses some pain points they had recently.

What are operational and tech limitations we need to take into account? → We need to be able to identify limitations and have a clear plan of overcoming or mitigating them. Otherwise, the product isn’t feasible.

Ask the experts

You might cover expert insights before the workshop with the client. Still, there’s a huge value in letting client workshop participants ask questions to an expert in the domain and creating a joint set of insights.

The first thing is to identify experts who can provide you with insights on the client’s company and the domain. Some usual suspects:

CEO or CPO

Marketing managers

Customer support managers and reps

Sales managers and reps

Industry thought leaders and SMEs – this is easier said than done. You can leverage your own business network, look for SMEs withing Infinum or ask your colleagues if they know someone who’s an expert in that domain

Depending on the relationship you have with that expert, you might need to give them the incentive to join the call. These can be small ticker items like a voucher or a small gift.

You should plan 30-45 minutes per expert in your agenda. Usually, up to four experts are okay. Anything more than that, and you’ll start hearing similar things.

There’s no one-size-fits-all for questions you should ask the expert. But there are some guidelines when you’re preparing those questions:

Break it down into smaller sub-topics or themes: Prepare questions that address different aspects of the subject matter. May not be applicable to all clients and domains.

Practicality vs Vision: Practical questions focus on the current challenges, best practices, and actionable insights. Visionary questions encourage experts to think ahead and explore innovative ideas and future trends related to the topic.

Experiences and examples: Ask for specific examples or case studies from their professional experiences. This helps bring abstract concepts to life and understand how were solutions applied successfully in real-world scenarios.

Challenge assumptions: Go for counterfactuals and ask experts to challenge their or their industry’s assumptions. You’re looking for alternative viewpoints or potential risks and drawbacks.

Future opportunities and trends: Inquire about emerging trends, technologies, or market shifts that may impact the topic at hand. Encourage experts to share their insights on potential opportunities or disruptions in the future landscape and how they foresee the industry evolving.

Ideation and problem-solving: Ask them to brainstorm potential solutions, share their strategies for overcoming challenges, and discuss any lessons learned from previous experiences.
Ask the participants to keep their notes in the rose-thorn-bud fashion. Roses are positive things like trends that are beneficial for us; thorns are bad things such as pain points, and buds are things that could be opportunities in the future.

After each expert have a quick round of sharing insights and ask participants to stick their top 5 insights to the joint board. You want to avoid information overload, so you want them to filter out things that may not be that important.

Pre-mortem

Pre-mortem may seem like an intimidating name for an exercise but it is close to how it sounds. “Pre-” implies before and ‘mortem” means to die. A premortem assesses risks that could kill or destroy a product or idea.

It is important to gather this context from participants prior to a workshop to gauge their confidence in the product or idea, as well as to gather unforeseen information that may otherwise be concealed from you or your team such as some internal blocker, market news, or other inhibiting factors that could make the product fall of course or fail.

Two steps in creating a good pre-mortem document.

Get workshop participants' input before the session → There’s a template Typeform survey. Duplicate it and send it to both internal and external workshop participants. Be sure to brief the manager on the client side and request that it be complete prior to the workshop. If anyone forgets or doesn’t have time (this happens quite often) provide a 10 minute time slot during the workshop to allow participants to focus and complete this survey.

Use the session to comment on different risks and ideate potential solutions to address those risks

Our ultimate workshop template covers the goals and the flow of this workshop exercise. You should use it when preparing your agenda and workshop board (be it online or remote).

Lightning demo

Lightning demos are a great way to get the entire group to find apps and products that could be inspirations for ours. No, this doesn't mean just "copy your competitors".

Look for products from other domains that solve a similar problem for users as the app you're working on. For instance, both food delivery and fashion e-commerce apps solve a similar problem for users: find a thing that works best for them.

A lightning demo works by quickly covering the product, emphasizing the core features and functionality. It is best to start with a primary use case flow or two and walk others through it, describing each relevant feature along the way in brief detail.

Our ultimate workshop template covers the goals and the flow of this workshop exercise.

Evil and crazy 8s

The standard Design sprint exercises aimed at ideation. Don’t skip those – you’ll end up with a more diverse pool of ideas, and participants will be more engaged.

Evil and Crazy 8s quick overview:

Ask participants to fold an A4 paper three times, giving them 8 frames on that paper

Tell them they’ll have 1 minute per frame to draw an idea

It doesn’t need to be perfect, this is for their eyes only

Evil 8: the idea should break the product, make it worse for the users // Crazy 8: the idea should solve a problem for users

Once one minute is up, participants move on the next frame

Each new frame can either be a completely new idea, or an expansion of a previous idea

Once eight minutes are up, the exercise is done

Our ultimate workshop template covers the goals and the flow of this workshop exercise.

Sketch, vote, decide

The “put your idea to the paper” part of the process. These three linked exercises will help participants turn their ideas into actual sketches and allow you to set a course for the product prototype.

When you’re committing to a direction, make sure that the Decision-maker is there and that they’re okay with that decision. When in doubt, go for a riskier direction – you want to test it out by prototyping.

Our ultimate workshop template covers the goals and the flow of this workshop exercise.

Storyboard and prototype

Once you have the winning idea and product direction, you need to create a testing scenario. You’ll do it by creating a storyboard.

How to make a storyboard? Go back to your user journey and tag the most important touchpoints that you need to visualize to test out the idea. These steps need to create a coherent story of usage. Something relevant and real-life that the target audience would do when using your product.

Use sketches of the winning concept and add a placeholder post-it for the screen that you’re missing. Write down what the user is trying to do and what screen opens after they click on a specific part of the screen.

Once the storyboard is ready, write down the research questions you want answered on each screen. Comment on those questions with the workshop participants and define what’s the final set of questions. You’ll use those for user testing.

Prototyping is the next step. Align with the Designer on the user tasks the prototype needs to support. Go for up to four tasks to test out the concept. Make sure those tasks are relevant for real-life usage.

Concept test

Recruit five people that match your target persona. You want actionable feedback to your idea to people who are potential users. Don’t settle for stakeholder or internal feedback. This is the key moment of this stage – real users need to see and use your product so that you can validate the demand for such a product.

The user testing interviews are somewhat focused on usability (check Moderated usability testing chapter). Still, your main focus is to test the concept – i.e., does it resonate with the target users?

Your user testing session should have the following three segments:

Warm-up and checking if they fit the target audience: Start by asking people about similar problems/situations that you’re trying to address with your product. Make sure they feel comfortable talking to you and check if they actually match your target audience. It might be that they’re not a match, or they just might be a different segment. Make sure to note all of that.

Using the prototype: Send them the prototype and ask them to open it on a native device, be it mobile or desktop. Ensure they share their screen with you and that they think out loud as they’re solving tasks. You and other workshop participants should keep notes in a rose-thorn-bud fashion.

Follow-up questions: get their impressions while they’re fresh. Ask them if such a product would be useful to them in the past two or three weeks. If yes, then dig deeper, and understand if that situation fits your vision of the target audience. Also, ask them to compare your product to other products and services they’re using to solve a similar problem.

After five to six interviews, you’ll clearly understand whether or not people find your product appealing. The potential decision is to persist, pivot or perish. Don’t sugarcoat it to clients, be open and honest. They don’t want to invest money in something that won’t work and bring them back profits or savings.

Tech review

Involve a solution architect or a tech lead from the get-go. It’s not just strategists or designers who should be coming up with ideas. Our tech colleagues also have a creative spark, and they produce great ideas if you follow the steps outlined above.

The additional benefit of having a tech person involved from the beginning is that they can do a tech review of the idea. They can prevent the workshop team from chasing rainbows, and if the prototype is validated by the users, they can create an outline of the tech architecture.

This document is foundational for the last stage of the innovation process – planning the solution.

As-is user journey

An as-is user journey provides a visual representation of the steps, touchpoints, and interactions that a user goes through when engaging with a digital product or service. It captures the user's actions, thoughts, emotions, and pain points at each stage of their journey. By mapping out the as-is user journey, you can gain insights into the existing user experience, identify pain points, and uncover opportunities for enhancement.

As-is user journey doesn’t show the desired state of UX, but the current one. Don’t mix it up with the desired user journey because both client and our internal team will start jumping from two mindsets: exploration and solutionizing.

A good as-is user journey should have:

A clearly defined scope: you need to know when a journey starts and ends.

All user touchpoints: where users interact with the digital product or service. These touchpoints can include website visits, app interactions, customer support interactions, and more.

Context of each touchpoint: a visual representation of the user journey, highlighting each step and touchpoint along the way. Include key actions, emotions, thoughts, and pain points experienced by the user at each stage.

Opportunities and risks at each touchpoint: identify opportunities you can leverage and potential risks you’ll need to mitigate as you’re creating the new product

Service blueprint is an extension of user journey. It shows the inner workings of the client's organization that enables these user journeys. Similar to the association between a steering wheel and dashboard, and all engine parts under the hood. A service blueprint provides a detailed overview of the various components involved in delivering the service or app, including both front-stage and back-stage activities.

Here you can find a workshop template for running user journey exercise.

Service blueprint

A service blueprint follows a similar mapping blueprint (pun intended) as the user journey. You need to:

Define the Service Boundaries: Clearly define the boundaries of the service being provided. Determine the starting and ending points of the service/product delivery process.

Identify Service Components: Identify all the components involved in delivering the service, including customer-facing elements and back-stage (internal) processes. This can include activities such as customer interactions, technology systems, support processes, and any 3rd parties involved.

Map those insights into a single visual: Create a visual representation of the service blueprint, organizing the various components in a sequential manner. Indicate the interactions, inputs, and outputs at each stage of the service.

Highlight Pain Points and Opportunities: Look for opportunities to streamline processes, enhance communication, or introduce new technology solutions to enhance the overall service experience.

Personas are fictional representations of target users that are created to help you and the client better understand and empathize with their intended audience. They are detailed descriptions of typical users, including their characteristics, goals, needs, and behaviors.

Key thing: make sure that information included in the persona document is actionable and product-related. Too often personas are fluffy documents telling you that the target audience “watches Netflix in their free time”, which is an interesting factoid, but you can’t use it in any meaningful way.

There are 3 different ways in which you can build personas, depending on research (not) used to back up the data.

Proto personas — based on team’s existing assumptions about who their users are

Qualitative personas — based on small-sample qualitative research (e.g. interviews or usability testing)

Statistical personas — based on quantitative research (which ideally follows after the qualitative one)

Proto personas

Proto personas are created with no methodological research. They are built based on the team’s (sometimes educated) guesses of who their users are and what they want. The main goal of the proto personas is the quick alignment. They are particularly useful as a starting point during the discovery process as they help us build empathy towards the end users. Downside is that they can sometimes reinforce the echo chamber of incorrect team assumptions about users.

Qualitative personas

Creating personas through exploratory qualitative research is the most common approach when building user personas. This involves conducting user interviews with a mid-sized number of participants, typically ranging from 5 to 30, and then categorizing users based on common attitudes, goals, challenges, and expectations. The main drawbacks are that they do not indicate the proportion of the user base each persona type represents, and that we are (unconsciously) facing the risk of overemphasizing outlier perspectives.

Statistical personas

This is the most time consuming and skill sensitive way of developing user personas.
In this case we use our hypothesis and qualitative insights to create a survey, which is then distributed to a large user sample (ideally more than 100 participants). After distributing the survey, statistical analysis is applied to the responses to group users into similar clusters. This method reduces human bias in the clustering process, makes sure the outliers are not overrepresented and lets us know what percentage of our total user base and/or revenue each persona represents.

Buyer persona vs user persona

This is not the only way in which personas can be categorised. Based on the relationship the persona has with your product, we can further distinguish two other types: buyer persona and user persona. The former is the one making the purchase decision and the latter is the one actually using your product. Their needs, motivations and priorities might be different.

What should be included

Make sure your persona covers these key areas:

Name and Background: Give the persona a name and provide a brief background story that helps bring the persona to life. This includes relevant demographic information such as age, occupation, and location.

Goals and Motivations: Identify the primary goals, needs, and motivations of the persona. What are they trying to achieve? What problems are they seeking to solve? Understanding their objectives will guide product design and strategy decisions.

Behaviors and Usage Patterns: Describe how the persona typically interacts with digital products or services. What are their preferred channels, devices, and platforms? How frequently do they use these products?

Pain Points and Challenges: Identify the pain points, challenges, and frustrations the persona encounters when using digital products or services. Understanding their struggles helps in identifying opportunities for improvement and innovation.

Information and Content Preferences: Explore the persona's preferred sources of information and content consumption. Are they more likely to seek information through blogs, social media, or industry publications? This is highly relevant for buyer personas.

Decision-Making Factors: Understand the factors that influence the persona's decision-making process. What criteria do they consider when evaluating and selecting products or services? Also more relevant for buyer personas.

Quotes and Direct Feedback: Include direct quotes and feedback from real users that align with the persona. These quotes add a human touch and can be particularly impactful when presenting the persona to client stakeholders.

A qualitative and generative research method.

Rarely you might use it for evaluative purposes – the group dynamics might lead to biased, more extreme, or non-representative feedback to a product. Focus groups are a delicate dance of guiding people to riff of each other’s ideas without letting any single one of them take control of the group.

A focus group in UX research includes an active group discussion with a handful of product or service users. During this session, allow the participants to share their thoughts and opinions about a product or service.

In a focus group, a moderator (in most cases, you) leads the discussion and encourages participants to share their honest opinions, ideas, and suggestions. It's a brainstorming session where everyone gets a chance to speak up and bounce ideas off each other.

A focus group aims to gain insights into how people perceive and interact with a product or service. Participants may discuss their likes, dislikes, challenges, and desires related to the user experience. Participants can also share unique stories around their experience using a particular product, service, or component of them. It's a great way to explore different perspectives, uncover common themes, and understand the diverse needs and preferences of the target audience.

Focus groups are important because they provide qualitative data and rich insights beyond individual opinions. They help us, as well as designers, understand the collective voice of users, identify patterns, and discover potential areas for improvement.

It is important during a focus group to ensure that all participating members have time to voice their opinions and do not feel discouraged in doing so. Because of this, it is best practice that you source individuals who do not have a relationship with one another. Try your best to source strangers for activities like this.

If your direct and indirect competitors already have their products launched, you can use them as your learning platform. We do it by performing a heuristic analysis of these apps to gather as much data as possible in a structured and actionable way.

Heuristic analysis for both web and mobile is explained in the Evaluative research section.

Quant method that can be both generative and evaluative.

Intro

A user survey is a research tool used to collect data from a specific group of users to gain information and insights into various topics of interest. It usually consists of a series of questions that users can answer online, on paper, or during an interview. If you're aiming for a mix of quantitative and qualitative insights from a larger pool of users gathered in a timely fashion user survey is the right tool in your belt.

Depending on your goal, there are two main types of surveys:

User persona survey: Used when you want to do market research, understand your (target) customers better, and gather information about users’ demographics, behaviors, and attitudes. You can use the same pool of participants to ask around what your audience likes or dislikes about your competitors. This type of survey falls under the category of generative research and is usually conducted in the discovery phase of the project lifecycle. Combine surveys with user interviews to add depth to your insights.

User satisfaction survey: It allows you to quantitatively measure user sentiments while also capturing qualitative insights for deeper understanding. You can add one of the usability measures to your own pool of questions. Another advice is to use the questions to identify areas of improvement (“If you could change one thing about this product, what would it be?”).

Execution

There are a lot of tools you can use to conduct the survey. When doing research for a product that is not live yet, our tool of choice is Typeform. If you are interested in user feedback on a live product, and it supports tools like HotJar, Intercom, etc. — use it!

Introduction: Always start with a brief intro explaining the purpose, how long it will take, and how the data will be used. Note if the survey is NDA protected.

Demographics: These could range from age and gender to occupation and location. Aim for what is relevant for your target persona and their relationship with the product or industry.

Survey questions: This is the meat and potatoes of your survey. Craft questions that align with your research objectives. Be clear and concise to avoid confusion. Mix up question types—multiple choice, Likert scales, and open-ended questions—to garner both quantitative and qualitative data. Add standardized usability metrics to the mixture to benchmark your product.

Closing: Wrap up your survey by thanking the participants for their time and input. Provide them with a space for additional comments or questions they may have. Phrases like "Is there anything I forgot to ask?" or "Feel free to share any additional thoughts you may have" can be useful here. This not only closes the loop but may also provide you with insights you hadn't initially considered.

Types of Questions

Multiple-choice questions: Great for quantitative data and easier analysis. Offer options, but don't forget the 'Other' category.

Likert Scale Questions: These ask participants to indicate their level of agreement or satisfaction with statements. Ideal for attitude or opinion data.

Open-Ended Questions: As open questions are time consuming to analyze, serve these for more nuanced insights, such as understanding reasons behind a specific behavior or sentiment.

Tips and Tricks

Keep it Short: The longer the survey the grater the bounce rate. Aim for a 5-10 minute completion time.

Randomize Answer Order: When possible. You want to minimize response bias.

Mobile-Friendly: Make sure the survey is easy to complete on mobile devices.

Pilot Test: Always conduct a small-scale test run to catch errors or confusing questions.

Data analysis

Before analyzing the data, examine answers for outliers or anomalies. If you figure out some of your users wrote gibberish as a response, ended the survey way faster than the rest, or selected the a. option at every multiple-choice question — you might want to remove their answers.

On top of that, check if users misunderstood the questions. You don’t want faulty answers driving your insights and design in the wrong direction.

Once you have cleared the data, you can start analyzing it. Dive deeper into data. Filter & compare results by demographic data, length of using the product, and other relevant elements. Code verbal responses, create charts and graphs, calculate statistics, or do whatever helps you to understand survey results.

The goal is to identify patterns and trends in the data that can be used to make conclusions about the participants' opinions, habits, satisfaction, attitudes, and experiences.

Quantifying and benchmarking usability

Yes, you can (and should) measure the usability of your product. And yes, there are a lot of good and reliable measures that can help you do that usability health check better than the NPS.

There are several good reasons to use usability metrics:

They can help you compare different design options or products.

They can help you track the usability progress in time.

They are reliable and valid as most of them are standardized.

They will allow you to compare your results against the industry standard as they are norm-referenced.

Some usability metrics are geared towards evaluating specific aspects like user flows, designs, or features. These include quantitative measures such as single ease question (SEQ), error rate and task completion time, which are elaborated upon in the usability testing chapter.

On the other hand, we have more complex psychometrically standardized questionnaires. These are tailored to measure the effectiveness, efficiency, and user satisfaction of the product as a whole, serving as ideal instruments for periodic health checks or industry benchmarking.

Here are some of the questionnaires you can pick from:

SUS: System Usability Scale is one of the most used usability metrics that works better with complex systems and applications.

SUPR-Q: Standardized User Experience Percentile Rank Questionnaire measures usability, trust, loyalty and appearance and works great on websites.

UMUX: Similar to the SUS but is shorter and targeted toward the ISO 9241 definition of usability (effectiveness, efficiency, and satisfaction).

UEQ: User Experience Questionnaire is available in Croatian, in longer or shorter for, and measures attractiveness, perspicuity, efficiency, dependability, stimulation and novelty.

System usability scale

The System Usability Scale (SUS) is a widely accepted scale, used and validated in a variety of contexts, making it a reliable and valid instrument for measuring usability. It provides a quick and easy way to gather user feedback and assess the overall usability of a product or system.

The SUS consists of a 10-item questionnaire that asks users to rate their level of agreement with various statements about the usability of the product or system.

The statements are designed to measure different aspects of usability, such as ease of use, learnability, and satisfaction. The responses are given on a 5-point Likert scale, where 1 represents "strongly disagree" and 5 represents "strongly agree."

System usability scale questions:

I think that I would like to use this system frequently.

I found the system unnecessarily complex.

I thought the system was easy to use.

I think that I would need the support of a technical person to be able to use this system.

I found the various functions in this system were well integrated.

I thought there was too much inconsistency in this system.

I would imagine that most people would learn to use this system very quickly.

I found the system very cumbersome to use.

I felt very confident using the system.

I needed to learn a lot of things before I could get going with this system.

The SUS is unique in that it provides a single score, called the SUS score, that represents the overall usability of the product or system. The SUS score is calculated by summing the ratings for each item and multiplying by 2.5. The final score ranges from 0 to 100, with higher scores indicating better usability.

Interpreting SUS scores can be done by comparing it to a benchmark score or by comparing it to a previous score. A score of 68 or higher is considered to be a good score and indicates that the product or system is usable. Scores below 68 may indicate that there are usability issues that need to be addressed.

It's also important to look at the individual item scores and the patterns of the responses, in addition to the overall score. This can help identify specific areas of the product or system that need improvement.

A qualitative method and a generative method.

Stakeholder interviews are structured and moderated conversations with key individuals who have a vested interest or influence in the user experience of a product or service. Occasionally, you might use it as an evaluative method, but in these cases, this will be more similar to usability testing than a stakeholder interview.

These stakeholders typically include:

Owners and executives

Project managers

Developers

Designers

Marketers

Customer support representatives

any other relevant parties involved in the product's development and success.

It is important to note that not all stakeholders are the ideal end-user. However, their opinions should be considered as they are almost subject matter experts or key decision-makers.

Stakeholder interviews provide an opportunity to gather unique insights, perspectives, and requirements from these individuals to inform the UX design process. These interviews help product and product strategists, researchers, and designers understand the business goals, key objectives and metrics, expectations, constraints, and priorities set by stakeholders. They also provide an opportunity to align everyone's understanding of the target audience, business objectives, and project scope.

During the interviews, UX researchers or designers ask questions related to the stakeholders' roles, responsibilities, and their understanding of the user experience. Check out our stakeholder interview questions database (🔒Internal use) when preparing the script.

Topics to explore:

business goals

target audience demographics

desired user behaviors

competitive landscape

technical constraints

brand guidelines

existing user research or feedback

UX stakeholder interviews are essential for several reasons:

Aligning Objectives: They ensure that the UX design process is aligned with the goals and expectations of all stakeholders. Understanding their perspectives helps in creating a shared vision and setting realistic design objectives.

Gathering Requirements: Stakeholder interviews provide valuable insights into the specific requirements, constraints, and priorities that need to be considered during the design process. They help in understanding what stakeholders consider important for the success of the product.

Building Relationships: Engaging stakeholders through interviews fosters relationships and establishes open communication channels. It creates a collaborative environment where stakeholders feel involved and valued in the design process.

A qualitative method that can be both generative and evaluative. Some might call it “googling,” 🙂 But it actually goes beyond that.

Desktop research or independent research refers to the body of work you conduct in preparation to core research which occurs with a client, remotely or in-person. Desktop research enables you and the UX team to become better equipped with information needed in order to successfully complete work in a timely and professional manner.

Many times you or other team members may lack the domain knowledge needed in order to be effective at the highest level so it is important to ensure that you have sufficient domain knowledge of the topic at hand as well as have researched with the necessary tooling that may be used prior to the core body of work being conducted.

To avoid “just googling stuff”, here are a few resources you should check when doing desktop research:

Management consultants’s articles and opinion pieces: cover Bain, McKinsey, BCG, KPMG, E&Y, Delloite and PwC

Google "your industry" market research trends: try looking for both idustry as a whole and digital part of it (make sure to check Gartner)

Ask GPT about your competitors: you can even ask it to browse and compare their websites or tell what people like or don't like about them

Academia articles: SSRN, Google Scholar and Web of science are all great sources of academic research that might come in handy

Search trends: visit Google trends, and check what have people been searching for that related to your product’s domain

It’s time to add some details to the lean canvas and turn it into a bigger solution-market fit narrative. This analysis and type of interview come from Reforge, with some slight tweaks on our side. Reforge calls this product-market fit, but given the content it is better to see it as a more generic solution-market fit.

There are six pillars of solution-market fit:

Problem to solve: explain the problem in as much detail as possible. You can break down the problem into primary and secondary sets of problems. Try using the same words as the target users use to describe the problem.

Target users: describe how the envisioned user (and the buyer if they’re separate people). Start with demographics, but focus also on psychographics and behaviors exhibited by target users. You can lay out short-term and long-term audiences if you expect it to change over time.

Value proposition: the key part of your document, describes what the product will offer to customers and it needs to be obvious how the value prop is connected to the problem to solve.

Competitive advantage: this is where all that business work in the previous stage comes in handy. Explain why we’ll beat competitors both in short- and long-term. The advantages might not be the same for these two different time horizons.

Growth strategy: explain how you plan to acquire new users to make the user pool growth sustainable. Think about short-term and unscalable channels and also about long-term scalable ones. Both can serve their purpose in winning over customers and market share.

Business model: dive deeply into the revenue side of things – define how you will charge for your services and define metrics you need to measure to be sure you’re on the right track.

There’s a simple and streamlined template from Reforge you can use to create a solution-market document. It’ll guide you and ensure you won’t miss out on any relevant data.

This narrative document is your hypothesis; you should think of it as a living organism, not something set in stone. You’ll use it to run a solution-market interview with your hypothesized customers. These interviews can take anywhere between 40-90+ minutes so be prepared to be in there for the long haul.

At its core, this interview validates the hypothesis you laid out in your narrative document. Two potential ways these interviews might go: you tick all the boxes and validate the solution-market fit, or some of the hypotheses are invalid. In the second case, you can use a secondary set of questions that can help you pivot the product.

Interview template (🔒Internal use) and interview observations template. You’ll need to tweak and tailor these documents to ensure they fit your specific client's needs.

Introduction

A user interview is a generative and qualitative research method. It’s a part of UX research where you swap out your lab coat for a detective's hat. It's a chatty, qualitative way to get inside the heads of your users or potential users. Consider this your first coffee date with users to get to know them better.

The goal is simple: Get rich, detailed info without making it feel like an interrogation. You want the "why" behind the "what," the stories behind the statistics. Knowing your users' motivations, pain points, and needs is a good baseline for a product users will genuinely value.

We usually go for semi-structured interviews. Think of it as a casual coffee chat but with a few talking points written down in your notes. You have some preset questions to guide you, but if the conversation naturally drifts toward something interesting, you’re free to wander. The script isn’t your master; it’s more like a trusty sidekick.

Our scripts, which you'll see later in this chapter, focus on open-ended questions. Let the users talk. These aren’t yes-or-no quizzes; we want the interviewees to elaborate their point of view. It’s ok even if they ramble a little.

Not all interviews are created equal. Depending on what you're after—nailing down a product-market fit, capturing the thoughts of potential users, or checking in with your longtime users—you'll want to tweak your approach. But don't worry, we’ve got guidelines for each scenario coming up.

Interview execution — Product-market fit interviews

Product-market fit interviews are a type of user research method that is specifically designed to understand if a product or service meets the needs and wants of its target market.

The goal is to validate our hypothesis about user problems and the solution that your product offers.

Validating the problem consists of asking participants to list all the problems they’re facing in that specific situation. You’re hoping they’ll spontaneously mention the problem you’re targeting and then they’ll place it high on the list of their priorities.

Validating the solution consists of asking users to come up with ways of solving their problem. You’re hoping that their ideas fit your vision of the product. Additionally, you’ll explain your product and see if they think it seems like a good solution to their problem.

There’s more nuance to this type of interview, and you can check all the sections of PMF interview in this template.

These interviews are typically conducted early in the product development process, before a product has been fully developed, in order to validate a new product idea, understand the market for existing products, identify areas for improvement and new opportunities.

Additionally, these interviews can also be used to validate a new feature, service, or design change.

You can find a script template for the product market interviews here.

Interview execution — Interviews with potential users

We typically roll these out during the discovery phase, and for good reason. We're on a quest to decode the habits, secret desires, and vocalized frustrations of an audience who hasn't yet gotten their hands on our product or service.

Interviews are a cornerstone of the discovery phase. But that doesn’t mean they’re not valuable at later stages. They can also help you refine the user experience, validate new features, or re-evaluate existing assumptions.

Use our tailored interview script designed for potential users. It's broken down into three sections: Introduction, follow-up questions, and the heart of it all, the interview questions. But remember, every research project has its own flavor. Toss in questions specific to your domain and feel free to prioritize. Given you’ve only got about an hour for each interview, it’s a game of “Pick Your Battles” when it comes to questions.

As you sift through the interview data, you'll start to see patterns that will help you sketch out who your users are and how they navigate their way around problems.

To wrap up the round of interviews, revise or build the user persona and user map document based on the new insights.

Interview execution — Interviews with existing users

Think of interviews with existing users as a pulse check for your product. It's all about evaluating the current state of the relationship: Is the product still fulfilling the user's needs? Are there any friction points or room for improvement? The aim is to gain insights into how satisfied and loyal your users are.

Once again, you can use our tailored interview script designed for potential users. It's broken down into three sections: Introduction, follow-up questions, and the heart of it all, the interview questions. As always, every research project has its own flavor. Toss in questions specific to your domain and feel free to prioritize. Given you’ve only got about an hour for each interview, it’s a game of “Pick Your Battles” when it comes to questions.

For more structured feedback, consider incorporating desirability testing or other standardized UX questionnaires like SUS into your interview questions. These can offer quantifiable metrics to complement the qualitative data you gather, giving you a more holistic view of user satisfaction.

Turning conversations into actionable insights: Analyzing user interview data

So you've wrapped up the interviews and are now sitting on a mountain of qualitative data. It’s tempting to just hand it off to the team and say, "Make sense of this!" But hang tight. Your data needs to be sifted, sorted, and translated into insights that people can actually use. And yes, always keep your original research questions and objectives in your line of sight; they're your north star in this analytical journey.

The process of organizing and categorizing research data is called coding. Coding involves identifying and labeling meaningful segments of the data, such as specific quotes or themes, with a code or label.

Coding can be done along multiple axes. The Axis that is often used is the “feature axis”. This means that you will categorize your insights into categories that represent your features or flows, like “Onboarding”, “Registration”, or “Pairing the device”.

The other, “UX axis” should represent different aspects of user experiences and interactions. Erika Hall in her book “Just enough research” mentions that qualitative insights can be categorized in one of the following categories:

Goals: what your target users/research participants intend to accomplish which your product or service is supposed to help them with?

Priorities: what is the most important thing to the participant?

Tasks: these are the actions the participant would take to reach their goals.

Motivators: the situation that triggers the actions for the tasks.

Barriers: the challenges that would get in the way of the participant doing the task and accomplishing their goal.

Habits: what are their established patterns of behavior; things they do regularly.

Tools: these are objects the participant interacts with while doing the task.

Environment: what is going on presently that would affect or influence the participant’s desire and ability to accomplish their goals.

Relationships: the people the participant interacts with while doing the tasks.

If you are feeling creative and see the need to use different or additional UX-focused categories, feel free to go wild.

Once you’ve applied these codes or labels, it's time to get comparative. Look at your data through different lenses—be it age, user role, gender, or any other metric that's relevant. To get an even fuller picture, cross-reference these findings with other data sources you might have, like Google Analytics.

Once you are done coding, check for the patterns and themes that emerge from the categories. And last but really not least — convert them into actionable insights. Communicating these findings in a way that everyone can act on. Whether it’s the designers, the product owners, or other stakeholders, make your insights understandable and actionable. For a deeper dive into the "how-tos" of reporting, be sure to check out the dedicated chapter on that topic.

User interviews — tips and tricks

Ah, user interviews. While they can seem straightforward, anyone who's conducted one knows that each is a unique experience that can either soar with grace or stumble into awkwardness. To help you stay more on the "soaring" side of things, here are some tips, tricks, and best practices.

1. Do Your Homework: Know Your Users:
Before stepping into the interview room (real or virtual), make sure you’ve done your homework. Know who you're talking to. This doesn’t mean you need an FBI-level background check, but knowing a bit about the interviewee’s role, experience, and context can provide invaluable insights.

2. The Right Environment: Set the Stage:
If you're interviewing in person, make sure the setting is comfortable and free from distractions. For remote interviews, double-check your tech set-up. Nothing kills momentum like a dodgy internet connection.

3. The Art of Listening: More Than Just Hearing:
You’re not just there to ask questions; you're there to listen. That means not interrupting, no matter how eager you are to dive deeper into a point. Often, the most valuable insights come from letting the conversation flow.

4. Keep It Casual: Conversational Tones Work Wonders:
The interview should feel like a conversation, not an interrogation. Keeping a friendly, informal tone can help participants feel more comfortable and more willing to share.

5. Mastering the Follow-Up: The Delicate Art of “Tell Me More”:
When a participant mentions something intriguing, don’t hesitate to deviate from your script for a deeper dive. Follow-up questions like "Could you elaborate?" or "Why do you feel that way?" can unearth some gems.

6. Maintain Neutrality: Be the Switzerland of Interviewers:
It's easy to influence responses without even realizing it. Be mindful of your body language and vocal intonation. Strive for neutrality to ensure you're collecting unbiased data.

7. The Summary Play: Confirm Your Understanding:
Near the end of the interview, summarize key points back to the participant. This not only shows you've been listening but also gives them a chance to correct or clarify.

8. Take Great Notes: Your Future Self Will Thank You:
Whether you’re jotting down notes or recording the session for later transcription, make sure you capture all the nuances. This is raw material for your coding process later.

9. Seal the Deal: Conclude Professionally:
Thank your participants, reassure them about the confidentiality of their responses, and let them know the next steps on getting their incentive or how their input will be used.

10. The Post-Game Review: Reflect and Adjust:
Once the interview is over, take a few moments to reflect. What went well? What could be improved? Each interview is a learning opportunity for the next.

Define the target population

The first step in recruiting participants is to define the target population. You can use persona documents or google analytics reports to identify the specific characteristics of the users you want to recruit. For example, you can set age, gender, occupation, or location as screener criteria. Add psychographics into the mixture too. Think in terms of behaviors, lifestyles, experience with a specific technology and other factors that might influence people’s attitudes toward your research subject.

Also, It is important to have a diverse group of participants to ensure that the data collected is representative of the overall population.

Define number of participants

Number of participants needed for a user research can vary depending on the context and method. If you are conducting a qualitative study, for each persona type you should aim for around 5-8 participants. A diverse range of perspectives and experiences can lead to more robust and reliable findings. If you are conducting a quantitative study, or any other unmoderated study, a larger sample size (n>30) is welcomed. It can help you minimize the impact of outliers and chance events. When recruiting the participants, keep in mind that the average response rate is something around 10%.

Pick your recruitment tool

You have many options to recruit the participants:

ask your client if they have access to the end or target users

use steps from the Prolific chapter to recruit non-croatian participants

use our internal database to recruit participants from Croatia

if the product is live, you can use Intercom HotJar, or similar tools to recruit participants

use #infinum Slack channel and ask if they happen to know someone who fits the target audience

be creative and use social media groups and personal networks to recruit the right people.

Tweak your screener criteria depending on the recruitment tool’s offer

Depending on the offer, you might need to tweak the criteria you have set. Some recruitment tools (Prolific, for example) support more complex screener criteria, such as hobbies, experience with a specific technology, health issues, employment sector, etc. Most of the other ones stick with the basic demographic data.

Use incentives

Offering incentives can be an effective way to attract participants to your research. These incentives can include monetary compensation, gift cards, merch bags filled with t-shirts, cups, socks… or other rewards that you arrange with your client.

Prepare an NDA and consent to participate in the study

If you are using Prolific or Useberry you can follow the instructions in the dedicated chapter. If you are using any other tool or method — you should add a new Productive task on Human Resources: Administration - shortlist. Set the task in private, list participant's email addresses in the description, and attach the versions of NDA and Consent that participants need to sign. Colleagues from HR will ping you as participants start signing the documents.

Generate a scheduling link (if you are conducting a moderated study)

Use Google Calendar’s appointment scheduler. Generate a link using which your participants can select the time slots that work best for them. Keep in mind that our users work and live all over the world, so try to be flexible and offer options that are not in the middle of the night for your users. If you’re using Google appointment scheduler, make sure to set up a few reminders to be sent to participants. A day, an hour, and 30 minutes before might be the best combination.

Send the invitation out!

Send out reminder & prep email to the scheduled participants (if you are conducting a moderated study): Adjust the 🔒 prep email for your needs and send it out, so participants know what to expect and prepare for the session.

Research methods can be divided into two main groups: generative and evaluative.

Generative research methods are used to gather knowledge: discover new insights and ideas about business, users and their needs. These methods are typically conducted early in the design process, before a product or service has been developed, in order to inform the design and development of the product or service. Some examples of generative research methods include user interviews, card sorting or ethnographic research.

Evaluative research methods are used to test and evaluate specific design solutions or prototypes. These methods are typically conducted later in the design process after a product or service has been developed in order to identify areas for improvement. Some examples of evaluative research methods include usability testing, tree testing, or A/B testing.

Methods can be split among the quant-qual axis as well.

Quantitative research methods require a bigger pool of participants (30+) and offer you reliable results.

Qualitative research methods require less participants and go into more depth. You’ll learn more about the why’s of people's behavior. But generalizing your findings is a tricky thing. Your sample will be 5-10 people, so you need to tread lightly when using those insights.

For the purposes of this Handbook, we’ll stick with the generative-evaluative split. To add some confusion to the mix, in most of the cases — the split is not clear. For example, you can use survey both to generate more information and to test your hypothesis.

A qualitative and evaluative method.

360º Expert App Audit is a heuristic evaluation process that relies on Nielsen Norman and Rolf Molich usability principles enriched with custom categories from a broader user and business perspective.

Heuristic evaluation is a structured approach to testing the apps' usability by considering known heuristics.

We use it to eliminate significant usability and growth issues without involving real users.

Who

You will need at least 3-5 experts to do the 360º Expert App Audit. It does require at least one experienced evaluator. From the Infinum team, you are looking for Product Strategists, growth, QA, and other UX specialists. From the client's team, you are looking for a marketing specialist, product manager, content specialist, etc.

To prepare for the analysis, we suggest you get acquainted with 10 Usability Heuristics for User Interface Design by Jackob Nielsen.

360º Expert App Audit and Website heuristic analysis are the only two user research methods we conduct — without users. This is because they rely on frameworks that consider well-tested and proven usability principles (heuristics). So the focus is still on the user's reality.

When

You can do the 360º Expert App Audits in any phase of the app's lifecycle. For example: use it in the wireframing phase as a checklist to make sure all the usability principles are being taken into account or in the optimization phase of an existing app with active users.

Examples of use cases for the 360º Expert App Audit:

Sales phase: We offer it (maybe even for free) to assess the potential areas of involvement with a client. We come back with a backlog of items that can be turned into workshops or other production work.

Part of the prep for Product strategy workshop Tier 2 and 3: We sell this audit as part of prep activities for a larger workshop. Requirement: client needs to have an already developed app

Silent review of a current product we're working on: Instead of saying publicly to a client that we've messed up some things, we do this internally. And then use the findings and ideas to upsell work and overall raise the quality of the app.

Overt review of a current product we're working on: If we're in an okay relationship with the current client, we can do this in tandem with them. This means the whole process is upsold, not just the outcome as in use case 3.

How

Part 1 — preparation (4-8h/person)

Do the research regarding the app you will evaluate - what is the app's goal, the main functionalities and features, and target audience/personas.

Once you know everything about the app goals, organize the heuristic analysis workshop. Schedule two hours to do the workshop and invite all the stakeholders that will participate in the audit.

Decide who will be facilitating the workshop, and prepare the sheet framework and the FigJam board. We suggest that every evaluator does the work in a separate sheet, as we all like to adjust to others' opinions.

Part 2 — the session (3-4h/person)

So, this is what the sessions look like:

Take 10 - 15 minutes to meet, chat, loosen up, and build the rapport

The person leading the workshop should debrief the rest on the motivation, agenda, goals, and the frame of the workshop

Tell the evaluators to go to their assessment sheet and put focus on the first category

Everyone's task is to read the statements of the category in focus, go through the app, and rate how much the statements describe the app on the level from 1 to 100

Stay on the call so everyone can ask questions and clear the misunderstandings

Feel free to tell the evaluators to put your thoughts, arguments, and ideas in the comments of the assessment sheet they will help you have the complete picture later on in the process

When you are all done with the first category, continue to the next one, and if you are the workshop facilitator, don't forget to manage the time

After the analysis using the questions stated in sheet, you will have a quantitative overview of how well your app performs in these 10 categories:

Pre-installation experience: Do users think this is the right app for them? Matching the app representation on the App and Play store with the app functionalities and target audience.

Activation & Onboarding: Making it as simple as possible to onboard users. Complicated onboarding processes can make the app lose users before they experience the benefits.

Information architecture: Do users know where to tap and what to do? Every app user wants to be able to find what they are looking for easily and quickly. Visible navigation and CTAs will help users navigate the app and use the features.

Visual design: Clear and well-structured UI. Visually appealing and clear design, readable fonts, and smooth transitions are necessary.

Usability: General principles for interaction design: How easy a product is to use—how easily a user can accomplish a given task with the app.

Motivation: Stimulating and motivating users to use the app. Meeting the user's goals with features and functionalities and making the experience fun and enjoyable.

Content & text: The clarity in communication and instructions. Relevant and clear content, concise communication throughout the app, and a positive and cheerful tone of voice.

Privacy and trust: Data sharing options. Handling user's data sharing, permissions given, and the possibility of opting out of data sharing.

Error handling & prevention: Avoiding errors and giving users the option to recover from them with clear instructions.

Growth opportunities: Assuring the app has users actively using it. Acquiring new users, and re-engaging with those who stopped using the app.

The most probable outcome is that you will wrap the analysis up by realizing the app has some potential for improvement. And you will ask yourself — what do I do with these results now?

Part 3 — make it actionable for homework(2-3h/person)

End the session by giving the homework to the evaluators.

Guide them back to the FigJam template you have prepared. Split the categories among yourselves. Show the basics of FigJam to the evaluators and tell them their homework will be to:

Think about how well the app performs in a category they are assigned to

Take some screenshots and put some notes that describe the current status of the app

Do some desktop research and find examples you can look up to

Paste some screenshots and post some sticky notes that picture the improvement suggestions

Part 4 — prioritize & wrap up (2-3h/person)

Meet again and:

Build the value-effort matrix by evaluating each suggestion's sticky note on the two dimensions (how valuable the improvement would be for the business and how much time, money, and effort they imply)

Decide who owns what, put it on the roadmap, and start working on the quick wins! When building the value-effort matrix, keep that in mind.

Why

You can do the 360º Expert App Audits whenever you want to test the UX, content, design, or growth opportunities of an app. You might notice that you might test the same thing by doing usability testing. So, what's the difference between usability testing and heuristic analysis, and why would we ever use heuristic analysis?

Well... Usability testing will only get you the answers about people's reactions and behavior they are aware of. They don't always tell you much about deeper, subconscious principles.

Moreover, the fact that the people know they are being tested changes their behavior and answers. The discrepancy between people's socially desirable responses and their real behavior might lead you to make faulty assumptions and build a product that isn't what you looked for.

The advantage of heuristic analysis in this context is that it considers subconscious principles. It relies on a structured, tested, and proven heuristics framework.

Advantages

Time & cost-efficient method

A structured approach based on proven principles

Results in clear action points

Gives a client both usability and app growth ideas

Disadvantages

The quality depends on the experience of the evaluators

It is easy to fall into the trap of thinking you know all about your users

Introduction

Card sorting serves as a hands-on tool for understanding the user's mental model, directly informing the development of a website's or application's information architecture by revealing how users naturally group and categorize content.

You can use card sorting to:

Build your product’s information architecture

Evaluate your product’s information architecture

Get inspiration for labeling and grouping content or ideas

Three types of Card Sorting

There are three types of card sorting:

Open Card Sorting: Participants create their own categories. Excellent for an early-stage project where you're figuring out the basic structure.

Closed Card Sorting: Participants sort cards into predefined categories. Useful for tweaking or validating an existing structure.

Hybrid Card Sorting: A combination of open and closed. Allows for the most flexibility and is particularly useful when working with complex interfaces.

How to conduct a Card Sorting session

During the study, participants are given cards, each containing a topic or feature, and asked to group them into categories. This can be done using actual cards, virtual post-it notes, or you can just use Useberry. Whichever tool you are using,

When it comes to the number of participants you will need to recruit, the type of card sorting you choose makes a significant difference. Closed card sorting tends to be more quantitative. To make your data statistically meaningful, you'll need a more substantial participant pool—think at least 30 people to give you numbers you can really crunch. On the other hand, open card sorting is more qualitative and you can get by with fewer participants. A group of 6 or more can provide rich, detailed insights that can help you understand their mental models.

Choosing between open (qualitative) and closed (quantitative) card sorting isn't the only fork in the road; you'll also need to decide whether to go the moderated or unmoderated route. Here's a quick guide to make that choice a bit easier.

If you're leaning towards open card sorting and have the time and resources, consider moderating the sessions to dig deeper into users' thought processes. Short on time? Simply send out the link and add a follow-up question asking participants to explain their reasoning and any dilemmas they faced.

For closed card sorting, if your time and budget allow, moderate a couple of sessions—say, about 5 to 7—and send the link for the rest. If you're stretched with time and budget, send the link with the follow-up question to all participants.

Data analysis

Begin your card sort analysis with a bird's-eye view of the collected data. Take a moment to scan through the categories and choices. What grabs your attention? Is the user's mental model similar to what you have expected to see? What comes as a surprise? Do you see any patterns?

If you've gone the quantitative route, you're likely looking at a decent-sized dataset. In Useberry, you will see the agreement rate (percentage of users who placed a card in a certain category) and similarity matrix (overview of how often two different cards were put in the same category) as primary visualization of the results. They are crucial tools in designing your information architecture and are pretty straightforward at identifying the most common groups and belonging items.

On the other hand, the open card sorting results are not that straightforward. It can be challenging because every participant has their own way of categorizing and labeling content. You will end up with a variety of unique structures and labels. While Useberry will auto-merge some categories, you'll be doing a fair bit of manual merging (standardization, as they call it) too. Some will be no-brainers, like combining "bills" with "payments," but others will require a bit of, well, educated guesswork. Once you clean the data and merge the similar categories together take a look at the agreement rate and similarity matrix. These metrics will guide you, just as they do in closed sorts.

Bear in mind, that Useberry has some limitations when analyzing more complex information architecture structures (the ones that have 3 or more levels). In this case, you would need to use Optimal Workshop (ETR toolstack) or export the csv file from Useberry and use Python or R to plot a dendrogram. Don’t run away before you even start, we did a few times before and you would only need to do it if you are reviewing a more complext information architecture (e.g. the whole app). Ping us in the internal channel, and we’ll lend you a hand.

Card sorting tips & tricks

Pre-test Your Cards: Before the main event, run a quick test with a few colleagues to make sure the terms on the cards are clear and understandable.

Limit the Number of Cards: Too many cards can overwhelm participants. Aim for not more than 30-40 cards, depending on the complexity of the information.

Use Clear and Concise Labels: Avoid ambiguity; the terms you use should be easily understood.

Randomize Card Order: When presenting cards to participants, randomize their order to prevent any bias.

Encourage Thinking Aloud: In moderated sessions, ask participants to verbalize their thought process. This can provide invaluable insights.

Quick Debrief: A short conversation or a follow-up question post-sort can get you insights that might not be evident from the sorting data alone.

Tree testing

Intro

Tree testing, also known as reverse card sorting, is a method used in user research to evaluate the effectiveness of a website's navigation structure. It is a way to test how well users can find information within a website by testing their ability to locate specific pages within a website's proposed navigation structure.

Execution

To prepare for a tree test, you might have to create a sitemap of the software’s proposed navigation structure. The sitemap should include pages of the software you want to test, organized into a hierarchical structure. Designers and QA experts can help you outline the structure.

In a tree test, participants are presented with a website's proposed navigation structure, usually in the form of a sitemap, and asked to find specific pages within the structure.

Tree testing tasks should be written from a user perspective. Their goal should match user needs and objectives and be representative of the types of tasks that users would typically perform on the website.

Tree testing can be part of the usability testing study. You can use Useberry to conduct it.

Useberry doesn’t tell participants if they found the correct part of the app. So after each task, ask them how sure they are that they found it and how easy it was to find it.

Data Analysis

The data collected from the tree test can be analyzed to identify patterns and trends. Look for patterns in the data that may indicate issues with the overall navigation structure. For example, if many participants have difficulty finding specific pages, it may indicate that the navigation structure is not intuitive or that the labels used are not clear. Longer time taken to complete the task can also be a sign of an issue.

By identifying these issues, you can make recommendations for improvements to the navigation structure to make it more user-friendly.

Quantitative and evaluative method.

Usability is the ability to use a product with ease. When we talk about usability, we ensure that products are easy for everyone in any usage context. It should be evident to people where they are, what they are supposed to do next, and that they are able to complete the necessary task.

From the design perspective, we want our users to have a product that is easy to use without much thought and any frustrations.

This chapter goes into a lot of detail about user testing. To make it easier to implement best practices, we've created a template project in Productive (🔒Internal use). In the Design Phase board, there's a task list called Validation. Ping your TL to give you access to it.

Usability testing is a direct way of seeing how users interact with our product.

In usability testing, we show the clickable prototype to one user at a time (whether it's a mobile or web app), and we ask them to:

figure out what it is

try to use the prototype to do a typical task

find some critical information

Usability Testing is crucial because it can help us learn if our product is really based on users' behaviors and expectations. This leads to many ideas for improving the design. We usually perform “task testing” — we ask the user to do complete a task, and then we observe how well they do.

We can divide usability testing into 3 phases:

Setting up — planning and preparing everything we need for testing

Conducting usability testing — moderated or unmoderated sessions with the users

Analysis — provide actionable insight to the client and our team

The following paragraphs will guide you through each of these phases.

Setting up

Follow the usual user research preparation steps

Prepare tasks — After the client approves the agenda and after the responsibilities are assigned, the facilitator starts to prepare tasks and prototype(s). Be wary of the wording you're using on tasks; you don't want to give away the answer by mentioning the exact copy that is visible on the screen. For a more in-depth study of this process, take a look at NNG’s guide.

Prepare your prototype for Useberry

Prepare Useberry

Conducting usability testing

Before the official user sessions, it's crucial to conduct a test run to identify any smaller issues and possible improvements. The test run can be simulated in two settings based on the type of usability testing you're conducting: moderated and unmoderated.

Set up a prototype or version of the website/platform that users can interact with independently. Send the link to someone from Infinum just as you would to the research participant and tell them to provide feedback if anything was unclear, buggy or confusing.

We conduct test runs to identify and rectify any smaller issues or room for improvements before carrying out the actual testing.

Analysis

When you get all the data, review the rating table, Useberry's report, the observer's notes, and video recordings.

Build your report around these:

Percentage of success for each task

Ease of use for each task

Pain points from your notes of participants thinking out loud

First clicks or taps for each task

General appeal of the app to participants

Improvement suggestions based either on participants' direct ideas or your analysis of all of the above.

You can write your report as Pages/Word document or as a presentation document. You can find both templates in this folder (🔒Internal use). If you follow the structure of these templates, you won't miss any significant part of the report, such as describing participants.

You'll be sending this report to the client, so try to write it in a plain language with no UX/UI lingo and lay down what improvement ideas result from the testing. That's what clients care about - how we'll use insights to make their product better.

Introduction

Let's get real—people are not just logical, they're emotional. A well-functioning product might tick off practical boxes, but what turns users into advocates is how a product makes them feel. Desirability testing is a controlled vocabulary test of software's or brand’s look & feel. It can help you capture user preferences and evaluate the emotional and aesthetic appeal of a product.

Why conduct desirability testing

Desirability testing gives you quantifiable data on those subjective attributes that users might otherwise struggle to articulate. Here are some examples of user research questions that can be answered using desirability testing:

Emotional Resonance: How does the user feel when interacting with the product? Is it eliciting the intended emotional response?

Branding Alignment: Does the product's aesthetic and user experience align with the brand’s emotional and visual identity?

Comparative Analysis: When presented with different design options, which one do users find more desirable and why?

Target Audience Alignment: Is the product’s design and experience resonating with the intended target audience, or is it appealing to an entirely different demographic?

Getting It Done: The Execution

Desirability testing is one of the fastest user research techniques, and you can combine it with other methods like user interviews, usability testing, etc. You can use Useberry, Typeform or any other tool of your choice to conduct desirability testing.

The test itself is very simple — you give users the list of product reaction words and ask them to select those that best describe the design (normally three out of them). Next to the words, you can simply show the screenshot of your screen(s) or brand attributes.

This extensive and comprehensive list of 118 product reaction words can be used for the study. You will see that it includes words that display visual appeal, copy used, functionality, user experience as a whole…

Now, choosing your vocabulary list is an art in itself. Aim for a balanced mix, like a well-crafted playlist. A list of 118 product reaction words may sound like overkill, but the words are there for a reason'. Here are some pro tips for list selection:

Tailor the list based on what you're keen on measuring if it's visual allure, ditch words like 'time-consuming' that relate to performance

Align the words with core brand values

Use a similar number of positive, neutral and negative words

Less can be more. Aim for 25 words or fewer, ideally around 10

Randomize the order in which the words are presented

Add your own words to the list if needed. But be very careful when doing that so that you don't add a word that can be interpreted as both positiva and negative. (Like "goofy")

When it comes to the number of participants in desirability testing, think of it this way: one is better than zero, but a hundred is leagues ahead. While even a single participant can provide valuable qualitative feedback, ramping up the numbers—especially if you're looking for quantitative insights—gives your data the kind of robust, statistical clout that makes your findings both compelling and credible. So, in the world of desirability testing, the more the merrier indeed!

Data Analysis

With the help of Useberry (or Typeform, or any other tool) we suggest that you:

Use percentages to report the number of times each word was selected

Check if different user groups perceive the software differently (for example, there may be a difference between the age groups)

Compare sets of words chosen to describe different options (if applicable)

Think about why users chose a specific word, and give special attention to the words that are most frequent, least frequent, or came as a surprise for some reason

Did You Know?

The first-ever desirability test was coined as "Microsoft reaction cards" back in 2002. And now you’re carrying the torch.

A qualitative and evaluative research method.

Usability testing is a direct way of seeing how users interact with our product.

In usability testing, we show the clickable prototype to one user at a time (whether it's a mobile or web app), and we ask them to:
a. figure out what it is
b. try to use the prototype to do a typical task
c. find some critical information.

In moderated usability testing, you guide participants through specific tasks and scenarios while observing their actions, listening to their feedback, and asking follow-up questions.

Usability Testing is crucial because it can help us learn if our product is really based on users' behaviours and expectations. This leads to many ideas for improving the design. We usually perform “task testing” — we ask the user to do complete a task, and then we observe how well they do.

It's a bit like having a conversation with the user as they explore and provide insights on what works well and what needs improvement.

Preparing tasks

After the client approved the agenda and after the responsibilities are assigned, the facilitator starts to prepare tasks and prototype(s). Be wary of the wording you're using on tasks; you don't want to give away the answer by mentioning the exact copy that is visible on the screen. For a more in-depth study of this process, take a look at NNG’s guide.

Test Run

Before the official user sessions, it's crucial to conduct a test run to identify any smaller issues and possible improvements. Simulate the test in Infinum’s offices or via a video call. The participants should ideally include the user, the facilitator, and the observer.

Moderating sessions

For each usability testing, we need at least two persons to set everything up:
a. facilitator,
b. observer.

This can a combination of produst strategists, designers, QAs or PMs. If you are the lead designer on the project, don’t take the user feedback personally and avoid bias towards users’ opinions.

Here are some tips and tricks to get you started:
- In the beginning, make sure the user feels comfortable and calm. Be friendly, so the user feels relaxed, but not too friendly because we need to get objective answers and opinions from them.
- Next, we use a script with Interview guides to conduct usability testing, and always keep the text in front of you. Don’t hesitate to read from it, but it’s ok to ad-lib a little, even if it means making mistakes. When the users see that you are comfortable making mistakes, it helps take the pressure off them.
- You have to make it clear before you start that nothing we do or say is personal, and they can always ask questions. It's helpful to tell them that sometimes giving the answers too soon will affect the testing, and you will wait until the end of the session to answer their questions. It’s important to mention this because it will seem rude not to answer their questions as you go along. If you want honest answers, it can be useful to point out you did not work on this project (whether that’s true or not) and that you are just overseeing the testing.
- Double-check if the participant has signed recording consent and NDA. If they did, turn on the recording of the session.
- If the participant's a bit quiet, it's ok to ask questions like “What are you thinking?” or “What do you think…”. Try not to start a conversation, but just to remind them to think out loud. Talking too much at inappropriate times or leading the user can affect what they do and say, which can ruin the research findings.
- Ask participants not to refresh their browser or go back in browser's navigation. This might affect Maze's tracking of their behavior.
- When users finish the study in Useberry (they'll get "Thank you" screen), ask them follow-up questions.
- Tell users how they'll get their reward, e.g., you'll send voucher code via email.

Here is a Google Drive folder (🔒Internal use) with templates and examples of usability testing interview guides.

And here you can find a template for prep email (🔒Internal use) to send to your participants.

A qualitative and evaluative method.

Website heuristic analysis (heuristic evaluation)

Heu..what? It’s only how Nielsen Norman and Rolf Molich named the usability principles back in the 90s. They also realized that sticking to them led to a better user experience and a greater number of returning visitors.

That’s why today we are talking about heuristic evaluation. It’s a structured approach to testing the website’s usability by taking the known heuristics into account.

We use it to eliminate major usability issues without involving the real users. The method itself is so structured and technical that people talk about it as usability engineering.

Who

You will need at least 3-5 experts to do the heuristic evaluation. It does require at least 1 experienced evaluator. From the Infinum team, you are looking for growth, QA, and UX specialists. From the client's team, you are looking for a marketing specialist, product manager, content specialist, etc.

To prepare for the analysis, we suggest you take a two-and-a-half-hour-long education about heuristic analysis on the CXL platform.

You might notice that this is the only user research method that we conduct — without users. This is only because it relies on a framework that takes well-tested and proven tested usability principles (heuristics) into account. So the focus is still on the user's reality.

When

You can do the heuristic analysis in any phase of the lifecycle of the website.

How

Part 1 — preparation (4-8h/person)

Go through the personas to prepare for the heuristic analysis, as you will use them as the basis for the walkthrough. Personas will help you predict users' reactions to the interface correctly, and reduce the risk of faulty presumptions. It will be extremely hard to answer some questions without them. If you want to read more, there’s a whole chapter about personas in the handbook.

Once you know everything about people visiting the website, jump into organizing the heuristic analysis workshop. Schedule about two hours to do the workshop, invite all the stakeholders that will be doing the analysis, and tell them to take the CXL heuristic analysis online course (if they haven’t already).

Decide on who will be facilitating the workshop, prepare the sheet framework and the FigJam board. We suggest that every evaluator does the work in a separate sheet, as we all like to adjust to others' opinions.

Part 2 — the session (2-3h/person)

So, this is how the sessions look like:

Take 10 - 15 minutes to meet, chat, loosen up, and build the rapport

The person leading the workshop should debrief the rest on the motivation, agenda, goals, and the frame of the workshop

Tell the evaluators to go to their assessment sheet and put focus on the first category

Everyone’s task is to go read the statements of the category in focus, go through the website, and rate how much the statements describe the website on the level from 1 to 100

Stay on the call so everyone can ask questions and clear the misunderstandings

Feel free to tell the evaluators to put your thoughts, arguments, and ideas in the comments of the assessment sheet —they will help you have the full picture later on in the process

When you are all done with the first category, just continue on the next one, and if you are the workshop facilitator don’t forget to manage the time

After the analysis, you will have a quantitative overview of how well your website performs on these 7 categories/usability principles:

Relevance. Do users think this is the right place for them?
Relevance is generally a feeling, and it happens in a fraction of a second - does the web page match to what the visitor thought they were going to see? An important factor in relevance is where your users are coming from and were their expectations meet with the pre-click and post-click messages and visuals.

Trust. Do users think they can trust the company?
Trust is also a feeling, and it happens in less than a second. Factors that influence trust in a website are web design (color, form, etc.), information architecture, information focus („clarity“), key visual, useful information, and brand. Another key factors in building trust are Social Proof and Authority (testimonials, trust seals, etc.)

Orientation. Do users know where to click and what to do?
Every website visitor wants to be able to find what they are looking for easily and quickly. Orientation is vital in making the users behave the way you want them to. Avoiding design and content clutter, having visible navigation and CTAs will help users navigate the website and find the information they are looking for.

Stimulance. Do users feel like they should buy or use the product?
Stimulating and motivating users to buy by using implicit and explicit value messages and including urgency and scarcity in your offer. A clear and unique value proposition and well-designed price/risk perception will help motivate users to complete the desired action on the website (purchase, sign-up, etc.)

Security. Do users feel like it is safe to use this website and give you their personal information?
Anticipating and answering user's concerns and doubts about the product or the purchase process, having a FAQ section or a chat option available will help users reduce the perceived risk.

Convenience. How effortless is using the website for the users?
Convenience is how easy you make it for the user to do things on your site and how convenient the user perceives it to be. Things like clear visual hierarchy, having space between elements, rounded buttons, clear CTAs etc., all contribute to the convenience to your users.

Confirmation. Do users know what the consequences of their on-site behavior will be?
Users may make emotional or irrational decisions, but they also seek to justify those decisions through confirmation and rational thought. So it is crucial to assure the users they made the right decision by purchasing on your website or giving their personal information. That way the “buyer’s remorse” can be avoided.

The most probable outcome is that you will wrap the analysis up by realizing the website has some potential for improvement. And you will ask yourself — what do I do with these results now?

Part 3 — make it actionable for homework(2-3h/person)

End the session by giving the homework to the evaluators.
Guide them back to the FigJam template you have prepared. Split the categories among yourselves. Show the basics of FigJam to the evaluators and tell them their homework will be to:

Think about how well the website performs in a category they are assigned to

Take some screenshots and put some notes that describe the current status of the website

Do some desktop research and find examples you can look up to

Paste some screenshots and post some sticky notes that picture the improvement suggestions

Part 4 — prioritize & wrap up (2-3h/person)

Meet again and:

Build the value-effort matrix by evaluating each suggestion's sticky note on the two dimensions (how valuable the improvement would be for the business, and how much time, money, and effort they imply)

Decide on who owns what, put it on the roadmap, and start working on the quick wins!

Why

You can do the heuristic analysis whenever you want to test the UX, content, or design of a website. You might notice that you might test the same thing by doing usability testing. So, what’s the difference between usability testing and heuristic analysis, and why would we ever use heuristic analysis?

Well... Usability testing will only get you the answers about people's reactions and behavior they are aware of. They don’t always tell you a lot about the deeper, subconscious principles.

Moreover, the fact that the people know that they are being tested changes their behavior and answers. The discrepancy between people's socially desirable answers and their real behavior might lead you to make faulty assumptions and build a product that isn’t what you looked for.

The advantage of heuristic analysis in this context is the fact that it takes the subconscious principles into account. It relies on a structured, tested, and proven framework of heuristics, or usability principles.

Advantages

Time & cost-efficient method

A structured approach based on proven principles

Results in clear action points

Captures the moments that are subconscious to users

Disadvantages

The quality depends on the experience of the evaluators

It is easy to fall in a trap of thinking you know all about your users

This framework works only for websites, not for the apps

User research is the practice of understanding users' needs, behaviors, and motivations through a variety of methods, such as interviews, surveys, and usability testing. It is an essential part of the design process, helping to ensure that products and services are designed for the people who will use them.

User research can be used to answer a wide range of questions, such as:

Who are my users?

What are their needs and goals?

How do they use my product or service?

What are their pain points?

What are their preferences?

How can I improve my product or service to meet their needs?

User research can be conducted at any stage of the design process, but it is most valuable when done early on. This allows you to gather insights that can inform your design decisions and avoid costly mistakes.

There are many different methods of user research, each with its own strengths and weaknesses. The best method for you will depend on your specific needs and goals. Some common methods include:

Interviews: One-on-one conversations with users to understand their needs, goals, and experiences.

Surveys: Quantitative data collection tool that can be used to gather information from a large number of users.

Usability testing: Observational study of users as they interact with a product or service.

Card sorting: A technique for understanding how users organize information.

This set of chapters will provide an introduction to user research, including overview of research methods, models of analysis, steps in conducting a user research study, and guidelines on reporting the insights.

It will also discuss some of the common challenges that you may encounter during the research process and provide tips for overcoming them.

Setting clear research goals and objectives is like having a reliable compass for your user research journey—it keeps you on course and ensures your findings are both relevant and actionable.

Kick off by pinpointing the specific problem or opportunity you aim to explore through research. From there, articulate your research goals as clear and broad statements that outline what you're trying to discover. Say you're researching a mobile app; a worthwhile goal might be to unearth the five features users would most love to see in such an app.

During the discovery phase—before your product hits the market—your spotlight is often on validating solutions conjured up in workshops. In this stage, we usually blend user interviews with usability tests to check if our shiny new concept resonates with the target audience.

And don't forget, your research goals should be in perfect harmony with your overall project objectives. This ensures that your research findings don't just collect dust but actually contribute to developing a product or service that’s useful and appealing to your users.