Designers design, and testers test, but when they work together, great things can happen. We explore how integrating quality assurance into the design process can be beneficial to both sides and the project itself. 

Whenever I’m working on a design and ask somebody from the quality assurance team for their help and opinion, I regularly get the following disclaimer: I’m not a designer, so I’m not sure if my feedback will be useful. 

Contrary to popular belief, it usually is. 

If I am working on a new feature, I prefer getting feedback from people who are experienced in the domain, regardless of their profession. 

Including software testers in the design process can be extremely useful. In this article, we’ll take a look at five activities where collaboration with software testers can produce excellent results.

Having a tester present during design refinements makes the meetings significantly more efficient. They are experienced in the domain, really good at finding flaws, and know the app quite well, both from a technical and user experience perspective. Their feedback makes making design decisions much easier.

Here are a couple of reasons why the quality assurance team can be a great asset in this step:

Testers are a great fit for usability testing because they have a better perception of the product’s “big picture,” they are experienced in evaluating products, and they always do a great job documenting issues. 

In most usability testing sessions I was leading, project managers would be the ones taking notes because their skills are quite versatile. However, testers can be just as useful here. After all, usability testing is the process of evaluating a product or service by testing it with representative users. Since the goal is to identify any usability problems, collect qualitative and quantitative data, and determine the participants’ satisfaction with the product – testers are a great fit.

The preparation and planning phase consists of the following:

When testers are involved in this phase, they get to see an early preview of their work. The planning part of a testing session provides some context for the testers, which will help them test the implementation later on. Selecting the participants gives them a better understanding of the target audience, and the test scenarios users go through are very similar to test cases QA specialists will be dealing with when it’s their turn to test the implementation.

Conducting usability testing includes the following:

Testers can notice nuances in user behavior and interaction with the product, uncovering potential usability issues that may have gone unnoticed otherwise. Being included in this part of the process helps them, too – by being aware of the main issues encountered, they can know what to pay special attention to during their round of testing. 

There are three main aspects in the analysis and reporting phase:

Testers excel at documenting observations accurately and comprehensively. Their eye for detail allows them to catch both minor issues and overarching patterns, which is a big help in the analysis phase. By being included in all these activities, they can help with creating a report as well.

When the developers release a new app build, testers and designers tackle it separately. The QA team ensures all parts of the app are working as expected and incorporate the design. The design team only does the latter, paying special attention to details in the UI.

The testers’ work is usually planned to align with the development process release cycle. That’s why they know exactly when each build will be created. On the other hand, designers’ work is planned around design priorities, and it may be difficult for them to check the UI of any new builds in a timely manner. 

This is one area that can be substantially improved by designers and testers working together.

Here’s what this can look like in practice. My tester colleague and I periodically organized a short session to review the differences between the design in Figma, the implementation, and the open tickets. Since testers are experienced in reporting bugs and opening tickets, they can teach designers about the best practices. This approach worked amazingly for us.

We assess the accessibility of a digital product by observing its various features in the light of different accessibility criteria. These criteria range from very UI-specific ones, such as text size and color contrast, to the product’s compatibility with assistive tools. 

While designers are well-positioned to assess UI-related criteria, testers play a crucial role in evaluating the app’s compatibility with assistive tools. They can utilize tools such as screen readers or keyboard-only navigation to see where the product may not meet accessibility standards. BTW, if you would like to learn more about testing features with accessibility in mind, this article is a good place to start. 

Let’s make it clear that not every tester is expected to have experience working with assistive technologies, but being aware of accessibility criteria is very beneficial to understanding accessibility.

To create a truly accessible product, accessibility standards need to be taken into account at every step of the development process. That’s why I would like to emphasize that the collaboration between designers and testers would not be enough to ensure the full accessibility of a product.

Testers prepare test cases based on feature requirements before they even see the implemented feature itself. To understand the feature in context, they can take a look at the design specification. They may come across states that are missing in design, and that way, improve the features and their documentation. 

Developers pay the most attention to Figma when they are implementing a specific feature. Once it’s implemented, they rarely need the design unless they want to revisit something. However, during testing, especially regression testing, the QA team tests the complete app and compares everything with the design files. That’s why it’s crucial to have a detailed design documentation of the app, even for features that were developed a long time ago. When this is the case, testers can point out parts of design documentation that are outdated or not specified well enough.

The goal of this initiative is not to overwhelm testers with a ton of overhead. Of course, not every tester is interested in design, and I’m sure there are areas of quality assurance as a discipline that can evolve without integrating with design. 

The goal is to explore the potential of this collaboration and how it can improve the entire development process. When everyone is aware of the possibilities, they can implement the recommendations where it makes sense. We want to spark interest in the benefits of collaboration, not lay down a bunch of new rules. 

The idea is to use each team’s strengths to make better products and keep an open mind to new ideas that arise from working together. Let’s take those opportunities when we see a fit and see how we can all benefit from QA and design’s teamwork.

People often have the impression that the number of people who benefit from digital product accessibility is negligible. The reality is quite different.

Limited digital product accessibility features restrict a huge portion of popularity from using them to order food, use mobile banking, or get a cab.

Furthermore, not caring for digital product accessibility affects not only the permanently disabled but also those with temporary, i.e., situational disability.

Take a broken arm, for example. Those affected can use their phone with only one hand. Next, think about texting on the phone in direct sunlight. Good luck if the messaging app has poor contrast! Or imagine trying to read something without glasses if there is no option for text enlargement. These are all examples of situational disability.

Taking into the context that disability can be temporary or situational, it becomes clear how many people are affected by poor digital product accessibility. This is a lose-lose situation for both users and providers because the user misses out on services and experiences, while the providers lose revenue, reach, and conversion.

But even if companies were okay with losing revenue, digital product accessibility is not optional. Accessibility standards are regulated by law.

In the EU, all government websites and mobile apps have to demonstrate a certain level of digital accessibility. In the US, this applies to every website and mobile app – as a result, more than 2000 lawsuits for inaccessible products get filed every year.

The European Accessibility Act (EAA) that comes into force on June 28, 2025, will require most digital products to conform to Web Content Accessibility Guidelines, level AA.

For a digital product to become truly accessible, appropriate steps should be taken at every stage of the development process. No one person or one team can drive digital product accessibility alone.

For example, there’s no point in achieving good color contrast if a logical focus order is not implemented. Similarly, an app isn’t actually tested if nobody tested the screen-reader behavior.

The accessibility handbook contains our knowledge about digital process accessibility and describes the relevant steps in our development process. Each team provides its domain-specific knowledge in a separate chapter.

Now, let’s look at accessibility standards in a little more depth.

As the World Wide Web grew, standards had to be developed to ensure its long-term growth and the organization in charge of those standards is the World Wide Web Consortium (W3C). Because of its massive popularity, the Web is the first platform that had to incorporate accessibility standards. 

These standards are presented in the Web Content Accessibility Guidelines (WCAG), a part of a series published by the W3C. However, while the WCAG provides a definitive set of instructions for creating accessible websites, which includes mobile and responsive websites, mobile apps are still not covered in sufficient detail. 

If you look into Google and Apple’s design guidelines, you’ll find that they do cover mobile apps and take accessibility into account. However, they mostly include patterns specific to each platform. 

A neutral body like the W3C does not exist for mobile apps and there is no single gold standard like the WCAG, which is why we had to find our own path for making mobile products accessible.

We have been implementing the guidelines in projects that have some of the widest user bases, such as banking and telecom apps.

The digital accessibility principles we implement in our projects are organized in the same way as the WCAG principles. There are three conformance levels across four categories – level A being the minimum level of accessibility in a digital product.

Each of the levels is applied to the four main categories: perceivable, operable, understandable, and robust.

At Infinum, we started our digital product accessibility initiative by finding advocates from every production team. Their first task was to research accessibility principles and guidelines in their domain. However, individual work was not enough. It was crucial to put these advocates together and create comprehensive principles that cover all steps of the digital product development process.

After that, our advocates had workshops with the rest of their teams to incorporate accessibility into their processes. Each team laid out its process in its respective handbook.

Finally, we retrospectively applied accessibility principles to previous projects through accessibility audits.

We believe that digital product accessibility is not just a technical issue but also a social one, and as a socially aware company, we feel a responsibility toward the disabled. The difficulties they meet are often caused by barriers set by society, and it’s up to that same society to remove them.

We have set out on a journey to promote accessibility in the digital world. We will continue to share our approach, knowledge, and best practices about accessibility via Infinum handbooks, Infinum blog, Infinum talks, and other platforms. So should you!

IoT solution development opens up incredible possibilities, but it also brings unique complexities that require thoughtful execution. Have you ever stopped to think about the challenges that come with Internet of Things (IoT) app design?

In this article, we’re diving into the complexities of designing the UX of the Philips MasterConnect app, the core tool for setting up and configuring smart lighting networks in commercial buildings. The app helps light system installers manage connected lighting systems and brings complex hardware-software interactions, while championing simplicity.

The benefits of IoT devices are too great to ignore. They bring significant cost savings, efficiency, and a better user experience – all reasons we should embrace the challenges and push the boundaries of IoT app design.

At the same time, designing an IoT app like MasterConnect is a whole different ballgame compared to, e.g., banking or telecommunications apps. With IoT, you’re dealing with not just the user, app, and cloud but also multiple connected devices, all exchanging information in real time. It’s a technical minefield, which is why it’s so important to do your research, validate design decisions, keep things simple, and keep the user experience front and center. In this particular instance of IoT app design, the interactions between the users, the devices, the app, and the cloud have to be as smooth as possible.

In typical everyday apps, the app interacts with the user and the database stored in the cloud. So whatever the user does in the app, it is a matter of interaction between them, the app, and the cloud.

However, with IoT, we do not just have the user, the app, and the cloud but also a plethora of connected devices that exchange data. The Philips MasterConnect app can hold up to 500 connected lights, switches, sensors, and gateways. Not only does the app communicate with all these devices, but we also use it to control how the devices communicate with each other.

Solutions like this make the product a perfect fit for every lighting system size, but IoT app design becomes far more complex.

Flavors are different versions of an app, with the same structure but changed looks. The differences vary from color palettes to completely different branding, including logos, fonts, and other visual elements.

Apps that can be utilized for different brands or industries are often made to support multiple flavors. We’ll go through an ideal workflow for easily creating multiple flavors based on quite a bit of experience working on B2B enterprise apps, each customized for a specific business.

First, let’s create a version of the app where we define the style guide, the design system (including all components and their states), and all screens. This is either a non-branded version or one for a brand that will have the app first. Let’s use this simple app for a pastry shop as an example. We created a comprehensive Figma file that consists of everything we need. That’s why we are turning that file into a library.

It’s essential to define a color palette with all the colors we will use in the app. That color palette will be changed for each brand, so each flavor will have its own palette. We can add some gradients to the palette as well.

We can define some colors that stay the same across brands, usually white and some grays. Maybe some signal colors as well (error, warning, success).

For example, we imagined two different brands, a restaurant and a fruit store.

For each brand we defined 6 color styles:

To create more flavors based on the first one, we need to create a new file in the same project. From there, we have two ways to create the UI for other flavors in the new file.

We can create some key screens from the original flavor file as components and add their instances (child components) to other UI flavors. That way, all design changes on the master components are inherited by other flavor files. Nothing is detached from the library. After that, we can select all screens and change colors from one brand to another.

The other way is to copy all screens on each Figma page and paste them to a new brand’s file, with the same color switching (manually or with a plugin).

The drawback of this method is that there is no connection between the child screens, so keeping all flavors updated requires some work. It’s good practice to leave a note when all instances of a screen for other brands are up to date. Usually, when I’m doing some design changes on a screen, I note that all changes are applied to other brands, and I put it back after I make sure all screens are up to date.

To switch other assets (logos, photos, illustrations, or icons) to the new brand, we need to do it one by one since there is no way to do that automatically in Figma.

However, if everything is set up well, including organizing everything using Variants, that should be pretty easy. We just go screen by screen and change a variant to the one that fits the flavor.

Currently, Figma does not support swapping text styles on multiple screens at once. However, the Themer plugin can do it for us. One thing to keep in mind is that one structure and layout might not work for a wide range of fonts, so we have to choose fonts keeping their proportions in mind. That’s why I advise using the same typography for all flavors. If that is too limiting, one text style can be used for all body text in the app, while subtitles can be custom-made for each flavor. This way, less stuff can go wrong when we create new flavors.

For icons, it’s best to use the same icon set for all flavors. That way, we don’t need to pay attention to having distinct icons for each flavor. For illustrations and some other assets, it’s good practice to organize them in Figma Variants, with the brand being one property. That way, we can quickly swap different versions of the same asset.

It’s important to name all assets in Figma properly so you can quickly navigate through them. When you select all these assets and export them, they will be organized in a folder structure according to the names in Figma. That is very useful for developers since they have their own project folder file structure for each platform. This means that they will have to place each asset into the belonging folder manually. That could get tiring when they have to place all assets for a new flavor.

I found it useful to create instances of all graphic components in a naming structure that corresponds to the file structure in the project folder for development. When we export these assets, they are already organized in folders as they are in the development project folder. This makes it very easy to import all assets in a project.

One of the things that are very important regarding the white-labeling process is to be consistent across different flavors. When we change something in one version, it’s important to do the exact change in other versions as well. Otherwise, we can quickly lose track of what is up to date and what is not. Luckily, this process helps us easily adapt complete UI across different flavors.

Take a look at how a file should be set up for the easy creation of new app flavors. Using this example, we explain the optimal approach for creating whitelabel apps in our post.

A while ago, while I was leading a design team of 15 members in an international engineering students’ association, I would often hear people say that they wanted to join the team. Yet, few would even sign up.

Whenever I asked why they didn’t join, I got the vibe that the majority simply didn’t believe they had what it takes – enough knowledge about design to begin with or the confidence that they would ever acquire it.

Even today, as I collaborate on a daily basis with engineers and other non-designer colleagues established in their respective professions, I often witness many of them are interested in design, but very few actually get around to educating themselves or exploring another discipline.

I‘ve always been interested in technology and science but with a wish list future profession. After high school, I enrolled in the Faculty of Electrical Engineering and Computing, earned my Bachelor’s degree there – and then I decided to pursue a Master’s in Design. Wait; what?!

As you might assume, I’m the biggest proponent of taking a multidisciplinary approach to things. Here’s how each of these disciplines, Engineering and Design, contributed to me becoming a better digital designer.

One of the basic things I learned there is how to work on software. I had to get familiar with a vast number of technologies, architectures, and programming languages. That’s how I got to know and remember things that are common in most projects. Also, during my education, I had to work in teams with goals to create functional web or mobile apps – that’s what I do as a designer, as well.

In tech school, everything revolves around developing problem-solving skills. Learning about technologies that helps solve problems. When new issues emerge, you explore new solutions. That’s how science works. Funny enough, that’s how design works as well.

As a digital designer, I solve problems with solutions that are visual, organizational, or experienced. However, the logical reasoning behind proper problem-solving is always the same. A wide spectrum of math-related subjects really improves logical thinking.

Needless to say, technical education meant learning about some tech-specific stuff. I got to know the frameworks, when it’s better to use waterfall, and when agile can be more efficient. I learned how to read entity and sequence diagrams and about how they are useful in the early design stages. I got to know the difference between native and custom components. These things are not taught in design schools, although they are crucial in digital design.

In most digital agencies, developers make up to 70% of the workforce. At Infinum, among some 270 people, there are 25 designers. Working in a digital agency, this means one will spend most of the time collaborating with developers. Knowing their lingo and way of thinking is a huge plus in reducing the gaps between design teams and development teams.

One of the fundamental skills of a designer is to be able to step into the user’s shoes, and I’ll admit that focusing on understanding technicalities made me step away from the user-centric way of thinking. A typical design process includes conducting target audience research, interviews, leading workshops, brainstorming sessions, defining concepts, and usability testing… The list goes on.

That’s a lot of interactive work with people from all kinds of backgrounds, together with a bunch of data to process. The crucial part of the complete workflow is making decisions with confidence.

While the sense for well-organized and structured output is always desired, it should never limit visual creativity skills. Fresh and exciting experiences should have a dose of thrill, along with an innovative look and feel. It took me a while to unleash my creativity, beyond focusing on efficiency and optimizing everything. That’s also why it makes sense that plenty of designers are from an art background, doing excellent work in agencies.

Another aspect I missed out on in the beginning was being part of a community. Design schools connect you with experienced designers from the early days. That is really helpful since networking and learning from the right people are crucial to kick-start a career. It is not easy to connect with other designers when you are in a tech school, so I only truly became a part of the design community after diving right into the field and starting my Design Master’s.

At first, I had a pretty strong impostor syndrome – an array of feelings and fears of not being good enough, common when stepping outside of one’s comfort zone. It’s important not to give in to the uncertainty but to utilize what you’d learned before in a new way. This way, you can enrich your team with new knowledge and a fresh perspective.

Finally, what appealed to me the most about becoming a digital designer is being in the position to shape the future of products we are working on, expanding the boundaries to reach innovative solutions, and taking problem-solving strategies to a new level. That’s a responsible challenge, but to me, it is the most exciting job in the world.