Subscribe now

How I use NotebookLM in my ideation workflow

Reading some articles and browsing posts on LinkedIn, you might get the impression that everything has already died or will die within the next few months. Design is dead, the design process is dead, the testing profession is about to die, the product manager role is about to disappear, agile methodologies are dead, Figma is dead, and the list could go on for quite a while. If you are interested in this topic, it is also worth taking a look at a recent post by Debbie Levit.

However, I would like to reassure you that nothing has died, and nothing suggests that this will change anytime soon. Of course, we can clearly see that things are evolving. People are starting to work differently, with the growing trend of product builders being a good example. Yet even if we all eventually become product builders, many things will remain the same. Perhaps the tools will change, but the core of the work will not. For that reason, I would not be so quick to declare the death of anything.

With that in mind, I would like to show you what my design process looked like in 2026 while working on a new product with the support of AI. This will not be an impressive showcase of building a great product and pushing it to production within a few hours. Instead, it will reflect a real process inside a large organization where AI strongly supports the work.

Some people will probably say that this approach is outdated and that I should be able to deliver a product to production within an hour. In reality, however, this is not how things work in the vast majority of large organizations. They simply cannot afford that level of experimentation due to budget limitations, legal constraints, resource availability, internal company politics, or even the existing IT infrastructure.

What did my process look like?

Toolstack

NotebookLM, Gemini, FigJam, Figma, and Figma Make.

For those who are not familiar with it, NotebookLM is an artificial intelligence tool based on the latest models from Google. It works as an intelligent assistant for analyzing and organizing source materials. One of its biggest advantages is that it operates only on the sources you provide, which significantly reduces the risk of hallucinations. In addition, every piece of information is linked to the exact part of the document it comes from.

It is an excellent tool for contextual analysis, data synthesis, and as an assistant during the discovery process. It can also work very well as a knowledge base for a product and its features.

Let’s return to the process.

What did it actually look like?

I will start by saying that I collaborate with product managers almost from the very beginning of the product development process. In this case, when I joined the project, there was already some information collected by the PM waiting for me. This included the initial assumptions for the new product, goals, some information about users, an early proposal for functionality, and the results of research conducted with the target group.

1. Context and Discovery

At the very beginning, I moved the information I received into NotebookLM and asked it to summarize it so I could familiarize myself with the project and establish what we already knew. I also asked for a separate summary of the attached research results.

Next, using the deep research feature in NotebookLM, I conducted desk research on the two biggest competitors of our new product. I expanded this research by manually collecting additional data that the model was not able to provide but that I considered important, and I added that information as well.

2. Analysis

Based on the data collected by the PM, the research results, and the materials from my own research, I then asked the model to identify gaps, risks, and inconsistencies in the collected materials. I was particularly interested in differences between internal knowledge and external insights in order to identify areas that required deeper investigation or clarification. The goal was to make sure these issues would not negatively affect the product being developed and to understand which areas required special attention.

At the same time, I asked for a list of the ten biggest frustrations users experience when using competitor services, as well as the must have features for the first version of the product. We wanted to understand the main pain points that our product could address. I received a ready to use list that included priorities, proposed solutions, and the value for the user. I also received a proposed UVP which, interestingly, aligned with our initial assumptions.

This step was the result of an analysis of the previous stages of the process that I asked Gemini to perform. It suggested specific steps and questions and prepared prompts for NotebookLM that significantly improved the quality of the responses.

I received a list of topics that clearly required deeper product work. Some of them turned out to be unnecessary because they resulted from a lack of knowledge about certain aspects of our product, for example how advertising works within it. Despite that, the questions themselves were still valid.

Next, I asked for proposed solutions to address all of the identified inconsistencies as a starting point. I also asked Gemini to do the same, since it can be connected with the context from NotebookLM. It is important to be mindful of sensitive data when doing this. Both tools proposed slightly different but equally interesting solutions. Gemini then combined both responses into one comprehensive answer, adding several additional questions and suggested solutions across all areas.

3. Alignment

Together with the PM, we analyzed the questions and the proposed solutions. We provided answers to the questions and decided to move forward with some of the proposed solutions. We also reviewed the inconsistencies that had been identified between the internally documented requirements, the proposed functionality, and what we had learned from research and desk research, and clarified them. I then provided the entire updated material to NotebookLM so it could update its knowledge base.

4. Concept & Validation

Once we felt that the collected data was sufficient, I asked NotebookLM to prepare a prompt that would allow me to build the key product view based on the gathered information. I then used this prompt in Figma Make, which produced very satisfying results. In fact, the generated view reflected our assumptions and addressed the user frustrations that had been identified earlier.

The generated view served as the foundation for workshops with the PM.

During the first iteration, we analyzed what we had received. We went through each element and decided what should be removed, what required modification, and what could remain unchanged. It turned out that several elements were unnecessary, so we removed them. Some were modified, and we also kept a few solutions that we had not originally considered but found worth exploring.

After the first workshop iteration, we conducted an initial analysis with the technical, advertising, and SEO teams. We gathered information that allowed us to move forward and ultimately confirm the content of the first version of the view. The most important factors were those affecting SEO and the frustrations most frequently identified during the research.

After collecting insights from these analyses, we updated the prototype during another round of workshops. We then conducted usability tests with the target group, which provided additional feedback that was incorporated into the prototype. In total, we completed three iterations of the prototype, along with smaller improvements along the way.

5. Design & Handoff

At this stage, we had already finalized the content of the view. The next activities were more technical. Among other things, I mapped the elements of the view to our design system and documented what we were currently unable to support and which components would require modifications to meet the new requirements. I also began writing design and technical documentation for individual features, which is needed for deeper analysis and implementation planning. This work was also supported by AI, which significantly accelerated the process.

At this stage, I also prepared a more refined version of the view, composed mostly of design system components, the appropriate advertising grid, and the standard elements used across our products.

Work on the overall look and feel of the product also began at this stage. All of these activities were carried out in Figma.

The final step involved expanding the components and preparing production ready views based on the materials developed in the previous step. This included the key view we had been working on, as well as additional views that were required. Some elements were simplified due to cost or time constraints. Everything was prepared in Figma.

After that, the handoff took place and the next stage of collaboration with the engineering team began as the product moved into implementation.

In short, this was my process. At most stages it was supported by AI to a greater or lesser extent. This allowed us to save a significant amount of time compared to a process without AI support, while also helping us deliver a higher quality product. AI helped highlight areas that might otherwise have been overlooked and supported the creation of higher quality materials, such as documentation.

One very important point is that at every stage the final evaluation always came from us. We never treated the outputs we received as unquestionable facts. Effective work with AI requires the ability to manage and critically evaluate what it produces, and to determine whether the information is valuable or useless.

The key ingredient in this process is the knowledge and experience of the people working with AI. This is the part that cannot be replaced.

☕ Support our work

Premium is a simple way to support us as creators for just $5 a month (or $45 a year).

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Will we all become Product Builders?

The digital product design and development industry is changing before our eyes, largely thanks to AI. There are many shifts underway, and one of the most frequently discussed is what product teams will look like in the near and long-term future.

We all know what the usual team setup looks like. There is a PM, one or two designers, and anywhere from a few to a dozen developers. Each role focuses on its own domain while collaborating with others.

However, there are growing signs that this model is beginning to change, slowly or very quickly, depending on the organization. Referring to two great conversations by Lenny Rachitsky, the recent episode The design process is dead. Here’s what’s replacing it with Jenny Wen, Head of Design at Claude, and an earlier one with Dylan Field, CEO of Figma, titled Why AI makes design, craft, and quality the new moat for startups we can draw the conclusion that the traditional split between designer, engineer, and PM is becoming less accurate in describing reality.

If this division truly begins to disappear in the coming years, what will replace it? It seems that the answer may be the era of product builders.

In this second article in the career development series, we will take a closer look at the increasingly visible role of the product builder. It also serves as a natural continuation of the previous article about the IC path.

Who is a product builder?

A product builder is someone who can independently take a product from idea to launch, combining design, product, and technical thinking. Most often, they are designers or product managers with deep expertise in their core domain who, with the help of AI, extend their capabilities across other stages of the process. Increasingly, developers are following a similar path, expanding their role to include product and design thinking.

Are we supposed to become experts in everything now?

Definitely not. However, our role is clearly evolving to adapt to a new reality. So what does the designer of the future actually look like? Jenny Wen proposes three new archetypes she would be most excited to hire.

• Block-shaped generalist

• The Deep-T Specialist

• The Cracked New Grad

Block-shaped generalist

This is someone who is strong across multiple areas at once, so their skill profile looks more like a block than a T. It refers to a person with substantial knowledge across several disciplines, such as design, coding, and product thinking, although not necessarily at the exact same level in each. I would say this archetype is the closest to a product builder.

The Deep-T Specialist

This is an evolution of the classic T-shaped profile. People in this archetype have even deeper expertise in their core area, often described as being in the top 10% of a specific field, such as systems thinking, visual design, research, or animation. It can also apply to a designer who has developed very deep knowledge in product management or development.

This archetype is particularly important right now because when anyone can build almost anything with AI, deep expertise becomes even more critical. It is what allows teams to validate, refine, and meaningfully develop what AI helps generate.

The Cracked New Grad

This is someone at an earlier stage of their career who is driven by curiosity, ambition, and resilience in the face of change. They are not yet shaped by established ways of working, which allows them to adapt quickly to a rapidly evolving environment. This makes them an ideal candidate in fast-changing times. Jenny considers this one of the most underrated archetypes.

Each of these archetypes responds to a different challenge we are currently facing. The block-shaped generalist addresses the blurring of roles. The Deep T responds to the need for real depth of expertise. The Cracked New Grad reflects the need for adaptability.

What they all share is curiosity, a willingness to step beyond defined roles, and openness to change.

In the context of the product builder, the block-shaped archetype describes it best. However, it could be strengthened by elements of the Deep T, such as strong domain expertise, as well as the mindset of the Cracked New Grad, without which it is difficult to succeed in today’s environment.

Is the market really moving in this direction?

In my opinion, absolutely yes. We may not yet know exactly what form this will ultimately take or how it will look in the context of the archetypes mentioned above, but this shift is already happening.

Let’s start with a statement from Cynthia Savard Saucier, VP of UX at Shopify:

Next, we have Ryo Lu, Lead Designer at Cursor, who, as early as July 2025, mentioned that he designs Cursor directly in Cursor:

Now let’s look at research conducted by Figma. Based on these findings, Dylan Field, Figma’s CEO, said that 72% of respondents are expanding their responsibilities thanks to AI tools, and 56% of non-designers are already taking on design-related tasks:

Returning to Figma’s research, the report states that 65% of product managers engage in at least one design task, and 57% of developers report moderate or significant involvement in prototyping. The report also describes product managers as increasingly involved in creating mockups or prototypes to help communicate their vision at the beginning of a project.

In the article accompanying the report, titled Are roles and responsibilities a thing of the past? we can also read:

“Ownership of design work is broadening: Non-designer participation in design-centric tasks like creating mockups and brand explorations has increased 10% in the past year. In practice, this looks like marketers creating quick visual assets for social media or PMs sketching early ideas rather than waiting for a working prototype from a designer. In fact, 70% of PMs said they’re creating low-fidelity mockups or wireframing, and 59% said they’re taking on interactive prototyping.

We can find more interesting insights in the report PM Field Guide for the AI Era, which describes prototyping as a central practice of the modern product manager. Here are two additional quotes:

This is only a small sample of the information available online. There is a growing number of signals pointing to changes in product teams and job postings, sometimes explicitly for product builders.

It is becoming less surprising to see a product manager creating working prototypes or a designer delivering production-ready code or components for Storybook. LinkedIn has even launched the Associate Product Builder (APB) program, supporting the development of product builders with the opportunity to be hired within the organization.

All of this suggests that environments and processes in which we can call ourselves product builders are not a distant future.

Building and scaling products

Looking at the information above, can we say that in the future, the division into specializations will disappear entirely and teams will consist only of product builders? In my opinion, no. This view is also supported by one of the archetypes proposed by Jenny, the Deep T. I would argue, however, that the role of product builders in the process will vary depending on the stage the product is in. For simplicity, I will divide it into two phases: 0→1 and 1→100.

0→1

At this stage, product builders can operate at the full extent of their capabilities because speed of delivery, testing, and iteration matter most. Dylan Field has said directly that the most valuable skill is shortening the distance between an idea and a working prototype. That is exactly what product builders can do. Without communication barriers or hours of meetings, they can deliver a ready solution in the form of a prototype or implemented code within hours. At this stage, rapid launch and user feedback matter more than quality, scalability, or security. As a result, a product builder can confidently lead a project end-to-end, even without deep knowledge of areas such as architecture, since the overall risk is relatively low.

1→100

Here, things become more complex. The product builder is still present, but the role evolves and expands to include collaboration with specialists such as database engineers, security experts, and people responsible for designing systems. A product builder remains highly valuable because they can independently define problems, explore solutions, build prototypes and new features, and test them with users. What changes significantly is that pushing things directly to production may, for many reasons, no longer be possible. In such cases, the product builder can hand off ready code to developers, who ensure code quality and proper implementation. This is a process Jenny also mentions in her podcast.

In addition, some organizations, such as Spotify and Airbnb, are developing small teams focused on rapidly testing new features. This is an ideal environment for a product builder, as in many cases, a single person can move through the entire process.

At the 1→100 stage, additional factors come into play, including technical debt, standards, consistency, and overall product complexity. Because of this, one person cannot realistically do everything. Moreover, managing debt, maintaining standards, and ensuring consistency remain challenging with the current generation of AI tools. For that reason, a product builder does not replace specialists but acts as a catalyst.

Is there anything to be afraid of?

We are seeing roles blur, with designers shipping code and product managers creating prototypes. But does this mean that existing specialists are at risk and that the only path forward is becoming a product builder? In my opinion, no. I have already addressed this in the previous section, and Jenny’s proposed archetypes reinforce that perspective.

Many people may also wonder whether they should be concerned that this kind of role will take their job, for example, a PM creating mockups. Personally, I do not see it that way. In most cases, these activities are about communicating through visuals and interactions, whether to explain a potential solution or to share a new product idea. This significantly improves communication, strengthens collaboration, and saves many hours of work.

Even though AI now handles a substantial portion of the execution, a specialist is still needed to judge whether the outcome is truly good and aligned with the overall strategy. Once again, this is reflected in the archetypes proposed by Jenny.

By saving time on execution, we can redirect resources toward what truly matters in building products: strategy, research, and system scalability.

Tools, processes, and areas of responsibility are evolving, but the need for deep expertise is not disappearing. Product builders represent a major acceleration in how digital products are created, not a replacement for specialists.

So will we all become Product Builders?

Coming back to the original question, all signs suggest this is not a passing trend but something that will stay with us for the long term.

Some organizations are already hiring for roles like this, while in others, it may remain out of reach for the next few years due to their size, risks, product complexity, or simply a lack of awareness.

Will this become the standard way of working in every organization in the future? We cannot predict that. What we can do, however, is pay close attention to what is happening in the market, deliberately expand our knowledge beyond design, and treat AI as a natural part of our everyday toolkit.

☕ Support our work

Premium is a simple way to support us as creators for just $5 a month (or $45 a year).

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Making the Design Team Visible

Picture this: you are on a small team of really talented designers who are just crushing it: customers are happy, product management and engineering counterparts respect them, and all deadlines are kept. However, business stakeholders don’t even know about the existence of the design team. All the fame goes to product and engineering.

“Aren’t they just some artists who draw specs for our engineers who do the real work?” – someone from the Senior Leadership team may ask one day.

Well, that’s not the end of the world yet.

But what do you think may happen to this team when things go sideways, and leaders sit down with the finance guys to look at spreadsheets and make a few difficult calls?

These designers may be the first to leave.

A scenario that’s not so unrealistic, especially in today’s economy, where many organizations are forced to cut costs and do everything to keep themselves above the surface. In situations where business leaders misinterpret the function of design and see us only as a cost, not a strategic investment, we are simply screwed.

How to not let this ever happen? Or at least, how to minimize the risk?

The answer is to make the design team visible through:

✅ Establishing strong stakeholder alliances
✅ Proving the value with lighthouse projects
✅ Communicating the abilities of the design team

In today’s article, we will explore all the steps needed to make this happen.

Finding the balance

I feel like we go to extremes too often in our community's discussions. We romanticize our role and spend much of our energy talking about craft, visual design tools, and the future in the context of AI and vibe coding. We rarely talk about equally important parts of our job, such as strategy, leadership, and stakeholder alignment.

On the other hand, when it comes to talking business and finances, we are still bringing the same numbers to the table: McKinsey’s report revealing that companies prioritizing design have a 32% higher revenue growth and a 56% higher total return to shareholders than their competitors, or Forrester’s study on the ROI of design thinking claiming that every $1 invested in design can bring up to $100 of return.

While these numbers are valid and absolutely inspiring, they’re not translating well to all businesses and design teams, and don’t make our teams more valuable in the eyes of business stakeholders right away. The whole trick is to adjust the message to the audience and speak in the context of a specific business and organization.

One thing that has a high chance of accelerating the value of the design team and bringing more visibility to it is a lighthouse project – I’ll describe them in a moment, but first, let’s focus on the importance of stakeholder alliances first.

Why do we need stakeholders on our side?

You may think that, since you already have a few buds at work (most likely your peers from the design or engineering team), you don’t need more professional relationships. Especially with the people at the top. They’re strange, do more important work than you, and operate so differently that it’s impossible to have any link with them. Right?

When I was starting out as a designer, I used to think like that as well. A life learned lesson shows that I couldn’t be more wrong about work relationships. You need these relationships badly for a couple of reasons:

✅ Products are political
No matter how well you’ve done the research and how good your design is, someone always controls the budget, business priorities, and headcount. When this person (or a group of stakeholders) is your ally, there are fewer hurdles to getting a green light. Suddenly, office politics becomes easy, and approval becomes a formality.

✅ Early alignment beats persuasion
When you invite stakeholders to your process, they feel like they co-create solutions with you. Alignment suddenly is there, and you don’t have to sweat out trying to sell them anything late. You are not convincing them, but you’re executing something they already helped shape.

✅ Trust means faster decisions
Sooner or later, every team is forced to make trade-offs, and they can get really messy with scope cuts, delays, or quality versus speed. When this happens, leaders rely on people they trust. Once you built that trust, your judgment carries more weight.

✅ Protection during conflicts
When things go sideways (and they will do one day, for sure), allies act as buffers. A respected stakeholder backing you can prevent reactive, top-down decisions that damage the product, your credibility, and your career.

Having stakeholders on your side is important and beneficial, but it doesn’t always come easy. In a remote environment, it might be super difficult to have a casual conversation over the water sink or grab a lunch with them. So, what can you do to establish and eventually strengthen these relationships instead of just a virtual coffee?

Lead with curiosity

Assuming you’re leading an invisible design team, or you’re an individual contributor standing in the shadows, you have no power in your organization. And that’s OK. You can still influence stakeholders and build alliances with them as long as you have this one trait: agreeableness.

High-agreeableness people prioritize social harmony, empathy, and helping others. Doesn’t it sound natural to us designers who put users in the centre of our hearts?

Applying UX-style empathy to stakeholders is all about understanding their pressures, incentives, and decision-making: where their weird ideas and comments come from? They’re probably not weird, but it takes some effort to go deeper and really understand them. We, as designers, should be looking for ways to support their goals instead of fighting with them during demos and alignment calls.

Curiosity instead of critique. It means going side by side, not head to head. Leading with curiosity doesn’t mean that you stop having standards. It means that you position yourself as an explorer.

Stakeholders resist critique because it threatens their status, implies that they may be wrong (how dare you!), and creates defensiveness. On the other hand, natural curiosity signals respect, invites collaboration, and makes people feel smart and heard. Who doesn’t like to feel this way? This is the first step to grow your alliances.

Speak the language of execs

Executives ultimately care about things like growth, revenue, efficiency, and risk. When, instead, they hear things like font family, design system, daily active users, and accessibility, they might feel a little confused or even uninterested. Your job as a designer is to align the language to the audience. Drop that design jargon and focus on business outcomes during alignment calls, demos, and other work-related conversations with the stakeholders.

Continuing on my previous point about leading with curiosity, these are the questions you can safely ask during meetings to better understand the incentives of a stakeholder and not worry that they will find you weird because of the design jargon:

• “What is the biggest risk you see in this direction?”

• “If that fails, what would have caused it?”

• “In which areas do you think we are most vulnerable in the competitive landscape?”

This shows the strategic thinking that all designers should cultivate. Curious designers look like systems thinkers, not aesthetic guardians – I can’t think of a better way to position yourself as a strategic investment rather than a cost.

Develop executive presence

The choice of words is just a part of a broader topic that boosts our credibility in the eyes of stakeholders and takes us one little step towards a stronger alliance with them. This topic is executive presence. At its core, executive presence is the ability to create confidence in others that you can handle complexity, ambiguity, and responsibility at scale.

A term coined by Sylvia Ann Hewlett and broadly expressed in her 2014 book “Executive Presence” is super important for designers – even if you are not planning to become an executive or a formal leader one day. It changes your perception from a person who’s super focused on the visual side of things to a strategic partner shaping outcomes.

How can you develop executive presence? There are a few tips:

✅ Show up as a strategic leader, not just a design advocate
Powerful designers don’t just answer — they elevate. Do that by asking strategic questions during meetings: “What risk are we most concerned about here?” and “If we had to cut this in half, what must remain?" are great examples of questions repositioning you from executor to thinker.

✅ Take your time when responding
Rushing can seem anxious, while speaking slowly conveys authority. Pause before responding. The more senior you seem, the less you need to hurry.

✅ Embrace a “Yes, and…” mindset
It comes from improv theater, but it’s incredibly powerful in design. In an executive environment, “Yes, and…” keeps momentum alive. Instead of killing conversation with “Yes, but…”, critique, and defensive positions, it allows you to build on someone else’s ideas and co-create with them.

✅ Start a writing practice
Executive presence is, for the most part, about the clarity of the message. Writing should help you sharpen your thoughts and messages. But not any writing. Practice something that really puts you into the executive thinking mode, such as a one-page decision memo or pre-meeting writeups. Executives expect “bottom line first” messages (from Recommendation through Rationale to Evidence), so learn how to structure your messages.

✅ Look the part
I don’t necessarily mean wearing a suit. It’s more about calm body language communicate self-respect and situational awareness. That subtle signal says: “I understand the room I’m in.” Whether you like it or not, people make rapid, unconscious judgments about competence and authority within seconds. When a designer’s appearance signals professionalism and alignment with the company’s leadership culture, it reduces “status friction” — stakeholders focus on the idea rather than subconsciously question credibility.

Once you align the choice of words and develop the executive presence, stakeholders will finally understand you and start respecting your ideas and treating you and your team less as a cost. Now there’s time to strengthen your relationship with them and prove to an entire organization that design is a strategic investment through a lighthouse project.

A lighthouse project – an ultimate catalyst for proving the value of design

There’s no better way to prove the value of design through a lighthouse project. Just like a lighthouse guiding sailors on the sea during nights and rough weather, these projects are highly visible and serve as a gold standard for the whole organization, demonstrating how projects should be run from a product design perspective. They show what a great project looks like and signal the direction the organization should move forward. These aren’t just successful projects, but they serve as reference projects.

Lighthouse projects usually have these four traits:

✅ High visibility
Since they touch on a key revenue stream, a critical user journey, a flagship product area, or (actually almost always and) an executive priority, leadership and almost the entire company watch them or at least hear about them once. They are rare opportunity to build a reputation.

✅ Measurable impact
In order to work, they need to produce visible results – conversion went up by X, support tickets reduced to X, significant improvement of activation, or faster time-to-value – you need some strong numbers. Without them, it’s just another nice redesign you can store in a drawer.

✅ Strong narrative
Storytelling is vital to many aspects of design, and lighthouse projects benefit from it as well. The narrative matters as much as design if it tells a compelling story: from a clearly defined and important problem, through a well-thought-out and insightful solution, to a measurable impact on business.

✅ New standard
To reinforce that this project is different and better than everything that has happened previously, it needs to set a new standard. It could be a better UX pattern, a new research practice, or a better cross-functional collaboration.

Stakeholders won’t trust your potential alone. That said, lighthouse projects are a great way to build credibility, demonstrate the power of good design, and start influencing the whole organization through a strategic approach to building products.

There’s no better way to broadly demonstrate your ability to collaborate cross-functionally. Lighthouse projects prove you understand business goals and show that these goals drive your decision-making. These projects ultimately strip you of the pixel pusher label and turn you into a strategic design partner.

The design process isn’t for designers

Treat this little story as a bonus layer for building trust and stakeholder alliances. Last year, one of the most important strategic initiatives for my design team was to make it more visible. We’ve taken a bunch of actions to make it happen, including… illustrating the design process.

Sounds crazy at first, doesn’t it?

We all know that the design process is never linear. The more senior you are, the more flexible your process becomes. You understand that every project is different and needs a tailored approach. There’s no debate about that.

However, the steps we take, or rather the activities we do to solve business problems using design methods, are repeatable. Usually not in the same order or amount, but from a high-level perspective, they are roughly the same. Frameworks like Double Diamond aren’t stupid – they are just oftentimes misinterpreted or taken too literally.

So, why have we decided to spend time and energy illustrating our design process, knowing we will never follow it strictly and won’t expect new hires to do the same?

After making the first draft, I casually presented it to a few non-designer colleagues from my closest circle. During that meeting, I realized that the design process is not for designers, but can serve as a great tool for communicating with non-designers (engineering, product, sales, support, and, finally, business) about what design is, why we do what we do, and how collaborative we can really be.

Depending on how well you structure this document, it can help non-designers understand the usual steps we take to solve problems and the rationale behind each.

Additionally, it can work as a sort of invitation to certain parts of the process. For example, if your design process includes a validation stage (I hope it does), and you work in a B2B environment and struggle to get direct contact to the customers, you can reach out to the Sales and Customer Success teams within your organization and invite them to fill out this gap in your process (or ideally, convince them on the importance of you and your team being closer to the customers, but that’s a different, much longer story).

You may not believe it, but not everyone in your organization really gets why we go deep and try to understand the problems our customers and users are facing before we jump into Figma to ideate solutions. This design process could really help with that.

☕ Support our work

Premium is a simple way to support us as creators. It’s just $5 a month (or $45 a year), and as a bonus, you get full access to our entire archive.

Subscribe now

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Does every designer ultimately have to manage people? The IC Path

The first month of 2026 is already almost behind us. Many people have started working on their New Year's resolutions, while others are probably still in the planning phase. Among all kinds of goals and plans, those related to career growth often come up. We start thinking about how to move our careers forward, which areas we should focus on next, and what we really want to do to feel satisfied with our work.

That is why, with this article, I’m starting a series of articles focused on career development and the different directions you can take as you grow professionally. Together with experts, we will compare these paths, look at their pros and cons, and assess how well each one fits into the future of our industry.

To begin, we will take a closer look at the first possible direction, the IC role, also known as the individual contributor.

What defines the IC career path?

IC is a career path that allows you to grow as a designer and increase your impact on the product and the organization, without moving into management roles or people management.

Stages of growth on the IC path

The early stages of development on the IC path look very similar in many companies. For UX and Product Designers, they usually follow this progression:

Junior -> Mid-level → Senior

This is the point where it is worth pausing for a moment. It is the stage at which many designers decide to move into a management path, which we will cover in a separate article. Those who choose to stay on the IC path usually have the following growth options, depending on the organizational structure:

Senior → Staff → Principal → Distinguished

Sometimes you may also encounter roles such as Senior Staff or Principal Designer. This depends heavily on the specific organization and how it defines career progression.

Bonus: Super IC

The term Super IC is often used to describe designers at the Staff, Principal, or Distinguished levels who combine the highest level of expertise with a very strong organizational impact, while still remaining individual contributors.

What does this look like in practice?

If I had to describe the IC path in one word, it would be craft. By craft, I do not mean tool proficiency. I mean the ability to design and solve design problems at every stage of your career. Regardless of experience level, you continue to design and work through complex problems.

That said, craft is not the only area you need to develop in order to progress on the IC path. The proportion of time spent on craft compared to other skills also changes over time.

At the beginning of their careers, designers usually work on smaller and simpler problems that do not require a high level of independence or difficult decision-making. Responsibility is limited, and they are rarely involved in higher-level discussions. Contact with stakeholders is minimal or nonexistent. At this stage, designers should be mentored by more experienced colleagues to build their skills. They often focus more on individual artifacts than on their broader impact on the business or the organization. Project inputs are usually already well defined. They also learn how to give and receive feedback and how to work effectively within a team.

As your experience grows, the nature of your projects changes. You begin working on larger and more complex problems. You start gathering information on your own from different team members in order to build the context needed to design meaningful solutions. The balance between craft and other skills gradually shifts, which I will describe in more detail later in the article. Your communication skills and technical knowledge also continue to improve.

In practice, the core path from junior to senior looks similar across many organizations. This applies both to designers who plan to stay on the IC path and to those who eventually move into management. You can find more detailed perspectives on this stage in our other articles:

• From Intern to Senior. Part 1: Strategic thinking, engagements, and definition of design at different career stages

• From Intern to Senior. Part 2: Design process, project scope, tooling, and 1-on-1 meetings at different career stages

• The Path to Senior Product Designer: Why Seniority is More Than Just Years of Experience

With additional years of experience, once you reach the senior level or beyond, you become an increasingly important member of the team with growing influence over strategic decisions related to design and product direction.

As an IC, you start participating in higher-level meetings where you represent the design function and the user perspective. These may include product or organizational planning and strategy discussions. Together with product managers, you collaborate on product strategy and take part in discovery and definition phases before moving into solution design.

Depending on the organization, you may be assigned as the lead designer on specific projects or products, taking responsibility for the overall UX and the delivery of business goals. In this role, you act as a subject matter leader, ensuring consistency and quality across the work of other designers.

Strong communication skills become essential as you collaborate with multiple teams and stakeholders and mentor less experienced designers.

From a design perspective, your work focuses on solving increasingly complex business and product problems. Systems thinking becomes critical, and you begin shaping new standards and processes within the organization. Projects at this level require careful communication to balance the needs of all involved parties.

You still design, but this typically takes up around 20 to 50 percent of your time. For a deeper look at this shift, I recommend reading this article.

At the Staff and Principal levels, your impact extends far beyond individual projects or products you are responsible for. You help shape design standards, define processes, and influence strategy across entire product areas or even the whole organization. You represent the user and design perspectives in the most important business decisions, often working directly with senior leadership, including VPs and the C-suite.

As you can see, the IC path allows designers to achieve significant influence over organizational direction, product strategy, and design outcomes, especially at senior and higher levels within the Super IC space. At the same time, it does not require moving into a management role. Design remains a core part of the job, even though it looks very different from what it did at the beginning of a career.

Areas and skills on the IC path

We have already briefly covered the characteristics of the IC path. Now I would like to take a closer look at the areas that appear along this path and the skills that develop within them at different levels.

When reviewing career matrices that describe expectations for different IC levels across various organizations, with links to selected examples included at the end of the article, it becomes clear that, beyond craft, additional areas appear at every level. These often include systems thinking, collaboration and communication, research, technical knowledge, and impact on the organization and other designers. Some of these have already been mentioned earlier.

Since organizations define areas and expectations in different ways, I would like to apply a certain level of generalization here. For the purpose of this article, I will focus on the following areas, along with a high-level overview of the skills they typically include:

• Design Craft

• Product Thinking

• Collaboration & Communication

• Impact & Execution

• Leadership & Mentoring

• Technical Knowledge

Design Craft

Design craft includes all core design activities such as visual design, interaction design, systems design, and prototyping.

At the beginning, this is mainly about mastering tools and basic methods. This includes correctness of components, attention to detail, fundamental design principles and patterns, information architecture, flow design, and the ability to explain and justify design decisions.

As experience grows, this evolves into building scalable design systems, caring for accessibility, and ensuring the highest quality of experience across the organization. From the senior level upward, ICs are characterized by a very high level of quality and consistency. They are able to design complex systems and define design standards for other designers.

Product Thinking

This area includes requirements definition, research, and participation in product vision and strategy. In many cases, designers are also expected to plan and conduct research activities.

At early stages, the key skill is understanding the problem and connecting user needs with business goals.

With increasing experience, this expands into work at higher levels. This includes co-creating product vision and direction, deciding which problems are worth solving, making conscious tradeoffs, thinking long term, and understanding the consequences of design decisions over time. As seniority grows, the partnership with product managers and business stakeholders becomes stronger and more equal.

Collaboration & Communication

This area fully focuses on communication skills and collaboration with other team members.

At every level, the ability to communicate design decisions clearly, receive feedback, and collaborate effectively with others is essential.

At more senior levels, this also includes facilitating workshops and design sessions, leading project discussions, engaging confidently with stakeholders, and giving high-quality feedback. Collaboration with both your own team and other teams across the organization is expected to be at a very high level.

Impact & Execution

This area reflects the impact your work has on the business and the organization, as well as how you execute your responsibilities.

At every level, you are responsible for completing tasks and delivering solutions that you take ownership of. Early on, this responsibility is smaller, but it grows with more complex and critical assignments.

As experience increases, you become better at thinking about the impact your solutions have on the organization and the business, rather than focusing solely on delivering screens or features. You improve your ability to prioritize, measure the outcomes of your design decisions, and work within constraints that you increasingly handle on your own.

Leadership & Mentoring

This area most often applies to designers at senior levels and above. It focuses on supporting the growth of less experienced designers, building the value of design within the organization, and educating other teams.

It also includes exploring, introducing, and promoting new ways of working and thinking, as well as identifying and adopting new tools and methods.

You may be involved in leading projects end-to-end as a design lead, conducting design reviews, making decisions at the team level, and supporting other designers in their work.

Technical Knowledge

The final area focuses on technical knowledge, which is an essential part of design work.

At lower levels, an IC should have a basic understanding of technology and awareness of implementation constraints through close collaboration with developers. This also includes knowledge of design tools.

As designers gain experience, they develop a deeper understanding of technical topics such as system architecture and technological limitations. They also expand their knowledge of emerging technologies, including areas like artificial intelligence. Strong collaboration with engineering teams is a key characteristic at this stage.

As mentioned earlier, I have intentionally generalized these areas and skills to present a broad view of the possibilities within the IC path. This does not mean that an IC must be equally specialized in every area or skill that an organization includes in its development framework. However, as experience grows, especially at staff and principal levels, solid knowledge across most of these areas is often expected.

Individual skill sets can also become a personal strength and may differ depending on whether the path applies to a designer, writer, or researcher. This is why it is difficult to present a universal skill set in a single article. At the end of this piece, I include links to several sources from larger organizations that show how they define areas and skills across different levels.

Can IC be a destination career path?

Absolutely. Staying on the IC path throughout your entire career is neither a better nor a worse choice. It is simply a different one.

The decision of whether to follow this path or move into a managerial role at some point depends on your preferences. It is also worth considering your natural predispositions, rather than treating management as the default next step.

It is important to remember that not every organization offers a fully developed IC career path. In many companies, the highest formal level is Senior Product Designer, which does not necessarily mean a smaller scope of responsibility or impact compared to roles such as Principal Designer. That is why it is worth understanding how IC progression looks in your current organization or in the company you plan to apply to.

We will cover the pros and cons of different career paths and how to choose the right one in upcoming articles. However, if you enjoy working on complex UX problems, diving into details, strategy, and system and technical logic, and you do not feel drawn to managing people, the IC path can be a very strong direction for your career.

Resources

• Product designer job levels at Intercom

• Product Design Roles at Buzzfeed

• Interaction designer role at Gov.uk

• Figma Product Design & Writing Career Levels

• Product Design Roles at GitLab

• Product Design Career Framework at Remote

• Titles for Designers at Basecamp

☕ Support our work

Premium is a simple way to support us as creators.
It’s just $5 a month (or $45 a year), and as a bonus, you get full access to our entire archive.

Subscribe now

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Happy 2026!

And welcome to our first-ever guest post!

This one was thoughtfully put together by our long-time friend, Alicja Białek ().

We first met Alicja a decade ago. We worked together at an agency where she was a Project Manager. After all this time as a PO and Delivery Manager, she recently switched careers to become a Transformation Coach for a large corporation and a burnout and executive coach for individuals.

Today, Alicja will talk about burnout.

This is the beginning of the year, and it feels like a lot of our resolutions revolve around getting our relationship with work in place. It has become our little tradition to publish an article about this absolutely vital topic, which is mental health, in January – don’t forget to check last year’s article on how to avoid burnout after reading this masterpiece from Alicja!

Burnout is like Tinder

Let me guess: you’ve already got your 2026 resolution list ready. Maybe it’s finally sticking to that gym routine. Deleting Slack from your phone. Setting a hard boundary at 6 PM—no more “quick sync” calls that somehow stretch until 8.

I’m cheering for you. I really am.

At the same time, I know that a gym subscription won’t fix your burnout if your design team is chronically understaffed. That meditation app won’t help if your stakeholders keep moving the goalposts mid-sprint. That “no meetings after 6” boundary won’t stick if saying no means you’re labeled “not a team player.”

I am saying all of this to demonstrate that there is a narrative that fixing burnout is on us. That if we just optimize ourselves enough, wake up earlier, meditate harder, set firmer boundaries—we’ll finally feel better and work better without burning out.

And I’m here to lift that weight off your shoulders: it’s not all your fault.

The exhaustion you feel after another round of “just one more iteration”? Not your fault.

The cynicism that’s crept in after watching your best design work get watered down in stakeholder review? Not your fault.

The growing sense that no matter how many pixels you perfect, it doesn’t actually matter? Not. Your. Fault.

You might be wondering why a burnout coach is showing up in your design newsletter. Fair question. Here’s why: I spent years watching talented designers completely burn out. Not because they weren’t creative enough or they couldn’t handle feedback on their work, but because the systems they worked in were fundamentally broken.

Designers are particularly vulnerable to burnout as their work is deeply personal yet constantly critiqued. You’re asked to be both wildly creative and rigidly systematic. You’re expected to advocate for users while stakeholders advocate for revenue. That’s not a design challenge you signed up for. This is where the erosion that might lead to burnout often starts. It’s not a fun destination. I’ve been there. It forced me to stay off work for 10 months, onto antidepressants, but ultimately, towards a complete redefinition of how I see myself.

What is burnout, exactly?

Look, the internet has plenty of definitions. “Chronic workplace stress.” “Loss of motivation.” “Persistent exhaustion.”

Technically accurate, completely unhelpful.

Here’s what burnout actually looks like for designers (taken from THIS Reddit chain):

Without going through all the details... new director, ultra demanding, workaholic, expected people to answer phones at 10pm, work until the job was done type...

Basically, after some 18 months of more and more being added to the pile, the only reward being more work, having to boon annual leave just to work undisturbed to get the work down and being pulled in too many directions I snapped.

Broke down completely in a meeting, then a day or two later when my 3 year old was annoying me like any 3 year old does, I almost lost it and lashed out at her. That was the final straw.

Over this person’s tenure, 6 of their 8 line managers left, including me. Some with nothing to go to. Other staff members were signed off with stress or depression. Others were prescribed sleeping pills…

That’s burnout.

Or:

The situation has been manageable for awhile but I’m reaching the point where I no longer enjoy going to work every morning and my work performance is slowly going down the drain and I don’t even care about that anymore.

I’m a pretty down to earth person and since I’ve dealt with a burnout before, I always try to set healthy boundaries with my workplace but I feel like it never gets respected.(…)

Ive also realized that what really triggers me is the amount of changes to the design and feedback we have since the clients are really indecisive and sometimes the process can take up to 1 month for a Facebook post because they keep asking for more and more variation « to see » what it looks like if we do it differently. Sometimes they will ask me for 3-5 versions of the same thing just so they can visualise. My workflow is pretty busy and we’re far from making 2-3 designs a day (for me it’s more of 5-10 designs a day), so making different versions of the same designs can be really time consuming, especially when deadlines are really tight. I’ve also tried voicing my concerns about the amount of work I have to deal with and even tried making a few « ready to use » templates to improve the workflow but they always want something « new ».

I’m starting to feel like I’m working on an assembly line and I really don’t know what to do to make the situation better.”

That’s also burnout.

Here’s the crucial distinction: burnout isn’t occasional. We all have mornings where we’re exhausted or days where nothing seems to get done. That’s normal. But when you’re drained every single day, when you can’t remember the last time you felt genuinely effective at work, when you’ve started to not care about things you used to be passionate about?

That’s chronic. That’s burnout.

The World Health Organization defines it as an “occupational phenomenon”—meaning it’s caused by your workplace, not personal weakness. And it typically shows up in three ways:

• Exhaustion: Not “I need a vacation” tired. More like “I don’t know if I can do this anymore, and sleep is not helping me rest” depleted.

• Cynicism: That defensive detachment where you stop caring, because what’s the point?

• Inefficacy: The growing belief that no matter how good your designs are, they don’t actually make a difference.

Burnout is all three together, creating a vicious cycle that’s hard to break on your own.

Your workplace is like dating on Tinder—and you need to spot the red flags

We miss the idea of a Great Love that will sweep us off our feet and give us a fairytale Happy End. At the same time, we have become disillusioned by the very same vision, by people we meet and effectively, by ourselves, feeling like there has to be something wrong with us, since we are still alone and all we meet are people who ghost us after the first date? Your relationship with your current job is similar to that. We scroll through job offers like dating app profiles, imagining ourselves in that role, with those benefits, in that organizational culture. When you first started, everything felt exciting.

Remember that feeling? The honeymoon period? The team was great, the projects were interesting, and you had energy for those Friday happy hours.

But somewhere along the way, things changed. Maybe you lie awake in the middle of the night thinking: Is it me? Am I just not good enough? Should I defend myself better? Should I just be less precious about my arguments (designs)? Am I being too idealistic?

And aren’t those the questions we ask when shit hits the fan in a relationship? When we start dating, we look for red flags. We assess whether things can change. We ask if this is still good for us. We don’t immediately blame ourselves, right?

So why don’t we do the same with work?

The burnout red flags hiding in your job

Here’s where science backs up your gut feeling: Christina Maslach and Martin Leiter spent decades studying burnout. Their conclusion? Burnout isn’t a personal failing, but a systemic workplace issue. “The structure and functioning of the workplace shape how people interact with one another and how they carry out their jobs. When the workplace does not recognize the human side of work, then the risk of burnout grows, carrying a high price with it.” In this text, I will be using quotes from two of their books “The Truth about Burnout” (1997) and “The Burnout Challenge” (2023).

Maslach and Leiter identified six critical areas where mismatches between you and your workplace lead to burnout. Think of them as the fundamental incompatibilities that kill workplace relationships. When these areas are out of alignment, no amount of meditation apps or boundaries will fix it. Because the problem isn’t you—it’s the relationship itself.

Let me show you what these red flags actually look like in your day-to-day work, with the hope that it will take some heaviness from you, and maybe you will start thinking of your workplace dynamics from a different angle. As Maslach and Leiter so nicely put it: “Workers’ experience of burnout says more about the workplace than about themselves—and that has important implications for defining problems and exploring solutions.” So the match between the worker and workplace is always a relationship issue and about the alignment of any of the dimensions.

🚩 RED FLAG #1: Work Overload

This one is typically the one we associate with burnout the most. Having too much to do, “hustle culture,” “always on.” I think we still have not recovered from the idea that having a lot to do is the measure of our success, that working overtime is better for your career than not having enough to fill in these 40 hours. But this leads to inefficacy, exhaustion, high levels of stress, and lack of sleep (to name a few). There is always more to do, there are too few resources, and not enough hours in a day. You’re juggling: design system updates, three product features, stakeholder presentations, user research, AND mentoring a junior designer.

What is worth noting, except for the piles of work?

• After intense sprints, you don’t have the time to recover and reflect on the job done (it’s okay to work hard for a short period, but we all need time to stop)

• You are punished for exercising your boundaries

• You lack the support to recover, with the amount of work given and the time you are expected to spend at work and during breaks

• You miss the resources and space to do your job effectively

🚩 RED FLAG #2: Lack of Control

Micromanaging manager? Not able to make a decision to move forward with your tasks? That can be so frustrating!! We want to feel competent, to have the autonomy to solve problems and use our knowledge. We want to feel we have a say in what we will be held accountable for. For some of us, this one can be even harder to deal with than the actual workload itself. “Policies that impose narrow constraints on how work is done (...) allow no room for judgment or innovation and leave workers feeling less responsible for their outcomes, not more.” If you feel you lack influence over the quality and type of job at hand, we might be onto something.

On a day-to-day basis, this might look like:

• There are a lot of different rules and processes that aim to constrain and control your work—specific regulations, time-logging rules to the minute. Every task you deliver is checked in terms of the time and resources it took to complete.

• Your leader changes your workload without explanation. Stakeholders bypass you and go straight to engineering. You find out about major product decisions from Slack, not the design kickoff.

• Design by committee means your cohesive vision becomes a Frankenstein of everyone’s “small feedback.”

• Your colleagues and supervisors are rigidly attached to “the way we’ve always done it”—no flexibility, no experimentation, no adaptation.

🚩 RED FLAG #3: Insufficient Rewards

We all want to be rewarded for our work, whether with money, security, prestige, or simply pride in a job well done. The reality is that money is tight, budgets are cut, and promised raises are not given. You do more for less. You lose your motivation. In the end, you are left with neither internal nor external gratification

What could this feel like?

• Your redesign increased conversion by 23%. Leadership celebrated the engineering team. Design wasn’t mentioned.

• The reward system at your company has no credibility or serves the employees’ interests (why do we want another Happy Friday if we only got a 2% raise?).

• The reward system is not transparent—who gets rewarded, why, and on what basis?

• Favoritism is alive and well.

🚩 RED FLAG #4: Breakdown of Community

How well you connect with your coworkers matters just as much as your actual workload, or maybe even more. Your day-to-day interactions with colleagues and managers are equally important to your sense of security and teamwork as your salary or benefits. If there’s conflict, lack of mutual support or respect, your sense of belonging vanishes, and you become an island.

As a designer, you often don’t experience the same built-in community that dev teams have. You’re a team of one, reporting to engineering. No one to review your work, share wins with, or vent about impossible deadlines. On top of that, other designers might view you as competition, rather than a collaborator. What’s important, the example comes from the top. If these behaviors are not modeled, employees don’t have enough incentives to make commitments to each other.

🚩 RED FLAG #5: Absence of Fairness

We already know that burnout is about the relationship. Viable relationships are based on such qualities as trust and respect. And it goes both ways: if we, as employees, are treated fairly, we feel like members of the workplace community. Conversely, we treat our workplace fairly when we have respect for the practices and processes and believe we can trust them. This mutual connection is a basis for a healthy workplace. “Cynicism, anger, and hostility are likely to arise when people feel they are not being treated with the fairness that comes from being treated with respect.”

What to look for when we talk about fairness?

• When we believe that the evaluation and promotion process is not handled in a just way

• Inequity of workload and pay

• When we get blamed for things you didn’t do

• When conflicts arise, they’re either ignored or handled poorly

🚩 RED FLAG #6: Conflicting Values

Very often, a mismatch in values is a critical factor in a person’s burnout. In the workplace, this dimension might be overlooked or misunderstood compared to the previous five. But people really care about whether they are being treated fairly or whether they are doing a meaningful job that they can be proud of. “What people find especially aggravating is that often organizations emphasize a dedication to excellent service or production while they take actions that damage the quality of work.”

So how might this red flag appear in your workplace?

• Leadership talks about being user-centered, but when it’s time to decide between what users need and what’s faster to build, engineering timelines win.

• You have to make trade-offs between the quality of work you want to do (and value more) and the work you have to do.

• The company says “design-led,” but designers aren’t in strategic conversations until the execution phase.

This is not about being “too precious”

These six mismatches show up in every industry. But designers? You experience them with particular intensity.

Because design work is inherently:

• Personal (your creative vision is on the line)

• Collaborative (requires buy-in from everyone)

• Subjective (everyone has “design feedback”)

• Undervalued (still fighting to get “a seat at the table”)

• Emotionally demanding (you’re advocating for people who aren’t in the room)

Look at those six areas again. Every single red flag points to organizational dysfunction, not your failure as a designer.

Maslach and Leiter are crystal clear about this: “Based on extensive research, we strongly disagree that ‘fixing the person’ should be the focus in dealing with burnout. We argue instead that burnout results from mismatches between the person and the job, and that solutions must therefore address both the workers and the workplace.”

When you recognize these red flags in your current job, your first instinct might be: “Maybe I’m overreacting. Maybe I am just being too precious about my designs. Maybe I just need to toughen up.”

And while it is quite natural to think this way, given the workplace climate many of us function in, I want to encourage you to stop. This isn’t about you being “too precious” or “too weak.” This is about your workplace failing to recognize the human side of work.

I’m not saying you should immediately quit. Some relationships can be repaired. Some mismatches can be addressed.

What I am saying: stop putting all the weight of fixing this on yourself.

Your 2026 resolution shouldn’t be “I’ll be less sensitive to feedback” or “I’ll just design faster.” But rather “I’ll recognize what’s actually broken and decide if this relationship can be repaired.”

Count how many of these six areas are mismatched in your current design role:

• 1-2 mismatches? Might be fixable. Start documenting the impact of design decisions, advocate for design in strategy conversations, and demand a seat at the table during those meetings.

• 3-4 mismatches? Requires significant organizational change. Consider whether leadership actually values design or just likes the aesthetics, or just needs somebody to draw what will be developed during the “real work.”

• 5-6 mismatches? You’re not in a design role. You’re in a production role with a design title.

Just like with Tinder, workplace relationships only work when there’s a real match, not you performing or shrinking to keep someone interested. The vibe should feel energizing, not draining. Values should align in practice, not just on paper. Boundaries should be respected, not something you have to fight for every single time.

And yes, you’ll make mistakes in the process. You’ll say “yes” when you mean “no.” You’ll give one more chance when you probably shouldn’t have. You’ll compromise on things that matter to you. That’s the growth part.

But it takes two to tango. If you’re the only one adjusting your steps, adapting your pace, compromising your needs? That is not a partnership, and you don’t owe anyone a solo act.

If the dance is one-sided, it might be time to find a different partner. There are so many other fish in the sea.

Here’s to 2026, may it treat us better than that hairy last date from 2025 that had too big an ego to even cry about!

Alicja Białek is a burnout prevention coach who learned about workplace dysfunction the hard way: 10 months off work, antidepressants, and a complete career reinvention. After 9 years leading IT teams as a PM and Delivery Manager, she now helps executives and creative professionals recognize organizational red flags before they break—and create work environments that don’t require self-sacrifice. She combines Harvard Medical School Lifestyle & Wellness Coaching with Certified Burnout Coach certification and is finalizing her ACC ICF accreditation.

Want to talk through your red flags?

• Connect with Alicja on LinkedIn

• Drop her a line

• Schedule a free, 40-min discovery session

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Increase your value with systems thinking

One of the key qualities of a good designer and a quality that can make you one is the ability to look beyond the narrow scope of the task you have been assigned and take into account all the other areas connected to it.

Designers at the beginning of their careers, although this also happens to people with more experience, often focus only on what is explicitly defined in the project scope. Designing a new form or a sign in flow? A few screens and the job is done. This kind of approach is work done in isolation, and as we know well, product design is definitely not a field where isolation works.

That is why, if you want to accomplish two of the most important goals in our work, identifying the real problem and solving it properly, your work has to be the opposite of isolation. It needs to include the perspectives of many people and teams, their requirements, business models, technological constraints, as well as internal and external dependencies related to what you are designing.

If you often find yourself in situations where it turns out you did not address all the problems or did not consider all the necessary perspectives, you should definitely take a deeper look into system thinking.

What is system thinking

Systems thinking is about viewing a product as a living, complex ecosystem where all elements influence one another.

To make this easier to understand, think of it this way: when you design a login screen, you do not focus only on individual screens. You think about the entire system. You consider how users create an account, log in across different devices, reset their password, switch between accounts, how accounts are managed from the organization’s perspective, which terms need to be accepted, what data users must provide, and whether a single step or a multi step form works better, and so on.

System thinking in product design

The concept of systems thinking appears across many different fields and at various levels of complexity. I would like to look at systems thinking from the perspective of building digital products. For me, it shows up in two key areas of product creation and development.

1. The first is identifying the real problem to solve, meaning making sure that we are addressing the right problem, which may exist much deeper within the system.

2. The second is preparing the solution itself, meaning taking into account all the necessary perspectives required to deliver a solution that meets the needs of the business, technology, users, and other teams within the company.

These are two extremely important areas that need to be addressed in sequence. At the very beginning, the highest priority should be placed on identifying the real problem to solve, because even the best solution has little value if it addresses the wrong problem. In that case, it becomes nothing more than patching symptoms. Only once we understand the real problem can we move on to designing a solution.

I would also like to point out that not every task we work on will require systems thinking. Very often, we will need to add or modify something that is not particularly complex, does not have deeper layers, or simply does not allow room for this kind of approach. This is natural and unavoidable in the world of digital product design.

Elements of systems thinking

To successfully apply systems thinking in your work, you need to focus on several elements that are crucial to this process.

Identifying the real problem

When working on a new solution or improving an existing one, it is essential to understand which problem you should actually be solving. As a designer, you should never take the problem handed to you by a PM at face value and should always make sure that the right problem is being addressed.

As mentioned earlier, a product is a system in which everything is connected. This means that poor click through on a purchase button does not always result from low visibility. The cause might be an inappropriate pricing strategy, unclear communication of the product value, lack of trust in the store such as missing reviews or weak product photos, an unclear delivery process, or hidden costs revealed only in the cart. Instead of solving the real problem, we often treat only its symptoms.

One of the better methods for getting to the root of the problem is the five why technique. Below is an example of a problem analysis related to search.

• Why do you need faster search? Because I look for the same thing five times a day.

• Why do you look for the same thing? Because there is no way to save it.

• Why do you not save it? Because bookmarks get lost and I have too many of them.

• Why do you have so many bookmarks? Because I use them as a to do list since the product does not have such a feature.

As you can see, the problem lies somewhere completely different. To notice it, you need to think systemically and go beyond the narrow area of the originally defined problem. If you simply improved the search, the user would still look for the same thing five times a day, only a bit faster, and their frustration would remain unchanged.

It can also be crucial to gather perspectives from other teams in the company, as they may have important information about the problem you are identifying. The real problem may exist in different parts of the system, the process, or the way various teams operate.

Thanks to systems thinking, you can understand where the problem originated within the system and what sustains it. Symptoms often appear in the most visible places, while the real cause lies deeper in the process architecture, company policies, technological constraints, or user behaviors.

Of course, it will not always be the case that the initial problem turns out to be the wrong one. Sometimes the purchase button truly is poorly visible. What matters is consciously validating the problem and not assuming from the start that it is definitely the right one.

Looking beyond a single screen or a single feature

I would start by saying that we should not focus solely on a narrow area that we are addressing at a given moment. When adding a new feature, flow, screen, or button, we should consider how this change affects the entire product, look at different usage contexts, existing solutions, the impact on users, and what surrounds it. A perfectly designed button in a poorly designed process is useless.

Understanding the relationship between users, business, and technology

As a product designer, you cannot focus only on user benefits. You must also consider technological constraints and organizational goals. Your solution has to be feasible within the current technology, the planned timeline, available resources, and budget, while also supporting company goals, which are often at odds with user goals. Thinking systemically means preparing a solution that balances these three areas as well as possible.

Recognizing patterns

A designer who thinks systemically can spot recurring problems and designs solutions that can scale instead of creating one off fixes. A perfect example is design system components. When solving a problem, you ask yourself whether an existing component can be used, and if a new one is needed, you analyze what other problems it could address with smaller or larger functional extensions.

Including perspectives from different roles

As mentioned earlier, systems thinking requires considering business needs, user needs, and available technology. However, these are not the only areas you need to keep in mind. A system is much more than that, and very often you will also need to consider guidelines from marketing, developers, feedback from customer support, or recommendations from legal and security teams. Ignoring these aspects early on leads to incomplete solutions that will sooner or later have to accommodate these needs, exposing the organization to additional costs. This was the case in my last project, where legal regulations were one of the most important constraints. Failing to meet them could have caused serious problems for the company.

Thinking about the product as an ecosystem with multiple participants

When designing solutions, you need to consider much more than just the end user. In addition to internal teams, you also need to understand what happens around the solution and its seemingly minor participants. For example, when designing an order system for users, it is valuable to understand how the process looks from the perspective of the warehouse, logistics, and customer support.

Designing consequences consciously

Everything we introduce into a system leads to consequences. Sometimes they are positive, sometimes negative, sometimes short term, sometimes long term. When thinking systemically, you should consider how a change will affect the current state of the system.

For example, heavily simplifying adding items to the cart and completing purchases may increase sales, but it can also lead to a higher return rate because users buy impulsively without much consideration. This can generate higher costs for the company than the value gained from increased sales volume.

Relationships and dependencies

You need to understand the relationships and dependencies between elements of the system. For example, adding comments to a website can be a useful feature because it increases the authority of presented products or services. However, it also requires expanding or creating a notification system, making decisions about login and registration, comment moderation, privacy policy updates, and additional technical costs.

The same applies to introducing dark mode. Systems thinking involves analyzing contrast, impact on branding, user behavior in different conditions, component support for dark mode, and consistency with other products in the ecosystem. Similarly, when designing registration and login, you must consider security, databases, and customer support. Every new feature or solution must be integrated into the entire system rather than existing alongside it.

Feedback loops

Systems thinking also involves anticipating how changes will affect the system over time. These changes can be intended or unintended. There are two types of loops, reinforcing and balancing.

Reinforcing loops amplify a given phenomenon, both in positive and negative directions.

Positive reinforcement example. Good reviews increase trust, higher trust increases purchases, more purchases generate even more reviews, and the system reinforces itself.

Negative reinforcement example. Introducing comments increases engagement but also attracts users seeking conflict. Over time, comments become more toxic, which may drive away other users.

Balancing loops stabilize the system and prevent extremes. For example:

• Discounts attract more customers, but a higher number of customers reduces margins, forcing the company to limit discounts and return to equilibrium.

• Users start using a new feature intensively, server response times increase, satisfaction drops slightly, and traffic decreases. The system returns to a level that is technologically stable.

System thinking increases your competences

As I mentioned earlier, the ability to take a holistic approach to design is a trait of every good designer. It helps you recognize that a product is always part of a larger and more complex system that includes social, environmental, and technical contexts. This understanding makes it easier to deal with the inherent complexity of design challenges.

As a result, the quality of your work is significantly higher because your solutions are truly aligned with the system rather than detached from it. It also allows you to deliver projects more efficiently, as it reduces the risk of overlooking important perspectives that can have a major impact on the outcome, such as legal or technological constraints. It also supports more accurate identification of the real problems to solve, which has a direct and meaningful influence on product quality.

Systems thinking is also the ability to ask the right questions at the right moment. It is definitely not a single checklist to complete in every project, but rather an understanding of what to ask in a given context. What needed to be considered in project A does not necessarily apply to project B.

If you want your work to be about more than just designing wireframes based on a provided specification, systems thinking is a skill you should absolutely develop further.

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

TL;DR:

• Recraft helps creators and teams maintain strong visual consistency across all design assets, from social graphics to ebooks, mockups, and illustrations.

• It offers high-quality image generation (raster + vector), built on its proprietary model Recraft V3, plus support for external models.

• Key features include photorealistic image generation, precise color control, true vector creation & vectorization, post-generation editing, and style-based generation.

• You can create custom styles using up to five reference images to ensure brand-consistent outputs across all new visuals.

• Recraft lets you generate, edit, recolor, upscale, and standardize assets without switching tools, making it ideal for cohesive branding and multi-platform content production.

• Overall, Recraft supports creators in producing professional, consistent, and scalable visual materials quickly, while maintaining full creative control.

Maintaining visual consistency has never been easier

Being a creator today often means wearing multiple hats at the same time. Whether you are shaping your personal brand as a freelancer, building your own product, or sharing your knowledge with a wider audience, you probably face a familiar challenge. How do you turn strong ideas into visuals that look clean and professional? The need for consistent social media graphics, a polished ebook cover, or a clear infographic usually comes up against the same limits that everyone struggles with: not enough time, a tight budget, or limited design experience.

Imagine a tool that supports you and your creativity while helping you produce visual materials that perfectly match a predefined style. This is exactly what Recraft offers.

What is Recraft

It is a tool powered by one of the best image-generation models, allowing you to easily create high-quality visual assets such as icons, illustrations, and logos. These assets not only look great but are also fully editable and scalable thanks to the built-in design features.

Recraft AI models

Recraft offers two proprietary models called Recraft V2 and Recraft V3. Recraft V3 is the newest model. It is used by default and recommended for most use cases. It performs very well in prompt adherence, layout control, and the generation of images with readable text.

You can also use external models such as Nano Banana, Flux 1 Kontext Max, Ideogram V3 Turbo, and GPT 4o High.

Key features

Recraft offers a wide range of useful features that support our daily work with visual materials. It allows us to generate images in any style we choose in both raster and vector formats. We can also edit generated or uploaded images with tools like the image vectorizer, image upscaler, AI image editor, background remover, and recoloring tool, which are only a few of the options available. It also makes it possible to create consistent visuals based on a selected style, and my personal favorite is to create a custom style using reference images.

To keep things simple and avoid overwhelming you with every possible feature, let us focus on the key functionalities that I find the most interesting.

Natural photorealism

What really stands out is the ability to create photorealistic images that, according to Recraft, avoid the typical artificial intelligence look. I think this is clearly visible in the example below:

When creating photorealistic visuals, we can also adjust the composition, which lets us generate both simple stock-style images and more complex editorial scenes:

The tool also allows us to create realistic visuals for product mockups, either by placing the product directly in the composition or by using composition elements to embed our materials.

Precise color control

Another feature worth highlighting is precise color control. This feature gives us complete control over colors when generating and editing images. We can use predefined color palettes or create our own based on hex codes, an eyedropper, or colors extracted from an image. For vectors, we can adjust colors using swatches or spectrum editing.

This feature makes it easy to match the colors of generated assets to a brand palette, edit colors in vector illustrations, or reuse colors from other graphics to align our generated materials with the company’s visual style and keep everything consistent.

Vector art & vectorization (market-unique)

Recraft also lets us convert raster graphics into fully scalable and editable vector graphics in SVG format. Once the image is vectorized, we can adjust individual colors or entire color groups and even simplify color palettes. This gives us visuals that can be used at any size and applied in print without any loss of quality. I would even say that the Recraft model is the best for SVG generation of all the ones I have had the opportunity to work with.

Post-generation editing

The tool also lets you refine the images you generated without having to start the entire process from scratch. The options available include fine-tune, edit area with lasso, brush, and wand selections, as well as inpainting, outpainting, and background tools. This allows you to remove or replace backgrounds, for example, with studio backdrops, adjust image formats for social media, or change a character’s facial expression.

Style consistency

Now, for one of the two most interesting features, in my opinion. Consistent styles let you generate multiple images based on a selected style. You can choose from many predefined styles or create your own, which I will describe in detail later. With style consistency, you can produce cohesive visuals and other assets, such as icons, for your projects or for promoting your brand on social media without losing consistency. The effect of style consistency is clearly visible in the example below, where the brand’s products are presented in a visually coherent way.

Custom style creation

Finally, here is my favorite feature, the one I explore the most. I mentioned earlier that you can create consistent graphics based on your own style. Recraft gives us exactly that. If you already have an established style for your company or personal brand, you can use previously created materials as references to build your own style that you can then reuse for new marketing assets that stay visually consistent with what you have created so far.

The examples below show how custom style creation works. First, you upload up to five reference images, then you can adjust how much each element influences the output, choose whether the style should focus only on basic attributes like color and texture or also preserve layout, and add a style level prompt.

Once we have created our own style, we can move on to generating images based on it. For the reference above, we get the following images:

And here is another example, this time in a realistic style:

We are also able to achieve great results with just a single reference image, again in a completely different style:

As I mentioned, the option to create a custom style and generate images based on it is by far my favorite feature of the tool. After seeing the examples above, I’m sure you can understand why. I believe it is an incredible aid in creating consistent and high-quality visual materials that we can use in our projects and products, as well as for marketing purposes for our business.

Recap

Recraft is an excellent support for tasks related to image generation and editing, allowing you to create exactly what you need at any given moment. Whether it’s icons required for our project, vectorizing a logo drawn in Procreate, or creating cohesive materials for our Instagram, Recraft enables us to produce content that not only maintains high quality but also, and just as importantly, ensures consistency in a faster and easier way.

The article was created in partnership with Recraft

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

0 → 1 Product Discovery. On approaching vaguely defined design problems with no data

I remember quite vividly when online design challenges became a thing. When I was still a junior designer, eight or nine years ago, I joined a couple of these with a lot of hope and energy. There was just one problem with them: they were heavily focused on the visual side of things.

Earlier this year, Miranda Slayter from invited me to join her secret project. I fell in love with the idea from the very start: it was meant to be a multiple-week challenge with experienced designers judging projects with a focus on strategy, not just pixels. Miranda invited several other great designers to help judge submissions, including Femke van Schoonhoven, Aneta Kmiecik, Nina Tahami, Karla Fernandes, Tom Prior, and Edward Sudjono. With a bit of help from beta testers, she picked the perfect name for the challenge: Why before UI.

My prompt for week 7 of the challenge, which finished just yesterday, was the most strategic as it could be. No pixels involved at all, since this was a whiteboard challenge. The scenario went something along those lines:

You walk into a big-tech interview and hear the classic prompt above. Nothing else is provided: no personas, no data, no mock-ups.

The purpose of this exercise is not to produce polished UI on the spot, but to show that you can frame the problem, surface knowledge gaps, and plan discovery before drawing screens.

For this week’s challenge you’ll simulate that moment.

“Design a financial app for kids.”

In today’s article, I’m covering how I’d approach such a challenge. At the end, you’ll find some universal takeaways for working out uncommonly ambiguous tasks like this one in a corporate environment, not just from the lens of a whiteboard challenge one may get during a job interview.

Getting started

A challenge like this one can be frightening. You start with a blank sheet of paper. No requirements, no goals, no data. The ambiguity of such a project is the highest you can imagine. But with the right approach, it shouldn’t overwhelm you – just take a deep breath and try looking at it from a helicopter view. No one sane would expect that you’ll be delivering here any mockups or prototypes, but rather a plan. We’ll try to come up with a high-level plan for gathering more data and reducing the level of ambiguity.

Small steps method

We will follow The Small Steps Method, which is basically slicing this monstrosity of a task into smaller, manageable (and not so scary!) chunks of work – a discovery for a real project like this would take weeks before a designer would touch Figma and put the first pixel on a canvas.

We need to think about what we don’t know today, what’s most important to learn in the first place, and how we might gather this knowledge. Hopefully, this data will unlock new doors and help us move the needle.

Setting constraints

Because it’s an open design challenge for everyone rather than a whiteboard exercise typically seen during job interviews, there are no constraints set. The brief is super simple: “Design a financial app for kids.” We have to extend it a little by setting a scene.

Because every market has its own regulators and rules when it comes to finance, we need to narrow our brief down. Since I live in Poland, I’m picking this market as my constraint.

The second constraint is the business context. Who’s asking us to do the discovery work – is it a startup or an already established institution, such as a bank, which is trying to create a new offering? For this particular exercise, let’s pick a bank.

Initial questions

In this very first step of the exercise, I’ll try to list out everything that I don’t know. This will later inform my research plan and hopefully help move the needle. At this stage, it’s important not to make too many assumptions and to stay open-minded. It’s better to go super broad with the questions and eventually trim the list down to the most important ones. I’m splitting my questions into four themes: Monetization and Brand Positioning, Regulatory, Competitive, and Viability.

Monetization and brand positioning questions

These questions will help set the brand positioning of the offering and validate ideas for monetization.

1. What tone of voice (serious & safe vs. playful & gamified) is appropriate without diluting trust?

2. How can we monetize this product? Would parents pay a small subscription fee for premium features, e.g., an educational module?

3. Do parents see the bank as a trusted partner in their child’s financial education?

4. Can this increase family loyalty, e.g., parents consolidate accounts with our bank?

5. How many users do we need for break-even?

6. From the stakeholders’ perspective, what is the ultimate purpose of building this app? Is it a long-term game of building a relationship with the brand at a young age and eventually converting them into adult customers?

Regulatory questions

These questions should help me understand the rules and regulations set by authorities for finance apps and services in my market.

1. What are the advertising and monetization restrictions for minors in Poland/EU?

2. What are the age-based restrictions to be a primary user of a banking system or to have a joint children’s account with the parent’s account?

3. How to approach GDPR & Polish/EU rules on children’s data collection and parental consent?

4. What’s the right age for children to start educating them about finance?

5. What risks (fraud, misuse, reputational) must be mitigated?

Competitive landscape questions

This subset of questions will help me understand what other players in the market are doing in this area.

1. How are other banks and fintech apps already approaching this opportunity? Do they position themselves more as financial education tools or as spending/payment enablers?

2. How do competitors segment their audience (age, parental involvement, digital natives vs. younger kids)?

3. What’s the main attractor for minors in adjacent contexts, e.g., mobile gaming, online gaming, and what can be borrowed from there to a banking app?

Viability questions

These questions are designed to uncover whether the project is worth building from the business POV.

1. What transaction limits (e.g., spending caps, parental approvals) are feasible?

2. Do we have the technical infrastructure to support child-specific profiles or sub-accounts?

3. How easily can this product integrate with existing banking products?

4. Does this initiative support long-term customer lifetime value (e.g., onboarding future adult customers)?

Research plan

Once I establish what questions I want to uncover and what data is needed to move the needle, I need to create a research plan. I’ll go super lean and just stick to assigning research methods to four main themes. At this stage, I’m not going to come up with a full plan, commit to any timeline, or list out potential risks. In a corporate environment, it of course would be required, but for a whiteboard challenge, this should do the trick.

Monetization and brand positioning

1. IDIs or surveys on willingness to pay.

2. Usability tests of freemium prototypes to uncover perception of premium features.

3. Financial analysis/modeling with the finance team to check what’s the break-even.

4. Benchmarking on hooks for children, pain points solved for parents, and tone of voice.

5. Stakeholder interviews or workshops on goals.

6. Focus group with parents on brand perception, trust, and loyalty.

Regulatory

1. Desk research into GDPR and KNF (Polish Financial Supervision Authority) guidelines.

2. Expert consultation with the compliance/legal team.

Competitive

1. Benchmark apps from fintechs and local banks.

2. Benchmark apps from banks in the EU.

3. Look at adjacent apps parents and children trust (Duolingo, Roblox, educational platforms).

4. Identify unmet needs (e.g., parental trust, safe social features, gamification) with IDIs and focus groups.

Viability

1. Diary studies with parents and kids about current money habits.

2. Fake-door tests to measure sign-up interest.

3. Expert consultation with stakeholders managing adjacent offerings and tech leads on the infra side of things.

4. Stakeholder interviews or workshops on goals.

Success metrics

The success metric will tell me if discovery and later product design are on track. As you can see, I have avoided assigning numerical goals that the product team would try to hit in the future once the product is released. It’s way too early to tell what exactly is going to be released and come up with KPIs that make sense.

1. Parent sign-up conversion rate (from awareness → download → account setup).

2. Children/parents engagement (weekly active use).

3. Retention after 3–6 months.

4. Net Promoter Score for parents.

5. Usability score (or fun score) for children.

Universal tips

Whenever you are facing a whiteboard challenge like this one during a job interview, or a real problem in a corporate environment, when your boss asks you to explore new market opportunities, there are a couple of things to keep in mind to stay sane during the project:

• Don’t assume too much in projects like this one. This brief is one big unknown – when you think about a scale of ambiguity, this is at the end of it. What’s more important is actually to think about what you don’t know and what you need to learn to move the needle.

• Use the small steps method. Don’t try to uncover everything at once; it’s impossible. Be realistic with your research plan and don’t try to please stakeholders by saying you can have all the data within two weeks.

• Success criteria in this phase are tricky. Avoid setting any numerical goals, like hitting 70% of something within the first month after release, when you don’t have an idea what (and when) you’re actually going to release.

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Subscribe now

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Experiment like never before

Recently, I took part in an internal workshop where we worked on a new registration flow for one of our products. At one point, someone from the team asked, “What if we approached registration in a completely new way and got rid of the typical sign-up form altogether?” The idea sounded a bit abstract at first, but it quickly caught on, and we spent some time discussing it. Meanwhile, another team member created a fully functional prototype in just a few minutes using Figma Make, something we could instantly validate with users.

Not long ago, this would have required building clickable mockups that probably wouldn’t fully convey our idea and would have been a weak basis for validation, or involving developers to build a prototype we’d likely have to wait several days for. Today, we can have it almost instantly. Not to mention, we probably wouldn’t even be able to allocate resources to create something that abstract.

Thanks to tools like Figma Make, we can very quickly build and test prototypes of the solutions we are currently working on (as we did with our new registration flow), as well as those that might initially seem completely crazy. This opens up more room than ever before for experimentation and testing entirely new approaches in product design.

Not just crazy ideas

Even though at this stage we do not have much room to experiment with completely wild ideas, AI support is still invaluable for more everyday tasks where having a prototype is essential to ultimately deliver a product of the right quality.

The biggest value I see in the easier creation of prototypes, whether from scratch or using previously designed screens, lies in two areas: rapid prototyping, which we use most often, and the research through design method.

Rapid prototyping

Rapid prototyping is about quickly creating a prototype, collecting feedback, and improving the design. Time plays a crucial role, as the method assumes that the entire process happens relatively fast. Until recently, this was a major limitation because it meant we could not build complex, high-fidelity prototypes and had to rely on low- or mid-fidelity wireframes to gather feedback quickly and move forward.

Now we can create high-quality prototypes much faster, ones that are not very different from standard working solutions. This allows us to gather more valuable feedback than with low-fidelity wireframes and to test a greater number of ideas, which gives us more room for experimentation.

The value of faster and higher-quality prototyping is also visible in more traditional design and testing processes with users, which typically took much longer than rapid prototyping. In addition, AI supports us in preparing research scenarios, analyzing results, and summarizing findings, which further reduces the time needed and lets us either move forward with the project faster or accomplish more in the same timeframe.

With the current level of AI support and the significant reduction in the time required to prepare prototypes and tests, the line between rapid prototyping and a more traditional process is becoming increasingly blurred. Of course, time is not the only difference between these two approaches. Factors such as scope, goals, and sample size also matter. However, distinguishing between quick and non-quick usability tests no longer makes much sense, since the time needed to build prototypes, run tests, and analyze results is significantly shortened in both cases. This allows us to focus on the goals we want to achieve through testing without the compromises that used to come from time constraints.

In our case, while working on a registration form, the support of Figma Make proved incredibly useful. From all the working versions, we prepared two final ones that we wanted to test with users to find out which approach would result in more users completing the registration process. After designing the wireframes, we transferred them to Make to create fully functional prototypes. The entire form behaved exactly as it would in production. All fields were interactive, validation worked, we could simulate SMS code confirmations, and even check how users understood password strength. The form knew the password requirements and displayed information about whether the entered password met them and how secure it was. What would normally take a developer several days to build was achieved, including prototype refinements, in less than half a day. We also did not have to rely on traditional wireframe-based prototypes, which are not well suited for testing forms.

Importantly, we did not use AI tools to generate static screens. Those were still designed manually, and the prototypes were based on them, as the results we obtained when experimenting with AI-generated sketches and ideas were not satisfactory.

Research through design

Research through design is a method that uses design as a way to conduct research and generate new knowledge. In this approach, we create prototypes that serve as the foundation for our studies. Even during the process of creating them, designers can already draw valuable insights. RtD supports gaining knowledge that would be difficult or even impossible to obtain without using previously created prototypes in research, both on the side of designers and the users participating in the studies.

From my observations, the research through design method is not as popular as other research approaches. Yet, this is precisely where, if the organization provides the space, we can experiment and seek innovation. It allows us to test and gather knowledge about completely new, previously unexplored solutions and directions.

However, in many organizations, there is often no room for experimentation or innovation. It is a more time-consuming process and may not fit into current priorities. Thanks to AI, this might be changing.

I have already mentioned the role of AI in supporting prototyping. It now enables the rapid creation of advanced prototypes that are almost indistinguishable from real products. In the case of RtD, the value gained from this is equally significant, as it opens up new opportunities for product teams to explore ideas that previously did not fit into their schedules. Experimentation and innovation have become faster and easier, which means they now require fewer resources and can be more easily integrated into ongoing work.

RtD the new product discovery?

As I mentioned earlier, this method is still not widely adopted, but that may soon change. From conversations with other designers at a recent conference, I learned that many product companies are testing approaches inspired by RtD. Instead of conducting time-consuming discovery processes, they shorten them by moving directly to creating a prototype and learning from it.

Thanks to AI, designers can now build and test prototypes much faster than a traditional discovery process would allow. Could an RtD-inspired approach become the new standard for product discovery, offering equal (or even greater) value in less time? It is probably too early to say, but it is certainly something worth keeping an eye on.

A few thoughts to wrap up

To conclude, I want to share a few reflections from our recent experiences. These are not meant to be in-depth tips on using AI tools (we will cover that in a separate article), but rather a few simple suggestions to apply when creating prototypes. For those who are already at an advanced level, some of these points may seem obvious.

First, tools such as Figma Make and similar ones, while improving rapidly, are still far from perfect and are not suitable for every use case. Based on our experience, we are currently unable to achieve high-quality UI output or accurate implementation of our design system. For now, we use these tools primarily for prototyping and testing purposes.

It is also crucial to prepare prompts carefully and treat the tool more like a junior designer who needs clear guidance rather than a senior designer who will figure everything out on their own. The more context and clear instructions we provide, the better the outcome. Editing generated artifacts can also be tricky, as requesting changes sometimes alters more than we intend.

That said, especially in the early stages, it is worth testing different tools to see which ones fit your needs and limitations best. For example, one of our current constraints is the decision not to sync our Storybook library with AI tools. Keep an eye on updates too, because with the current pace of development, entirely new capabilities can appear overnight. I highly recommend following official sources such as OpenAI or Anthropic and their team members rather than self-proclaimed experts trying to sell you courses.

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Subscribe now

Partnerships and socials

• Partner with us via Passionfroot

• Arek’s LinkedIn, Instagram, and TikTok

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

A few weeks back, I was curious what other designers think about vision and strategy. I asked my LinkedIn followers how important it is for designers to be able to craft or influence the product’s vision. While it’s not usually part of our job description, no one voted for “It’s not important.” 62% of respondents said “Extremely important,” and 38% said it’s “Somewhat important.”

A conclusion? We, as designers, want to create products that are not only nice-looking and easy to use. Our aspiration is to be in the driver’s seat and take a more strategic approach to our work.

Earlier this year, my product manager and I decided to spend an entire two-week sprint (which ended up being a significantly longer process) crafting the vision for our product. We have never done that before for this product. Someone else proposed the previous vision, which was quite vague and not bold enough. In the last couple of years, we have done everything to fulfil it, and it required an update.

In this two-part series, I’ll share the process of crafting the five-year vision statement and the mid-term strategy for the next twelve months (part 1 and part 2) and the key differences between a tactical approach and visionary work from a designer’s perspective (part 2).

Crafting a vision statement ain’t easy

After going through the entire process of crafting a vision statement and supporting strategy, one thing I can say for sure is that it’s not an easy task. If you think of a scale of ambiguity in projects you’ll be doing as a designer, this breaks the scale by an order of magnitude.

When you sit down and start the work with a blank sheet of paper, you know absolutely nothing. How can you tell what your customers will want in the next five years? What makes you think you would know what the world will look like in the next five years? How do you know where your business will be in the next five years?

Well, you can’t. But the fun part is that this whole exercise is about envisioning the future and trying to shape it as you want.

There are some more takeaways that I collected from this process:

• Visionary work is hard. Having a sparring partner makes it easier.

• When your organization already has a mission statement, it can inform your vision and be a nice starting point.

• Vision should be bold and span a few good years in the future. There’s no point in not being ambitious.

• Vision should inform the mid-term strategy that you and your team will commit to following.

• Hang the vision statement on the wall so you can see it every day and refer to it when you are unsure if you are still on the right path.

I’m also sharing the entire process. It’s not a framework. It’s just a list of steps we naturally took, but somehow it clicked. Feel free to adjust it to your needs when you put effort into crafting a vision of your product.

It takes time to craft a vision

As you already know, two weeks weren’t enough to create the vision and efficiently communicate it. Instead, we spent almost two full months doing it. However, it was even a few months earlier that we took the first step and realized this work was needed. It’s a long process:

1. Realization

2. Mission statement as an inspiration

3. Wearing a detective’s hat

4. Finding adjacent areas

5. Drafting a bold statement

6. Supplementing it with a story (part 2)

7. Crafting a mid-term strategy (part 2)

8. Envisioning customers’ interaction in the next couple of years (part 2)

9. Addressing future needs (part 2)

10. Communicating vision to the stakeholders (part 2)

Let’s take a look at each step in detail.

1. Realization

When a year is coming to a close, product teams naturally start to plan the next twelve months, at least on a high level. Product leaders discuss with stakeholders what the organization's overarching goal will be next year and how each product can support it. When we approached this checkpoint at the end of Q3, we realized that we don’t only need the strategy for the next year, but also that our vision had to be slightly updated – or rather revamped from the ground up. Since the previous one seemed to be already fulfilled, we were forced to look for something completely new.

Such a realization may occur at various moments. It could be at a super early stage of a new project or a bit later if it wasn’t properly set in the beginning. The earlier, the better, as it sets the direction for the entire team and serves as a reference that people look at when in doubt and wondering if they are heading in the right direction.

2. Mission statement as an inspiration

Starting with a blank sheet of paper is super challenging, no matter what you are doing: writing an article, creating a prototype, or crafting a vision statement. As our previous vision wasn’t up to date or inspiring enough, we looked at the mission statement of our company as a stimulus.

Not gonna lie, we also looked at big players’ mission statements to see how they formulate their. But it wasn’t inspiring enough. Just look at Microsoft’s “We empower the world” or Apple’s “To create technology that empowers people and enriches their lives.” These are very broad and vague, as you would expect from a multi-billion-dollar corporation with hundreds of thousands of employees, multiple lines of business, and countless product teams.

If you want to get inspired by mission statements from other companies, look for smaller organizations, specifically those focused on one area of business, such as SaaS products. Of course, they have to be quite mature to have mission statements, but such companies exist.

3. Wearing a detective’s hat

As we already established, the level of ambiguity in such a project is at an extreme. Until you do some research, gather any data, and look for market signals, you’ll walk absolutely blind.

The first thing we did after we realized we needed to look far into the future was to set up a series of interviews with people from the customer-facing team. We asked them what our customers are talking about, but not in terms of our current offering or things we’ve already heard of and planned to address. Are there any potential use cases that we could address but haven’t considered before? Do we explore any new markets or industries? Is there any groundbreaking technology being developed behind the scenes that we could use or integrate with?

Additionally, we have also done our desk research. We looked for market signals and read a few reports from adjacent industries. We went quite broad, considering new markets and even entirely new products we could build on top of our existing technology.

4. Listing areas adjacent to our product

Our product, in short, serves as a delivery platform where our customers can pull the NatCat GIS data via API or through a user interface. They can preview these files to understand what natural catastrophe events are happening now and how they are impacting their businesses. So far, we are working with two types of customers and addressing some of their use cases.

In addition to thinking about other, less obvious use cases for the same customers (or for other customers from the same bucket), we decided to get creative and look further. We went broad and tried to list out every possible role or type of business that could benefit from the data product that we are offering. Later, we did a short analysis of opportunities to determine which ones are worth exploring further. We ended up with a shortlist of topics that seemed interesting and promising.

Once we had everything on a single board, we noticed a pattern: regardless of the industry or the jobs they may have (JBTD), on a very high level of abstraction, our customers come to us with questions, and we can provide them with insights.

That light bulb moment led us to craft a bold vision statement.

5. Drafting a bold vision statement

I can’t share the vision statement that we came up with yet, but believe me, it’s bold. And it should be bold and ambitious, because if it wasn’t, what would be the point of trying?

Once we figured out the pattern in how we might help our customers in the next couple of years, we spent a solid session on figuring out the wording. That was probably the worst part of this entire process. Even for me, who’s been writing articles for this newsletter for the last two years, coming up with one sentence that is ambitious, inspiring, and encapsulates everything that we want to achieve or the world we want to live in over the next five years is quite a challenge.

If you are facing the same challenge, follow the steps we have tried:

• List out product areas you want to attack in the future period that you’re considering when working on a vision statement (e.g., as a fintech startup, in the next five years, we want to be doing more of automated investing and peer-to-peer lending).

• Create a list of words that you feel should be a part of the vision statement (e.g., as a fintech startup, we want to be perceived as “safe” and “modern”, and we want to ultimately “change the way” people invest and lend money to friends).

• Go crazy and throw out whatever comes to your mind. Write it down on a board. It’s your first draft, and you can continually improve it. It led us to create a sort of mind map. As we iterated on the statement, more words and product areas started popping up in our heads, eventually enabling us to form the final vision statement.

Got it?

Congratulations!

It takes blood and tears to come up with this one sentence that warms hearts, inspires, and leads through times of uncertainty.

But here’s the catch: your job isn’t over yet: you need a story and a strategy supporting the vision.

Now get some rest.

Part 2 in late November

The five remaining steps (Supplementing it with a story, Crafting a mid-term strategy, Envisioning customers’ interaction in the next couple of years, Addressing future needs, Communicating vision to the stakeholders) will be covered in part 2 (coming late November), in which I’ll also compare tactical design with visionary design in more detail. Subscribe and don’t miss it!

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Get 20% off for 1 year

Follow us on other channels

• Arek’s LinkedIn, Instagram, TikTok, and Twitter (X).

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Response time in UX

People are impatient, they dislike waiting, and they expect things to happen instantly. This is especially true today, when it’s harder than ever to capture and hold someone’s attention. Within just a few seconds, users decide whether the content they’re seeing is valuable to them, and it takes only slightly longer for them to lose focus and abandon a task if the interface responds too slowly or fails to provide clear feedback.

That’s why time, and more specifically the interface’s response time to user actions, matters so much. Let’s take a closer look at it.

How time shapes experiences

Almost everyone experiences delays in a similar way, whether it is during interactions with digital products or in everyday life. When something does not work instantly, freezes, or when a courier simply arrives late, frustration and irritation appear, especially when we do not receive any feedback about what is happening or why.

In the case of digital products, users judge the speed and smoothness of the experience. Products that create a sense of immediacy lead to better overall user experiences. This is not about measuring time with a stopwatch but rather about the subjective perception of users.

Delays in interfaces also have a direct impact on business metrics. According to Akamai report, even a 100 milliseconds delay in website load time can reduce conversion rates by 7%, and a 2 seconds delay can increase bounce rates by 103 percent.

There are several time thresholds worth knowing in order to properly manage the response time of an interface.

Key time thresholds

In 1968, Robert B. Miller published his article Response Time in Man-Computer Conversational Transactions, in which he examined and described three time thresholds that remain relevant to this day:

• 0.1 second

• 1 second

• 10 seconds

In the context of UX, these thresholds were popularized by Jakob Nielsen, who described them in his 1993 book Usability Engineering. Let’s take a closer look.

0.1 second

Any interface response that occurs within 0.1 seconds will be perceived by the user as instantaneous. It also enhances their sense of direct control. This response time applies to direct interactions such as mouse movements, key presses, clicks, dragging elements, or any other interface interactions that happen immediately.

1 second

The next threshold is one second. In the range between 0.1 and 1 second, the user notices a delay but accepts it as a natural processing time. They still feel in control, and their flow remains uninterrupted. This time range usually applies to actions such as navigating between pages.

10 seconds

The last of the three thresholds is 10 seconds. Response times between one and ten seconds are noticeable to users, and while they remain focused on the task, their motivation begins to drop. They start to feel like they are waiting for the system to complete the task. This often applies to actions such as loading complex reports, exporting data, or uploading files.

Once the ten-second threshold is exceeded, users lose focus on the current task and start thinking about something else. When the task finally completes, they need to refocus, which requires additional mental effort. There is also a risk that once users lose concentration after waiting for more than ten seconds, they may not return to the task at all, which can result in abandoning the page or application.

It’s worth noting that the time thresholds mentioned above are not fixed. Much depends on the type of interaction, the context, and the individual user. Immediate execution without any feedback is not always the best option.

How to manage delay

We do not have full control over how long it takes for an action to be completed. Of course, we would like it to be as fast as possible, but that is not always achievable. The system may not be optimized at a given moment, some actions may take longer for technical reasons, or simply the user might have a slower internet connection or weaker device.

That is why we need to understand how the system should behave so users do not feel the negative effects of waiting too long. Referring back to the previously mentioned thresholds, it is crucial to focus on delays that fall within the third one. The first threshold, for obvious reasons, does not require any special handling. The same goes for the second one, where the delay is short enough that additional feedback is unnecessary, as the change is often visible naturally, for example during a page transition. The third threshold, however, has the most significant impact on potential negative user experiences, as delays become clearly noticeable.

For delays between 1 and 10 seconds or longer, it is crucial to provide feedback indicating that the system has responded and is currently processing the action. Without such feedback, users might assume that the system has not reacted to their input, try repeating the action, and if they still see no response after several attempts, they might abandon the task or even leave the product entirely.

On this page you can see what this looks like in practice. You will find several time thresholds demonstrated with and without user feedback.

Since feedback is key, what exactly should we communicate to the user? For shorter waiting times (up to 10 seconds) or in cases where we want to provide feedback just in case, the most common approach is to use animated elements that show the system is working. These can be skeletons or spinners (also known as loaders). Skeletons give users a sense of structure and progress, while spinners only indicate that something is happening without giving any sense of duration. The choice between the two should depend on the context and technical possibilities.

It is important to ensure that loading indicators appear after the appropriate delay, as showing them too early can create a flickering effect when the element appears and disappears within a fraction of a second.

When the waiting time exceeds 10 seconds, and when it is possible to calculate progress in real time (for example, while uploading files), it is better to use components such as progress bars that indicate the current progress along with the remaining time or percentage.

You can also enhance loading states with contextual messages such as “Uploading file,” “Loading data,” or more casual ones like “Almost there…” or “We’re getting things ready for you.” Such messages can make the wait feel shorter and less frustrating.

For operations that take significantly longer, for example several minutes (such as uploading a video), users can be allowed to continue performing other actions while the process runs in the background. Once the task is complete, the system should notify them.

When large and complex views need to be loaded, you can use a technique called progressive loading, which is most often applied in SaaS applications. It means that the entire interface is loaded in chunks, starting from the simplest structural elements and gradually adding more data, finishing with the heaviest assets such as images or content below the viewport.

In recent years, we have also seen the growing use of so-called optimistic UI. This approach displays the result of an action instantly, without waiting for the server’s response. For example, liking a post or adding a comment appears immediately, while the actual operation is processed in the background. If an error occurs, the change is reverted, and the user receives an appropriate message. This technique works especially well for actions with a high success rate.

It is important to remember that while we cannot always improve actual performance (the real speed of the system), we can always improve perceived performance. This refers to the user’s subjective feeling of how fast the interface responds. Small UX techniques, such as skeleton screens, microanimations, or early partial content, help users feel that the system is responding faster even when the total processing time remains the same.

Finally, while this article focuses mainly on websites and desktop or mobile applications, these principles apply to all types of interfaces that humans interact with.

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Subscribe now

Follow us on other channels

• Arek’s LinkedIn, Instagram, TikTok, and Twitter (X).

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Articulating design decisions

Countless times, I’ve heard stories of designers who, when asked why they did what they did in their projects, answered with “I don’t know” or “it just looked good this way.” If that ever happened to you, this article will help you skill up in defending your design rationale and speaking about your designs with confidence, authority, and competence.

In other words, you’ll start sounding like a design expert, and your design decisions will defend themselves.

Everything begins with making the right tactical calls while keeping the strategy in mind, rather than randomly throwing design system components on the canvas. There are a few core elements of preparing yourself for a big meeting with stakeholders who can be asking difficult questions:

• Following the design process smartly

• Backing decisions with evidence

• Exposing yourself to feedback often

• Speaking the language of the audience

Let’s look at each one in detail.

Following the design process smartly

I may sound like a broken record, but there’s no single design process that fits all projects, and you should already know that. That’s why knowing what you’re doing to solve a design problem and being able to explain it later to stakeholders and colleagues is all about adapting the design process to the particular project.

If you’re a recent uni grad or just finished a design bootcamp, you may believe that the process that you were taught has to be replicated and followed strictly in every single project, no matter what – that’s untrue. It’s rather the first step to not having the correct answers about your decision-making.

Just imagine this conversation:

- Why did you do that?

- This is the process I was taught, so I’m following it.

Your stakeholder probably won’t be happy to hear this.

So, how do you not forget about the processes, make smart decisions, and not lose your soul in the meantime?

✅ Do more of this:

• Adapt the process to your project. Make a plan in the very beginning. List the core questions you need to answer to cut through uncertainty, reduce the level of ambiguity, and move the needle.

• Be able to jump on ideation and fail quickly. We are currently living in an era of big shift. Jumping into the solutions space is now much cheaper than it used to be and opens up new ways of discovering insights.

• Document your steps and decisions. It will be much easier to track back why you did what you did when the project is long and extensive, and some details are already forgotten. When a stakeholder asks you a tough question, you can recall your notes and say, “Research suggested to use this variant over others we tested”, or “This is the standard way of building a form that users are familiar with by using other tools.”

❌ And avoid doing this:

• If you are working on a project for an existing and quite mature product that people already use, you’ll not need to create personas or an empathy map – you most likely already have this figured out.

• An extensive research when working on a highly ambiguous project? Yes, but only to the point when you're ready to propose a potential solution to gather more insights quicker and have a conversation about a tangible thing.

• Writing user stories and shaping MVP? Yes, but only when a solution is validated with the customers and users, stakeholders are more or less aligned, and the engineering team is involved in discussing the scope.

Backing decisions with evidence

It shouldn’t be surprising to anyone if I tell you that data is the ultimate argument when discussing design with tough stakeholders. If you have ever found yourself in a room with a stakeholder asking difficult questions about certain decisions made in the design, and you struggled to find a good answer, the reason was most likely a lack of data.

While intuition is extremely important, it can only be trained with experience. You probably shouldn’t trust your gut feeling every time when you've just started out in your career in design. Once you do more projects, talk to hundreds of users, ship useful features, and gain more experience, you’ll get better at making some decisions with zero or little data.

✅ However, if you are starting your career or the project you’re working on has many unknowns and requires gathering data to move the needle, here’s what you can do:

• Always start with desk research. Look out for information online. Try the competitor’s product. Use AI to help you cut through market reports or scientific papers.

• Cooperate with your product manager, internal researchers, and data analytics specialists. Look for the trends in your product analytics data. Ask account managers and customer support folks to hear what the voice of customers is about.

• If you have the internal capability to run research with real users or a budget to hire an agency, create a research plan and use the time and money wisely. Avoid doing research just for the sake of research.

• Once you create a mockup or prototype, test it with users or conduct guerrilla tests with your colleagues to verify that what you have created is usable, intuitive, and easy to use. Track metrics such as Error Rate, Time Spent on Task, or Success Rate, and use these numbers in conversations with stakeholders.

Exposing yourself to feedback often

Have you ever locked yourself down for a few weeks in your safe place and returned with a beautiful and almost perfect prototype, only to find that after presenting it to the product team and stakeholders, you needed to redo most of it, and you feel like you've lost weeks of work? I’ve done this a couple of times in my early days, and I know it can be super discouraging.

A much better approach is to expose your work to feedback often. Feedback is a gift, and it has to be treated like one. Feedback allows us to grow as designers and make our products better.

✅ Here’s how to make this work in practice:

• Schedule a recurring design feedback session with your product team and show them what you’re working on regularly. This will help you probe if you’re moving in the right direction.

• If there are other designers in your organization but you don’t really cooperate on projects, ask them for feedback, too. Design crits are super useful – hearing from other designers is not much less important than hearing from customers and users.

• Get prepared for a big meeting with stakeholders. After a few initial rounds of feedback with your colleagues and product team members, schedule a call with stakeholders. Record a short loom about what you’re going to present in a couple of days, so they are not totally surprised when you hit the present button. Write a short spec and attach it to the invitation, which will inform them what this is all about and what is expected from them.

A small caveat or a prerequisite, if you will, is needed to make good use of feedback: you must detach yourself emotionally from the work you’re doing.

You are not your work.

The best thing to do is to stop thinking about your work as something precious that you spend so much time and energy on. Otherwise, every little piece of feedback or change request will hurt you to the core, and you’ll cry a river after every meeting with opinionated stakeholders.

Speaking the language of the audience

Imagine this. You walk into a room full of C-level executives, domain experts, and sales reps. You are going to make a big presentation of a new shiny functionality that you have been exploring in the last couple of months. The project is still in the discovery phase, and not a single line of code has yet been pushed. Market has been probed, and you’ve spoken to customers, so you know their needs, and you’re pretty sure that this is the way. The goal is to get a seal of approval and make the audience excited.

❌ What is the worst thing to do during this presentation?

• Talking about the specifics of the user flow and visual attributes of the proposed solution. This would be super exciting for other designers when presented on a design crit kind of meeting, but not when demonstrated to the business people.

• Speaking in design language and using design-specific acronyms that stakeholders won’t understand.

• Neglecting business priorities and failing to connect your solution to KPIs.

✅ Instead, do more of this:

• Explain the identified user need and market opportunity, and connect it to the presented solution. Get them excited by saying that this functionality will improve a specific business metric, such as retention, stickiness, or ARR, by addressing the identified opportunity.

• Use clear language that stakeholders and product experts will understand and care about. Demonstrate how your design impacts business goals, priorities, and KPIs.

• Try to quantify the value of the change that your project is going to make. For example, if it automates a process, calculate beforehand how much money your solution may save the company.

Join the challenge!

Hopefully, the tips I covered in this article will help you grow and make your big presentations less stressful. Bear in mind that it’s not an overnight change. There are lots of components that will click someday and eventually make everything smoother, but in the meantime, starting today, try to learn and implement small improvements.

My friend, Miranda Slayter from has prepared something that will help you make your first step toward the journey of becoming a designer who articulates their decisions like a pro.

Join the challenge

Why Before UI is an 8-week design challenge focused on getting designers ready to go beyond pixels and design for real change. The challenge is free and starts in a couple of weeks.

I will be judging one of the prompts in the seventh week of the challenge – expect an article in November covering my solution for the given prompt!

Support our work

If you enjoy our newsletter, consider switching to the Premium plan to show your support! For just $5 a month (or $45 a year), you will get full access to our archives and free access to ebooks from Fundament Library.

Subscribe now

Follow us on other channels

• Arek’s LinkedIn, Instagram, TikTok, and Twitter (X).

• Mateusz’s LinkedIn

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

We Held a Hackathon for the Music Industry With No Engineers

The following is the recording of my conversation with Mindaugas Petrutis, who is working on growth and marketing at Lovable.

He and the small team of Lovable in Stockholm are doing a fantastic job, as they were recently announced as the fastest growing software startup in the world and secured the $200M series A funding round.

We first met with Mindaugas around a year ago for his previous project called Coho, way before he joined Lovable. How is he doing now? Is work at Lovable exciting? Are they going to compete with Figma at some point? And finally, what does he think of the future of design tools?

Arkadiusz Radek: Congratulations on the recent funding round of $200M!

Mindaugas Petrutis: Yeah, it’s huge, thank you!

It might not be easy for you to imagine this, but I’m pretty sure some people still haven’t heard of Lovable. Could you introduce the company that you work for to our readers?

Lovable makes it easy for anyone to build websites, web apps, games, and whatever you can think of. The imagination is your limitation at this point. You do it by simply chatting with AI in English. Or even your language. I tested it with Lithuanian, and I've also tested it with Japanese and other languages. It works, so you don't even have to speak English.

Some people are making money using our platform. From individuals launching businesses they couldn't before, to companies using it to roll out new products to their existing customer base, and making $3M in 48 hours, as seen in a company in Brazil that achieved this recently.

So we're now officially the fastest-growing company in the world, and we’ve been around on the market for a year..

Who invested in Lovable so far?

The A series funding round of $200M that you mentioned was led by Accel and backed by other VCs such as 20VC, ByFounders, Creandum, Hummingbird Ventures, and Visionaries Club, as well as a bunch of angel investors, such as founders or co-founders of companies like ElevenLabs, Klarna, Slack, Remote, and Hubspot. But not only people from tech invested.

There’s a cool story behind how will.i.am of The Black Eyed Peas became our investor, which we’ll share at some point. All I can say for now is that he experienced the product first and then wanted to become part of the story. It wasn't like, Oh, this is some hype company, let me get in. He tried the product and was so blown away that he wanted to invest.

Lovable targets users of many roles: designers, developers, founders, and even musicians, like will.i.am. How difficult is it to adapt communication to each of those different roles, so the product grows effectively?

I think it’s becoming easier, and it’ll only get easier over time. I always picture my mom as the person I want this product to be built for. Before joining, I was already a super user; I built a lot with it. Now, with what we’re releasing, I can see it getting to a point where even she could use it.

She’s in her mid-60s, doesn’t speak English, but has this incredible eye for vintage clothing. For years, she’s dreamed of running a little digital shop where she could resell her finds. Back in Eastern Europe, secondhand stores are everywhere. She ran one for 20 years, and she still loves hunting. She’ll walk into a shop, pick up a Gucci handbag for $5 because she knows it’s authentic, and then resell it for $500.

She tells me she doesn’t want to deal with apps or complicated platforms—she just wants her own shop, where people can come and buy. That’s the future I’d love to see: where she could simply say what she wants, and the tech handles the rest. No worrying about security, APIs, or AI. She just describes her vision, and it builds itself. We’re getting pretty close to that.

Are you planning to do a Mom Test on your mom with Lovable?

I would love nothing more than to do that in the next few months.

Fingers crossed for her passing it! Let’s talk about Figma, which has recently celebrated a big success as well. Just a few weeks ago, they began trading on the NYSE. When you look at the competitive landscape, do you see Figma as a direct competitor to Lovable?

I have a couple of perspectives on this. When I was at InVision, we were one of the most essential tools for designers, and then Figma showed up. And while it wasn’t the only reason InVision disappeared, it played a huge role. You can’t ignore a company that essentially made a $2B business disappear. Recently, they went public, and from what I saw, they are doing really well.

But here’s the thing: Figma came into the vibe-coding space after us, and competing with them is a different challenge. They have multiple products, multiple business lines. We’re focused on just one thing—and that makes us different.

While Figma is embedded in lots of companies, its user base is mostly designers, PMs, and engineers. Ours is far broader. On Lovable, we’ve seen teachers building businesses, or even someone like will.i.am experimenting with it. That range is huge. And when people see someone they admire, whether a celebrity, influencer, or even just a peer, using Lovable, it suddenly feels accessible. I think it would be quite tricky to have this land the same with anyone outside of tech.

Our language, our focus, is all about enabling people to build something they couldn’t before. For Figma to reach that audience, its whole messaging would need to change.

Are there plans for Lovable to become a direct competitor to Figma in their space and serve as a one-stop shop for designers in the future?

I don’t know if we’re really thinking about it as a “one-stop shop for designers.” What does that even mean, right? What I can say is that design systems are a huge part of building any product or new feature, and making that easier is definitely on our path. It’s also a big requirement for enterprise companies and deals, so that will naturally evolve.

But bigger than that, I think what’s going to change is how we build products overall. I don’t see us saying, “Let’s become the tool just for designers.” Instead, the way products are built will fundamentally shift, and then designers will adapt to that, because that's what historically a new piece of technology tends to do.

Can you tell our readers more about your current role at Lovable?

I’m a part of the Marketing Team, and my role is really interesting. The whole Lovable is a tiny team. We’re making $100M ARR with 60 people. When I was working at InVision back in the day, at our peak to make $100M ARR, we had 800 people on board. My role primarily involves working on creator and influencer collaborations. That could mean partnering with a creator who has 50,000 followers, making sure contracts and payments are handled, or building long-term relationships with major YouTubers. Lately, I’ve also started working with high-profile collaborators and cultural moments.

For example, we just piloted an AI and music hackathon in San Francisco called the Outside LLMs as part of Outside Lands, the largest independent music festival in the U.S. Two weeks before the festival, we brought together artists, musicians, producers, DJs, and talent managers to build their ideas with Lovable. We had an incredible judging panel with MC Hammer, Chris Messina (inventor of the hashtag), and even Chris Kelly (co-owner of the Sacramento Kings). The top teams demoed their projects earlier this week*, and starting today, 200,000 festival attendees can try them out directly in the festival app and vote. Winners will be announced at the end of the festival.

What’s powerful here is accessibility. Traditionally, hackathons like this happened at major events like this, but only coders could really participate. Artists and producers, the people closest to the real problems, were left out. With Lovable, we’ve removed that barrier, and the projects people built blew my mind.

Are you saying you held a hackathon and removed engineers from it?

They were welcome but not required. We focused more on producers or the DJs, people who are in that industry, day in and day out. They see inefficiencies, they see problems, they see opportunities. But then, for the majority of the cases, that's where it stops. What’s next? Do I hire an engineer? What kind? And how to work with them? Can I even afford one? In most cases, no.

What’s the biggest challenge in developing a product such as Lovable from your perspective?

I think, like for any other product, it’s staying close to the customer. I worked with some founders before, and what I immediately noticed about Anton and Fabian is the laser focus. I’ll give you one example. It was my first month in Lovable. We’ve got a Slack channel called #crazy-ideas, and I posted in that channel something that one of our users requested by sending me a direct message. I wasn’t really sure if it was a crazy idea, but Anton responded pretty quickly, saying, “I always wanted to build something like this, but we’re not doing this. Not a priority.” He is a co-founder and could easily tell the team to build this, but he’s well aware of what should be a priority.

Separating yourself from the work is extremely important. I think that’s why Lovable is so successful and loved by users, because the team is building something that resonates with their needs. Can you tell our readers how you ended up at Lovable? I’ve heard it’s an interesting story.

When we met last year, I was working on a product idea I still believe needs to exist. We built an early alpha, and I had a small, unpaid team, but without funding, it was tough to keep momentum. Eventually, my only engineer left, and suddenly I was stuck with a beta I promised, but had no one to build it.

Around that time, I was already deep into AI. I’d been experimenting since before GPT-3 took off, and when new tools like Lovable started emerging, I thought: maybe I can learn enough to become my own engineer. I began building small projects just to test what was possible. Some mornings I’d literally ask ChatGPT for ten random ideas and then build one of them, just to practice.

That led me to create Backchannel: a lightweight product where people could access my career advice without me becoming a coach or doing a full course. I went from an idea on a Sunday night to my first paying customer by Thursday. The next day, I built my own Stripe integration, something that used to take teams of engineers at previous companies I’d worked for. Sitting there, sipping coffee, pushing it live myself—it blew my mind.

Backchannel has since made $7–8k in revenue, and friends who are top engineers even tried to “hack” it, but couldn’t. That was before Lovable added the security features it has today. I realized then just how powerful the platform was. Lovable invited me to a livestream, then featured me on their blog, and I kept building with it.

In the back of my mind, I told myself: if they ever reach out, I’ll drop everything and join. And then it happened. One day, I noticed Lovable folks viewing my profile on LinkedIn. Soon after, Elena Verna (head of growth) DM’d me, we had a great chat, did a workshop together, and then I met Anton. A few days later, they made me an offer, and I joined.

Your background doesn’t resemble that of a typical designer. For long years, you have worked closely with designers, either by recruiting them or running product communities for them. Do you consider yourself one?

I think I’m just good at figuring things out. Honestly, when I joined Lovable, I had a real “what have I done?” moment. I’d never done influencer marketing before, and suddenly, we were one of the most talked-about companies in the world. The scale, the eyeballs, the pressure, it hit me fast.

But then I reminded myself: I know how to break things down. My role is really about relationships, recognizing patterns, understanding context quickly, and operationalizing ideas. I’ve done all of that before. Once I reframed it, I felt calmer. And hearing from industry peers that we’re “killing it” gave me confidence that the work is landing.

Am I a designer? In some ways, yes. My brain has always worked that way. Even back when I worked in hospitality, I was basically doing service design without realizing it and redesigning the flow of a restaurant to remove friction and make things run smoother. Now, I’m PM’ing my own projects, building with AI, and shipping internal tools. So, I guess I’m a bit of a designer, a bit of a PM, and a builder. A combo of all of it.

You are a Swiss Army Knife, Mindaugas! Here’s my last question. How do you see AI shaping the future of product development and design? And specifically for designers, what skills do you think they should focus on today to stay relevant and competitive in tomorrow’s job market?

It’s a good question. I think designers need to detach themselves from the tools and focus more on core skills, things like communication, defining problems clearly, and framing solutions. If your career has been mostly about pushing pixels in Figma, that’s the part of the job that’s going to disappear. And it will disappear fast.

I’ve spoken with many designers who are still deeply attached to a process where they spend days crafting designs and then present them. That way of working is about to get ripped out. My fear is that too many people won’t adapt quickly enough.

There will absolutely be a place for designers, an even more important one, I think, but it won’t look like it does now. You need to anticipate the shift, insert yourself into the new workflows early, and show how you add value there. If you wait until the old way is gone, it might be too late.

*The interview was recorded on Friday, 8 August 2025, the starting day of the Outside Lands Festival.

Mindaugas Petrutis

Mindaugas builds systems that help people find momentum in moments of uncertainty.

For over a decade, he has worked at the intersection of community, product, and career navigation—designing programs, tools, and experiences that enable people to get hired, build confidence, and move forward.

What began with creating trusted communities has evolved into a more hands-on approach. Today, Mindaugas uses AI to develop tools that transform complex, high-stakes problems into working products—fast enough to test, clear enough to act on.

He has built communities for designers and led teams across Europe, the US, and APAC. He has managed multi-program P&Ls and created platforms that thousands of people have used to reset their careers or rethink their next chapter.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Improve your visual skills with Gestalt principles

When it comes to visual design, I am a strong advocate for focusing on timeless concepts, understanding the fundamentals, and building on solid theory that is not influenced by fleeting trends. Of course, knowing current design trends is valuable. However, this knowledge alone does not give you the strong foundation you need to use those trends effectively in your projects and, more importantly, to design with intention and impact. One of these solid foundations is the set of Gestalt principles.

What are Gestalt principles

Gestalt principles are rules that describe how the human brain interprets and organizes visual information. They explain how we naturally group elements, recognize patterns, and form them into coherent wholes, even when they are incomplete or arranged in a seemingly random way.

These principles originated in the German school of psychology in the early twentieth century, based on the work of psychologists such as Max Wertheimer, Wolfgang Köhler, and Kurt Koffka.

Why is it important

In interface design, Gestalt principles are applied to how users perceive the interface and interpret its elements. This is crucial because it affects how the user understands the system and, in turn, its overall usability. These principles are essential for creating visual hierarchy.

They allow us to predict how users will interpret what we design. This helps us capture the user’s attention and support them in interpreting and understanding what they see. It also significantly reduces cognitive load, as users do not have to search for and guess which elements are related and which are not. When applied correctly, these principles enable the brain to automatically group elements and establish their hierarchy.

If these principles are ignored, the human brain will still interpret what it sees, but the interpretation will likely be inaccurate and inconsistent with how the system works, leading to frustration.

Although I refer to Gestalt principles mainly in the context of visual design, it is worth noting that they influence not only aesthetic perception but also user flow, the effectiveness of finding information, and decision-making.

In design, Gestalt principles can be applied in areas such as:

• Page structure and information hierarchy

• Navigation design

• Forms and multi-step processes

• Dashboards and data visualization

Examples of Gestalt principles

Let’s take a look at some of the most important principles and how they are applied in design. There are more of them, but I have chosen the ones I consider most relevant.

Closure

The principle states that the human brain automatically fills in missing elements in what it sees. This allows us to recognize shapes and patterns even when they are partially obscured or incomplete. It also helps reduce cognitive load, as it enables us to design elements in a more minimalist way while maintaining clarity for the user.

In design, this principle is often used in icons. For example, a trash bin icon can be drawn with just a few lines and still be recognized by the user. The same applies to a hamburger icon, where three lines form a coherent object. This principle is also commonly applied in logo design.

Similarity

According to this principle, objects that are similar to each other are perceived as related or belonging to the same category. Similarity can refer to aspects such as color, texture, shape, size, orientation, or typeface.

In design, this principle is applied, among other things, when creating interactive elements. Clickable elements such as buttons should share the same color and shape, allowing users to associate specific visual characteristics with a particular action. The same applies to links of the same color, which are perceived as the same type of interaction, or to icons, where the same trash bin icon always represents deleting, and a left arrow icon indicates going back. This principle is widely used in the design systems.

Proximity

This principle states that objects placed close to each other are perceived as a group, even if they differ in shape or color.

In design, we use this principle to group related functions. An icon and the text of a button should be placed close together so that users perceive them as a single element, and the same applies to a heading and its paragraph. This principle also allows for creating sections and grouping objects, such as in lists, without using additional separating elements.

Continuity

People perceive lines as continuous and naturally follow them, even when they intersect with other elements, because they are seen as more related than elements arranged randomly. This is not always about literal lines, but also about visual paths created by the arrangement of elements.

In design, this principle is applied for example in forms, where fields arranged vertically create a natural flow of the eye from top to bottom. The same applies to navigation menus or breadcrumbs, where we follow the path defined by the elements. It can also be seen in line charts, where we follow a line even when it crosses other lines or the chart grid.

Common Fate

Elements that change in the same way, for example moving in the same direction or manner, are perceived as belonging to the same group.

In design, this principle is often applied in micro animations. Elements animated in the same way create a sense of consistency within the system and a feeling of belonging to the same group. This makes it easier to understand the same behavior in different contexts, such as loading animations, card swiping in a specific direction, or carousels.

Prägnanz

This principle states that people tend to perceive complex or ambiguous images in the simplest possible form. It helps with faster and easier processing of information. The principle of Prägnanz is also known as the principle of simplicity.

In design, we apply this principle by creating simple and clear interfaces. The human brain naturally seeks to minimize cognitive load, which is why structured designs with simple shapes, clear hierarchy, and sufficient spacing are perceived more positively and require less effort. When this principle is not applied, the brain will still try to simplify what it sees, but this increases cognitive load and can lead to misinterpretations.

Following this principle helps users better understand a product and navigate it more easily. A common example can be seen in icons and pictograms, where complex shapes are represented in the simplest possible way so that users can quickly recognize them. The same approach is also used in layouts, charts, and other forms of data visualization, which improves clarity and makes interaction more intuitive.

Figure-Ground

People automatically separate objects in the foreground from the background and focus their attention on them.

In design, we apply this principle by using contrast to clearly distinguish buttons from the background or by designing modals that stand out and capture attention. This ensures that users focus on the relevant elements in a given context. However, it is important to avoid highlighting too many elements at once, as this can make it harder for users to concentrate on the most important object.

Common Region

Elements enclosed within a visual boundary are perceived as a group, separate from elements outside that boundary.

In design, we can group related objects within a visually defined area, such as using a different background color, borders, shadows, or dividers, to show that they are distinct from the rest of the interface. This approach is commonly used on dashboards, lists, modal windows, and dropdown menus.

Symmetry and Order

People prefer organized and symmetrical layouts, which are not only easier to process but are also perceived as connected and forming a cohesive group.

In design, this principle is applied, for example, in grid systems that help maintain visual order. It applies not only to entire page layouts but also to smaller elements such as buttons, cards, and sections.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Changing human behavior with behavioral design

In previous editions of the newsletter, I’ve mentioned several concepts and methods that allow us to influence human behavior. I’ve written about approaches such as The Hooked Model and nudges, as well as cognitive biases. When used thoughtfully, these tools can help change user behavior in a natural and unobtrusive way, making it easier and faster for people to make decisions that help them reach their goals, while also benefiting the organization.

This time, however, I’d like to take a step back and introduce the foundation behind all of these tools. They are all part of a larger concept known as behavioral design.

What is behavioral design

Behavioral design is an approach focused on influencing human behavior. Its effectiveness comes from combining cognitive psychology, behavioral economics, and user experience. Understanding how people think and make decisions enables the creation of products that naturally guide user behavior in a way that supports their own goals.

It is important to note that behavioral design should not be used to manipulate users, but rather to understand why they make certain decisions and how that insight can help support them in reaching their goals and gaining value.

It is also worth mentioning that behavioral design is not a required part of every design process. In many cases, the products we create are simply meant to solve user problems in a straightforward way, without aiming to change their behavior.

Foundations of behavioral design

The foundation of behavioral design lies in understanding how people think and make decisions. It will probably come as no surprise that I’ll start by referring to Daniel Kahneman and his theory, which explains that the human brain operates using two systems:

• System 1 works quickly, automatically, emotionally, and intuitively, while

• System 2 is more logical, deliberate, and slower.

Most everyday decisions we make are driven by System 1, which means we often do not act rationally. We are influenced by context, mental shortcuts, and emotions. Behavioral design operates at this very level.

An essential part of System 1 and behavioral design is the use of heuristics, which are simple mental rules and shortcuts the brain relies on to save energy. These shortcuts can sometimes lead to cognitive biases. By understanding and applying these mechanisms, we are able to anticipate and shape user behavior.

You can learn more about cognitive biases in this article:

However, heuristics and biases are not the only mechanisms involved in behavioral design. We can also influence human behavior using approaches such as the Hook Model, the Fogg Behavior Model, or nudges, all of which are also based on how cognitive biases shape our decisions.

You can read more about nudges and the Hook Model in these articles:

In the context of behavioral design, there is also a focus on shaping the environment in which users make decisions. This includes the situational context, such as time, place, device, or emotional state, as well as microinteractions and micro-decisions, like quickly choosing between two available options. This shows that behavioral design does not always involve large changes. Sometimes, small interface elements can have a meaningful impact on user behavior.

It is also important to highlight that behavioral design is grounded in behavioral economics, which examines how psychological, emotional, cultural, social, and cognitive factors influence economic decision-making.

Finally, behavioral design does not work the same way for everyone. Its effectiveness can depend on individual user traits, cultural context, and level of awareness. This is why it is essential to test and iterate on design solutions to make sure they are effective in a specific context.

Why is it worth your attention?

Behavioral design is extremely important from a UX design perspective. It not only provides us with tools for influencing human behavior but, more importantly, helps us understand what people do and why. This understanding allows us to support users in making faster and more effective decisions that are beneficial to them, which in turn improves their overall experience with our product or service. When applied well, behavioral design can turn a user's intention into action. Most of us probably want to save money or be more physically active, and behavioral design makes those choices easier and sometimes even strongly encourages action.

Users are often overwhelmed with information, unsure about which decisions to make, and tend to postpone them. Behavioral design helps create environments that support decision-making and goal achievement by reducing cognitive load and simplifying choices.

It also allows us to better understand our users and focus on their actual behavior, not just what they say they will do. It shows us that users do not read everything carefully, they procrastinate, and they often act impulsively and emotionally. This can lead to decisions and behaviors that are not in their best interest. As designers, we have the opportunity to influence whether the decisions users make will truly benefit them.

It is important to emphasize once again that behavioral design is not about creating dark patterns. It is about supporting users in making choices that are primarily beneficial for them and helping them reach their goals.

These kinds of design choices directly improve the user experience, which naturally brings positive outcomes both for the user and for the organization. Users are able to reach their goals more easily and efficiently, while organizations benefit from more effective products, increased conversion rates, and higher engagement.

Implementation

To successfully apply behavioral design in practice, the most important thing is to understand your users. What are their problems and goals, and if it’s an existing product, why are they not taking action? Qualitative research methods such as interviews and usability testing can be particularly effective here.

Next, it’s important to define the goals and behaviors you want to encourage. You need to be clear about what action you want the user to take and why it will be beneficial for them. It's also helpful to analyze the user journey and identify the moments when a decision is required. Tools like a user journey map or empathy map can be useful in this process.

Once you have this information, you can move on to selecting the most suitable tools for the specific situation. As mentioned earlier, this could include The Hook Model, nudges, the Fogg Behavior Model, EAST, or MINDSPACE, as well as leveraging cognitive biases, which are also the foundation of many of these methods. Sometimes, small interaction changes, such as adjusting the style or copy of a button, can effectively influence behavior.

Finally, make sure to test, iterate, and optimize. You need to confirm that your solution works as expected and refine it based on user feedback and research insights.

Ethics in behavioral design

Ethics in the context of behavioral design and the tools that support it is a topic I always bring up. This time is no different.

Behavioral design can be used to gently and naturally influence user decisions, but it can also be used to manipulate them for the sake of maximizing organizational benefit. That is why it is essential to ask yourself which of these two outcomes your design supports. Behavioral design is definitely not meant for creating dark patterns.

Always make sure you are not misleading the user, and ensure that they feel they are in control at all times.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

Objective and Key Results: 101

When I think of my first encounter with the OKR framework, I have a vivid memory of a company where I worked in the early stages of my career, which had no understanding of setting these objectives in a meaningful way. As you may suspect, I have hated OKRs for a very long time. I switched sides a couple of years ago when I witnessed how they can be established in a way that they mean something, they are bonded with metrics that are worth tracking, and at the end of the day, they are quite helpful in telling if you and your product team are doing good work and heading in the right direction.

In this article, I’m providing a brief overview of the OKRs theory, but I’m primarily focusing on examples of how OKRs can be implemented in a meaningful way in your organization and your projects.

What are OKRs, and why do they sometimes fail

OKRs (Objectives and Key Results) is a popular goal-setting framework used by individuals, teams, and organizations to define objectives and track their progress and outcomes. According to Wikipedia, the framework was popularized by Andrew Grove of Intel in the 1970s, who later documented this method in his 1983 book, “High Output Management.”

How does an OKR really look? It’s a two-part statement. There’s an overarching objective that should be ambitious and feel uncomfortable. Key results should be measurable and drive the completion of the objective. An example of an OKR could look like this one below:

Objective:

Improve the self-serve onboarding in our product.

Key Results:

• Increase activation rate by 10%.

• 30% of our users sign up and activate through the mobile app.

• The flow in activation is shorter, from 12 to 9 steps.

Objective Key Results is a relatively old framework. However, many organizations still struggle to put it to the right use. There are a myriad of reasons why OKRs fail, but the most popular and quite easy to address are:

• Lack of clarity and alignment. This happens when the team’s and individual contributors’ goals are not aligned with the overarching organization’s goals, e.g., the product team is focused on building features, driving improvements in the user experience of the admin area of the product, while other teams target customer growth, aligning with the overarching financial OKR of the entire organization.

• Setting vague or unrealistic objectives. Goals that are either not clearly defined or too ambitious (they should be ambitious and reachable in at least 60-70%, though) can cause confusion and demotivation. Just imagine setting a moonshot financial OKR to quadruple last year’s revenue in an unstable economic period – organizations doubling their YOY revenue are performing incredibly well.

• Overemphasis on metrics and depraved incentives. When organizations are too focused on vanity metrics, teams and individuals may go to the dark side and try to game the system. In 2016, Wells Fargo, an American bank, caused a nationwide scandal by creating millions of fraudulent savings and checking accounts on behalf of their customers without their knowledge, in an attempt to hit aggressive sales goals set by management.

The first two were definitely the case for the aforementioned organization that I worked for some time ago, and which turned off OKRs for me for a very long time. Let’s now explore the ingredients for inspirational OKRs that product teams and ICs want to achieve.

A recipe for meaningful and inspirational OKRs

OKRs that are inspirational and which product teams and ICs enjoy achieving share a few non-negotiable ingredients:

• Strategic alignment. Make sure your team’s objectives are aligned with the overarching goals of the organization, as well as their vision and mission.

• Limited scope. A rule of thumb is to focus on 3-5 objectives, each having around three key results.

• Aspirational and actionable objective. Write objectives as short, inspirational statements that give purpose and direction. Use clear and action-oriented language that conveys endpoints, e.g., “ship feature X”, “improve product’s reputation”, “increase the use of the product.”

• Measurable key results. Craft key results as specific, quantitative outcomes that, when achieved, will directly advance the objective. KRs should describe outcomes, not activities. If you are planning an activity that will influence the objective, describe the impact the activity will have.

• Put in a time frame. Make OKRs time-bound, usually quarterly or annually. This will help focus efforts and allow for regular reviews.

Alright, enough of theory. Let’s now focus on how you and your team can implement OKRs in your organization and make good use of them.

OKRs in practice

Let’s use a fictional organization as a background story for our OKRs:

Acme Inc. works for a relatively small volume of B2B customers. The main product of this young startup based in Europe is monitoring how brands are positioned in popular LLMs.

The management team sets an annual financial goal that the entire organization contributes to. Growing revenue to a certain value helps the company continuously improve its products and services. The company has set its mission and follows a specific list of values. As any serious CEO would do, the big boss sat down with the board of directors once, and they designed a five-year vision for the entire organization.

Acme Inc. has a few small product teams onboard responsible for various parts of the system. The entire company does quarterly planning for all product teams four times a year.

The goal of this exercise is to align the objectives with the strategic annual goals and the long-term vision. A couple of other factors, such as the voice of the customers and UX metrics, influence what the team will be focusing on in the next three months.

Let’s take one of the teams as an example and give it a more detailed look:

This is the Data Visualization Team, whose main job is to ensure customers can easily access and consume the insights they need.

As the second quarter of the year comes to a close and Q3 planning approaches, the team is preparing a list of key problems to tackle over the next three months. While doing that, the team’s Product Trio is considering both long-term vision and the customer feedback they have collected in the past few weeks. Two main themes emerge from the long list of problems:

1. Our customers face challenges in navigating complex data to uncover key insights about their positioning in LLMs.

2. Our customers get too many notifications from the system.

After discussing the short list of problems with the board of directors, the Product Trio is certain that this is the set of the right things to lean on in the next quarter. The next step is to ideate how the team might want to tackle these two problems, but they already know how to do it from this article.

Fundament – Product Design Newsletter

Ideate like a pro. Brainstorming and Offline Ideation Week

Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community…

Read more

a year ago · 5 likes · 1 comment · Arkadiusz Radek

Before the Q3 starts, the team has a quite clear idea of what they are after. What’s left to be done before jumping into actual design and development is to set Objectives and Key Results, which will help the team follow the right path and measure if it was actually good. Also, the team will report their OKRs to management a couple of times during the quarter to reassure them that the operation is (hopefully) going smoothly.

Since the team will focus on two initiatives to address two problems, they require only two OKRs. Here’s what the team came up with:

Objective 1:

Improve the way our customers find the key insights in our product.

Key Results:

• Time to insight improved by 25%.

• Error rate for finding insights on the dashboard reduced by 20%.

• 25% of the customers use new AI-based search functionality.

The team is about to build an AI-based search functionality that, as the team supposes, will unlock new ways of interacting with large data sets and enable quicker time to insight, which is a specific metric tracked by the organization. Additionally, the team plans to run a usability study while developing the new functionality to determine if the error rate metric drops after making a few changes to the dashboard.

Objective 2:

Customers receive relevant notifications.

Key Results:

• 20% of our customers adopt notification settings.

• Customer satisfaction increases by 10%.

• 100% of our customers receive smart notifications.

To tackle the second problem, the team will build a set of two functionalities: smart notifications and notification settings. Up to this day, customers have been unhappy with the number and relevance of notifications they receive from the system regarding their positioning in LLMs. That’s why the team decided to develop a piece of software that will determine if a notification was seen in the system and send an email with a delay to avoid knocking on the customer’s door twice. The second part of the solution would be the notification settings module that will let the customers customize which types of notifications and how frequently they want to receive.

What’s the main takeaway from this example?

The OKRs must align with what the team is about to build within a given time frame. Everything has to happen in a very specific order, where writing down OKRs is usually the last step of the planning process. Otherwise, the objectives may become disconnected from the product team's actual work, lose their meaning, and be challenging to hit.

An important announcement

Earlier this year, we switched from bi-weekly to weekly mode. For the first couple of months, it worked really well, and we believe we managed to deliver quality and thoughtful content.

However, it recently became a burden.

There’s a ton of good content online, and it’s impossible to consume it all. To avoid overwhelming our readers and maintain the highest standard of our articles, we decided to switch back to a bi-weekly mode starting August 2025.

At the same time, we are lowering the price of our Premium plan to $5 a month and $45 a year (3 months off). Consider subscribing to Premium to get full access to our archive, ebooks, and additional educational content.

Subscribe now

No matter how counterintuitive it may sound, we hope you’ll enjoy seeing our articles less often in your inbox!

Episode 62 will be released on August 14.

Best,
Arek and Mateusz

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

An important announcement

Before you dive deep into this week’s episode, here’s an important announcement on the future of Fundament we’d like you to read.

Earlier this year, we switched from bi-weekly to weekly mode. For the first couple of months it worked really well, and we believe we managed to deliver quality and thoughtful content.

However, it recently became a burden.

There’s a ton of good content online, and it’s impossible to consume it all. To avoid overwhelming our readers and maintain the highest standard of our articles, we decided to switch back to a bi-weekly mode starting August 2025.

At the same time, we are lowering the price of our Premium plan to $5 a month and $45 a year (3 months off). Consider subscribing to Premium to get full access to our archive, ebooks, and additional educational content.

No matter how counterintuitive it may sound, we hope you’ll enjoy seeing our articles less often in your inbox!

P.S.: We recently hit 2,000 subscribers!

Best,
Arek and Mateusz

You don't need to manipulate to influence users’ decisions

As designers, we have many ways to influence user behavior and decision-making. One example is the Hooked Model, which I wrote about some time ago. Methods like this can be used for good purposes, such as improving the user experience, helping users make decisions more easily, or speeding up a process. But they can also be used in more harmful ways, manipulating users to maximize benefits for the organization.

In this article, I’d like to focus on the first, more ethical goal and introduce you to a method that, while it influences user decisions, still respects their freedom of choice. It is based on the idea that any influence should always come with a benefit for the user. I'm talking about subtle nudges that support decision-making.

What are nudges?

Nudges are subtle prompts or suggestions in an interface, grounded in behavioral economics. Subtlety is the key word here, because unlike manipulative dark patterns, nudges influence user decisions in a non-intrusive way that does not exclude other options. They serve more as a form of support, increasing the likelihood of guiding user behavior through encouragement rather than pressure.

The term was introduced by Richard Thaler and Cass Sunstein, who described Nudge Theory in their book Nudge: Improving Decisions About Health, Wealth, and Happiness.

Benefits of nudges

Well-designed nudges have a positive impact on the user experience. Implementing them in a product helps users make decisions more easily, especially when they feel uncertain, which shortens the time needed to take action. They also help reduce cognitive load and increase the sense of control, making users feel that they are making informed and meaningful choices.

This also benefits the organization, as it leads to higher conversion rates, greater engagement, and improved user retention. In addition, satisfied users are less likely to contact support, which helps reduce operational costs. As a result, both users and the organization benefit from improved usability and overall satisfaction.

How does it work?

As mentioned earlier, nudges are based on behavioral economics. This field assumes that people often do not make fully rational decisions, and their choices are strongly shaped by context and subtle cues that can gently influence their behavior.

Nudges are processed through what Daniel Kahneman described as System 1 in the brain. This system is responsible for fast, intuitive, and automatic thinking that dominates everyday decision-making. Nudges work by leveraging natural patterns of human thought and cognitive biases that the brain uses to simplify decisions, while still offering users complete freedom of choice. These include, among others, default bias, social proof bias, anchoring bias, loss aversion, and framing bias, as well as heuristics like availability and representativeness.

You can learn more about cognitive biases in this article:

In addition, nudges rely on choice architecture, which refers to the structure in which users make decisions. As designers, we have a strong influence on this structure, sometimes even without realizing it. The way options are presented, default settings, the order of information, and the language used all shape the decisions users make.

Examples of nudges

Let’s take a look at the moments in a user journey where nudges can be particularly helpful. In fact, nudges can be applied in almost any situation where a user has to make a decision. To make this easier to understand, I’ve selected a few of the most common examples:

Choosing a subscription

When selecting a subscription plan, a nudge might include highlighting one of the plans as the most popular or offering the best value for money. It could also involve showing how much the user can save by choosing an annual payment or preselecting the plan that offers the best benefits.

Choosing a course

In the case of online courses, a nudge could be a message showing how many users recommend the course or that it’s a perfect match for your level. In learning platforms or fitness-related apps, nudges might include gamification elements that encourage users to stay active and keep making progress, whether in a course or a workout.

Selecting a product or product options in online stores

Similarly, when choosing a product in an online store, nudges can include things like social proof, such as user recommendations or showing how many units have already been purchased.

Choosing a bank account or financial services

In financial products, default options can be a powerful nudge. For example, a basic account or savings-related features might be selected automatically. Nudges can also involve visualizing how much money a user could save by choosing a particular plan, or showing progress toward a savings goal to encourage further contributions.

Selecting flight options

In the context of travel or flights, nudges might include preselected travel insurance, limited seat availability messages, or suggestions for additional services that others commonly choose.

Forms and configurators

Forms and product configurators also benefit from nudges, especially when using smart defaults that simplify the process. This might include setting a default country or language, or automatically selecting the most common options based on user data. Other helpful elements include clearly separated sections and progress bars that guide users through more complex forms.

What types of nudges can we use?

Let’s now look more broadly at the types of nudges that can be applied in user interfaces. Here are a few examples:

• Microcopy that encourages users to choose a digital option over a paper one, or informs them that most people take a certain action or make a particular choice

• Default selections in forms

• Visual highlighting of suggested options, such as colored borders or larger sizing

• Showing which products are most often chosen by other users

• Breaking down complex processes into smaller, easier steps

• Product recommendations

• Emphasizing primary buttons

• Personalization that helps users make decisions by tailoring content to their preferences

Strategies for successful nudge implementation

You probably will not be surprised to hear that effective implementation starts with understanding the context and goals of both the user and the organization. As an organization, we need to know what we want to achieve by adding nudges, whether it is simplifying a process, increasing conversions, or encouraging users to change their behavior. It is important that the goal also aligns with the user’s interests, such as promoting more physical activity. We also need to understand what decisions the user must make, at what point, and whether they might have any doubts, as well as the conditions under which they make these decisions, for exampl,e if they are stressed or tired.

Once we know what we want to achieve, we choose the appropriate type of nudge. This could be manipulating default settings, using social proof, changing the framing, or reorganizing the visual hierarchy. Each of these nudges relies on different psychological mechanisms that help us reach the intended goal. Commonly used methods include the Behaviour Change Technique Taxonomy and the NUDGES framework. These tools help us select the right psychological mechanism and adapt it to existing patterns, maintaining system consistency.

After selecting the appropriate mechanisms, we should apply them in a way that is subtle and unobtrusive. Despite the suggestion, users should still have the freedom to choose, not feel pressured, and not be manipulated for the organization’s benefit. Nudges are meant to improve users’ decisions, not deceive them. Users should always benefit from the use of nudges.

Finally, we need to test whether our solution achieves the intended goals and iterate if the results are not what we expected.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

From Intern to Senior. Part 2: Design process, project scope, tooling, and 1-on-1 meetings at different career stages

In this two-part article, I’m looking at designers’ career levels from unusual angles. I’m covering some real differences between the levels that aren’t captured by most career ladders. To give this comparison a bit of structure, I split my thoughts into seven main areas.

Two weeks ago, in part 1, I covered the first three areas:

• 🎯 Strategic thinking

• 🤝 Engagements

• 📃 Definition of design

Fundament – Product Design Newsletter

From Intern to Senior. Part 1: Strategic thinking, engagements, and definition of design at different career stages

Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community. Join 1,900+ readers and grow as a UX and product designer with us…

Read more

10 months ago · 6 likes · Arkadiusz Radek

Today, in part 2, I’m covering the remaining four areas:

• 👨‍🎨 Design process

• 🗺️ Scope and ambiguity of projects

• 🛠️ Tooling

• 👩‍💻 1-on-1 meetings

Let’s delve into each in more detail.

👨‍🎨 Design process

“What does your design process look like?” This kind of question is often asked during job interviews for design roles. Depending on the seniority of the role and the interviewee's experience, the answer will vary. Less experienced designers tend to follow the process they were taught in design university courses or boot camps quite strictly. More experienced designers tried it out and already know it’s not that simple.

1️⃣ Intern

As an intern product designer, you were taught that the first thing to do is to learn about the user's pain points as much as possible. You identify user personas, map out their feelings and thoughts on an empathy map, and begin to think about potential solutions. You write down some user stories, create an MVP, design a beautiful prototype, and prepare a scenario for a task-based usability study to validate the viability and usability of your solution.

Looking great on paper, but there’s a catch that you’ll learn it (hopefully not) the hard way quite soon.

2️⃣ Junior

As a junior product designer, you are beginning to understand that every project you are assigned is a bit different, and sometimes there’s no need to include every single step from the ideal design process you were taught back in the day. Because you are not experienced yet, and your level of working independently is still relatively low, the projects you are working on aren’t necessarily complex, and a lot of decisions must be consulted with your senior buddy.

Also, you often jump too quickly into the solutions space, not spending enough time on trying to understand the underlying issues, customer needs, and users’ pain points.

3️⃣ Mid-level

As a mid-level product designer, you are feeling more and more comfortable working alone on projects with higher complexity. You already know that a design process needs to be quite flexible and adapted individually to each project. You are better and better at juggling research, writing, cross-functional collaboration, and pushing pixels in multiple projects at once.

You spend less and less time on the solutions side of things, making a variety of exercises to understand the problem first.

4️⃣ Senior

As a senior product designer, you juggle multiple projects without much of a hassle. You are more than aware that an ideal design process looks great on paper, but in real life, it doesn’t make much sense. Was it invented only to teach new designers? Maybe. If yes, something’s wrong with it, and it’s a pity no one is telling them that once they get hired, the design process will look very different. But you have already passed that and made your realization that the more time you spend on understanding the problem, the higher the chance of closing the project successfully.

So, you wear the detective’s hat quite often, chasing stakeholders, users, customers, engineers, and customer success reps to gain the big picture and do your job well. Then, or in the meantime, you write about the problem, trying to break it down and distill its core. You invite non-designers to work with you on ideation. After that, you use your favorite design or vibe coding tool to create a prototype that you’ll later validate with your customers and users. The handoff is invisible, but you already know that from this article.

🗺️ Scope and ambiguity of projects

I covered some elements of this area in one of my previous articles, which was primarily focused on why years of experience don’t matter much when it comes to decisions about promotion.

The project’s scope and level of ambiguity are highly correlated with the designer’s experience and their level of independence. Less experienced designers are more likely to be assigned projects with a small scope and a low level of ambiguity, as they are not yet ready to make important decisions independently, haven’t worked on similar projects long enough, and are still in the process of learning how to ask the right questions.

1️⃣ Intern

As an intern product designer, you are assigned to projects with a low level of ambiguity and a relatively small scope. The reason for that is quite simple. These are your baby steps in the role, and you are still learning the craft. You don’t know where to look for the answers, nor how to ask good questions to find them. As a result, you need quite heavy guidance from more senior colleagues to complete your tasks.

2️⃣ Junior

As a junior product designer, you are now taking more confident steps, but you are still like a toddler. Both scope and ambiguity are more or less the same as on the previous level. Perhaps the scope is a bit larger in terms of size, but in terms of requirements coming from your product manager, they are quite clear, and there isn’t much that needs to be discovered. However, you may start assisting your PM and more senior colleagues with some product discovery activities.

3️⃣ Mid-level

As a mid-level designer, you are beginning to operate more independently and make important calls without much guidance. The projects you are being assigned to are more and more complex and unclear. You need to incorporate a significant amount of research and discovery exercises to find answers to close projects, which are, at the same time, much bigger in scope and last much longer.

4️⃣ Senior

As a senior product designer, you feel quite comfortable in making important design decisions. You work on highly ambiguous projects with a large scope. It wouldn’t be surprising if you were overseeing a very large area of a product, an entire product, or even multiple small products.

Chasing stakeholders and other members of your organization for the answers is your bread and butter. You quite often wear a hat of a detective, and you are quite good at connecting the dots. Sometimes what you’ve got to work with are just shreds of information, but you are experienced enough and have high agency to make good use of them.

You are a strategic partner to your product manager and tech lead, and together, you drive product discovery. Some would say that you are one level higher in looking for answers, as the projects you might be working on haven’t even been discovered. That’s you and the remaining two folks from your product trio to identify those opportunities.

🛠️ Tooling

For the past couple of years, I’ve been observing a concerning trend among designers who are overly focused on tooling. I’m not alone here. Artiom Dashinsky, a designer and book author, coined the term “Figmaism,” which refers to the discussion in our industry that is too heavily focused on tools and the visual aspects of design, resulting in a shallow understanding of the impact our role can have.

Around a year ago, during an interview, I asked Miranda Slayter from , what her take is on this trend. She quite accurately pointed out that the less experienced a designer is, the more obsessed they tend to be with tools and the visual aspect of their work.

While tools are essential for our work, they are not everlasting. What’s evergreen? Our skills such as problem-solving, facilitation, empathy, and creating something meaningful from essentially nothing.

1️⃣ Intern

As an intern product designer, you spend around 90-95% of your time in Figma. It’s not really your tool of choice, but a standard app that dominated the market in recent years. Has your interest in product design started with Figma? There’s a high chance that it was the case. The remaining 5-10% of your time is spent in a document editor, where you try to break down the problems before jumping into solutions, which most likely is something you’re still learning.

2️⃣ Junior

As a junior product designer, you are still heavily focused on the visual side of things, and as a result, you love Figma and try to master its every workflow, plugin, and creative trick. 80% of your time in this tool would be an accurate guess. Everything else is split between a document editor of your choice and various research and analytics tools, such as Hotjar, Amplitude, and Dovetail.

3️⃣ Mid-level

As a mid-level product designer, you are starting to realize that visuals are not everything in this job, so you cut your time in the design tools, such as Figma. My guess would be that you spend around 50% of your time there. The remaining half involves talking, writing, mapping, and performing other activities to understand the needs of customers, businesses, and users’ pain points. You are increasingly using analytics tools.

Additionally, you are starting to become interested in tomorrow's design tools, such as Lovable, v0, and Replit (which many refer to as "vibe coding" apps), and trying to figure out how to incorporate them into your workflow.

4️⃣ Senior

As a senior product designer, you spend maybe a quarter of your time in design tools. There’s a big shift in this department compared to your time as an intern or a junior. You no longer explore the visual side of things this much, as you know, there are many more important aspects of user experience beyond the user interface.

You may have already tested some vibe coding tools and incorporated them into your ideation and prototyping phases of the design process.

The majority of your time is spent in three categories of tools: whiteboarding (FigJam, Miro, Lucid) as you facilitate workshops, document editors (Google Docs, Microsoft Word, NotebookLM), as you constantly wear a detective’s hat conducting numerous interviews, and presentation editors (PowerPoint, Google Docs, Figma Slides) for creating slide decks that help you communicate your big ideas with stakeholders and the commercial team.

👩‍💻 1-on-1 meetings

Regularly meeting with your line manager is vital for both of you. For them, it’s necessary to gauge whether you are making progress in both your tasks and your career in general. They also need these meetings to discuss potential issues and offer you their help in fixing them. For you, as a designer, the needs and topics to be discussed during these meetings will vary depending on where you are in your career ladder. I made this observation in recent years while leading several interns and junior designers in various companies. How different these meetings could be? Let’s find out.

1️⃣ Intern

As an intern product designer, almost a hundred percent of the time you spend on meetings with your manager is focused on your tasks, which influences your growth. Of course, somehow, you are building a relationship with them, discussing non-work-related topics to maintain a healthy level, but because you are relatively inexperienced, you need a ton of feedback and direction on your work.

2️⃣ Junior

As a junior product designer, your main need remains the same as it was a while ago: you need feedback and direction on your work, so for the majority of time, you’ll be presenting your day-to-day projects and asking if that’s done the right way.

After your first promotion, you are hungry for more, so you’re starting to get interested in the mid-level role. How’s it different from your current role? What do I need to learn and achieve to get there soon? Your line manager may set specific goals for you that will guide you toward getting the promotion. As a result, a portion of your 1-on-1 meetings may be used to discuss these goals and check their progress.

3️⃣ Mid-level

As a mid-level product designer, you’re becoming increasingly independent, which has an impact on your 1-on-1 meetings with your line manager. You don’t discuss your current work in such fine detail as you used to do. Strategic thinking is something that pops up more and more frequently on your plate, so you’re most likely discussing what your team will be up to not next week, but next quarter.

You are starting to collaborate with people from different teams and departments more heavily to do your job, so you’ll seek advice on how to make connections with non-designers, engage with stakeholders, and talk to folks from the commercial team so they understand you (spoiler alert: they don’t care about your design system, tokens, or the double diamond process). You most likely have some quarterly goals set up that you’re trying to achieve to continue your growth.

4️⃣ Senior

As a senior product designer, you are more strategy-oriented than ever. There’s a minimal chance that you need to spend your half-hour slot with your manager to walk them through your day-to-day projects (if that’s the case, something’s wrong, it’s called micro-management, and it’s either your line manager or your entire organization). You'd rather juggle two major themes in your 1-on-1 meetings: strategic outlook and leadership.

If you are a senior designer willing to grow even further, there are two paths ahead of you: IC and managerial. Both require leadership skills in some way. You may not have any direct reports if you stick to the IC path, but you’ll be leading by example and overseeing the use of good practices. You are likely spending a significant portion of your time with your manager preparing for any of these roles.

Additionally, if you already lead a group of designers without holding the right title yet, which is quite common in this industry, you report on their progress and the strategic initiatives of the group.

The other part of the time, you use to talk strategy. What’s the focus of your product team (or multiple product teams if you oversee many products) in the next quarter in fine detail, and what else is being considered to be discovered and developed in the 6-12 months outlook? Your manager should be there to help you find resources and connections to hit the strategic goals.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

You probably just took on some UX debt

You’ve most likely come across the term technical debt at some point in your career. It usually arises when temporary solutions are implemented and shortcuts are taken. Technical debt means that even though we deliver a solution faster and cheaper now, in the long run, it becomes more expensive for the organization. That’s because the code delivered by developers eventually needs to be refactored. It has to be improved, optimized, or in many cases rewritten entirely from scratch.

Even though the term technical debt is widely used and many people have heard of it, I feel like UX debt is something we don’t talk about much, even though it’s not much less common. As designers, we work with many constraints. Deadlines are tight, and budgets are limited. Because of those constraints, we make all sorts of decisions every day which, not always but to varying degrees, can contribute to UX debt. As a designer, you should understand what it is, how it emerges, and what kind of impact it has on the business and the organization.

Let’s take a closer look.

What is UX debt?

UX debt refers to the accumulated neglect, compromises, and imperfections that negatively affect the user experience. These issues may arise either consciously or unconsciously during the design process. Just like technical debt, UX debt will eventually need to be "repaid" in order to improve the experience, which comes with additional costs such as time and team resources.

Where does it come from?

There are many different factors that can lead to the creation of UX debt. They can appear in isolation or combine over time, causing the debt to grow.

The most obvious contributors are tight deadlines and/or a lack of sufficient resources. These constraints often prevent teams from delivering the right solution the first time, forcing them to make compromises along the way.

Another common cause is the absence of user research and a lack of understanding of users’ needs and problems. This often goes hand in hand with ignoring or completely skipping user feedback. Usability testing is frequently overlooked as well. Simply put, not caring enough about users is one of the easiest ways to accumulate UX debt.

A further contributor is the lack of understanding of the UX designer's role within the organization, along with the low priority placed on their work. Designers are often not given enough time or resources to conduct research, fix known pain points, or test solutions before release (tasks that may also involve QA teams). When the designer’s role is poorly understood, there is often no expectation that they will take on these responsibilities. Instead, the only deliverable expected from them is a set of screens in Figma. In some cases, designers are not included in the product development team at all, which significantly increases the likelihood of accumulating debt.

Design work itself can also contribute to UX debt. This usually happens when designers ignore established standards and proven design patterns, or when there is a lack of consistency and no clear design system in place. Even if a design system exists, it might be neglected. On top of that, poor or missing design documentation can further complicate development and quality assurance efforts.

Finally, a lack of communication between teams and the absence of a shared product vision can lead to even more debt. When teams do not collaborate, align on goals, or communicate effectively, inconsistencies and gaps begin to form. UX debt is not created by designers alone. It is the result of how the entire product team works together. If collaboration breaks down, the debt will likely grow regardless of the designers’ intentions.

Conscious vs. unconscious debt

As I mentioned earlier, UX debt can arise either consciously or unconsciously during the design process.

Conscious debt occurs when the team is aware that the decisions they make lead to UX debt and accepts the consequences. It is usually the result of constraints beyond our control, such as tight deadlines or insufficient resources to design a better solution at a given moment. This kind of debt is not always bad, as long as its “repayment” is properly planned.

Unconscious debt appears when we are not aware that the quality of the user experience is deteriorating. It often stems from not using proven patterns, ignoring product feedback, skipping user research, or delivering solutions without understanding the real needs of users.

What are the effects of ux debt?

UX debt has negative consequences for both users and the business or organization. Let’s take a closer look at how it affects each of these areas.

Poor user experience and loss of value

Accumulating and neglecting UX debt leads, quite simply, to a worsening user experience. As a result of the decisions (or lack of them) mentioned earlier, the product gradually becomes less appealing to users. Increasing inconsistency, navigation issues, unclear messages, missing features, unnecessary additions, and a more complex interface all contribute to a growing frustration. Eventually, users stop seeing value in the product, and using it becomes so difficult that they feel discouraged and start looking for simpler alternatives.

One important factor worth highlighting is the rushed release of new features, e.g, under time pressure. These additions are frequently inconsistent with the rest of the system and misaligned with user expectations. This contributes to UX debt and frustrates existing users who are repeatedly forced to learn how to use new parts of the product from scratch.

This also affects new users. UX debt makes learning and onboarding harder. The product may feel confusing and difficult to use, which leads to abandonment. This is particularly critical in contexts like e-commerce, where UX debt can increase bounce rates during registration, product search, or checkout, resulting in more abandoned shopping carts.

Impact on the business and product teams

On the organizational side, UX debt has a direct effect. Even when a team is aware of the debt and has consciously taken it on, the time for repayment eventually comes. In most cases, repaying UX debt comes with high interest. Temporary solutions will, sooner or later, need to be replaced with proper ones, and refactoring usually costs significantly more time and resources than implementing the right solution from the start. The larger the UX debt, the harder it becomes to develop the product further. Existing problems either make it difficult to introduce new features or completely block them, as fixing foundational issues becomes the top priority.

The negative effects on users directly translate to business impact. When users struggle with the product, customer support and service costs go up. If they abandon the product or fail to engage with it at all, this leads to a decline in key business metrics.

It also affects product teams, who are forced to deliver and maintain solutions that are flawed from both a design and implementation perspective. These solutions are often more difficult to maintain, and teams end up spending time fixing problems and addressing UX debt instead of working on new, valuable features. Over time, this can lower engagement and reduce the quality of work, as teams become increasingly demotivated.

Can it be avoided?

In a perfect world, yes, it would be possible to develop products without UX debt. Unfortunately, we do not build products in a perfect world, and avoiding UX debt is simply not possible. This is because we cannot avoid the situations that lead to it. There will almost always be constraints such as time, resources, or budget that influence our decisions and result in the creation of debt. In addition, user needs are constantly evolving, and it is rare that we are able to keep up with them at the right pace.

It is important, however, to approach UX debt as consciously as possible and know how to manage it effectively.

How to manage and minimize it

Since UX debt cannot be avoided, it is important to know how to manage it in order to minimize its negative impact. Because of the consequences it brings, addressing it as early as possible is essential and should not be postponed.

To manage UX debt effectively, we first need to understand its scope. This means monitoring and documenting how the debt is created. We need to know where the debt exists and why it was introduced. If past decisions were not documented, an audit may be necessary to assess the current state of the debt. In cases where the debt was taken on intentionally, for example, to deliver a new feature quickly, it is important for the team to plan when and how the debt will be repaid. A good practice is maintaining a separate backlog for UX debt-related tasks.

Regular user research helps minimize the creation of UX debt by allowing teams to better understand evolving needs. Usability testing also plays a key role in reducing the risk of releasing solutions that are unclear or not valuable to users.

It is also crucial for the UX designer to be involved as early as possible in the project, for example, through the product trio approach. This helps reduce the number of poor decisions that could increase the debt. In many organizations with low UX maturity, this is still a major issue that negatively affects user experience and contributes to growing debt.

It is worth planning regular debt repayment, for instance, by including related tasks in everyday work. These do not have to be large efforts that consume most of the team's time. When resources are limited, repaying UX debt can start with small, incremental steps. Tasks should also be properly prioritized, since not everything that needs improvement will have the same level of importance.

During day-to-day work, having a design system and using proven design patterns can be very helpful. It saves time and reduces the number of decisions that need to be made, which helps prevent new debt from forming.

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡

Subscribe now

From Intern to Senior. Part 1: Strategic thinking, engagements, and definition of design at different career stages

Mature organizations use career ladders to assess whether an employee is exceeding their job expectations and ready for promotion. These ladders typically encompass several areas of skills and provide a precise indication of whether someone is close to being promoted or if they should focus on improving in certain areas.

Last year in episode 12th, I covered the basics of career ladders for designers:

Fundament – Product Design Newsletter

The Path to Senior Product Designer: Why Seniority is More Than Just Years of Experience

How many years does it take to get from junior to senior product designer…

Read more

2 years ago · 6 likes · 3 comments · Arkadiusz Radek

While career ladders are great for giving a sense of the differences between each level, which can be extremely helpful for designers who have recently started their careers, they don’t cover all aspects of our work. Career ladders don’t explain how the definition of design evolves at each level, how the ratio of time spent on design tools versus other activities changes, or how differently 1-on-1 meetings look at each level.

In this two-part article, I’m looking at designers’ career levels from unusual angles. I’m covering some real differences between the levels that aren’t captured by most career ladders. To give this comparison a bit of structure, I split my thoughts into seven main areas:

• 🎯 Strategic thinking

• 🤝 Engagements

• 📃 Definition of design

• 👨‍🎨 Design process

• 🗺️ Scope and ambiguity of projects

• 🛠️ Tooling

• 👩‍💻 1-on-1 meetings

In part 1, I’m covering the first three areas. Next week, in part 2, I’ll cover the remaining four areas.

If you are not already subscribed to Fundament, don’t hesitate to do it now so you won’t miss Part 2 next week!

Subscribe now

🎯 Strategic thinking

It should not be shocking to everyone that designers at lower career levels have little in common with strategy. The term strategy could be a little intimidating or mysterious for interns, juniors, and even mid-level product designers. Does strategy happen in some secret room where designers have no access?

Not at all.

Strategy is simply planning further ahead.

Planning instead of just reacting.

For designers, strategic thinking could mean getting involved more in shaping OKRs during quarterly planning, driving innovation for new initiatives through design methodologies such as design thinking or design sprints, and simply asking better questions at different stages of the design process to better understand users, stakeholders, and peers in order to deliver something that brings positive change.

Miranda Slayter from has recently put a fantastic short article about getting started with strategic thinking for designers:

UX Survival-list

The first step to becoming a more strategic designer

Hey, Miranda here 👋…

Read more

10 months ago · 19 likes · 3 comments · UX Survival Guide

Let’s now examine what it looks like on each level of a career ladder:

1️⃣ Intern

As an intern product designer, you are most likely being told quite precisely what needs to be done. Further context might be provided, but usually just enough to understand why without going super deep, not to overwhelm you. As a result, your approach to work is almost 100% tactical, which is absolutely fine at this level.

2️⃣ Junior

As a junior product designer, you are still primarily focused on executing tasks that your PM or more senior designers have asked you to do. Strategy isn’t yet on your plate as you shall focus more on leveling up in other areas, such as user research, visual design, interaction design, and collaboration.

3️⃣ Mid-level

As a mid-level product designer, you are beginning to think strategically and ask questions early. Why are we doing this? Is this the best way to address the customer’s pain points? How does this fit into the bigger picture of what we are trying to achieve as an organization? This is the right time to make a mental switch, stop panicking about the term strategy, and start contributing more to prioritization discussions.

4️⃣ Senior

As a senior product designer, you are expected to be a strategic partner to your product manager, tech lead, and other product team members. You look at the problems from different angles and what’s most important from a helicopter view. You consider how your decisions affect the long-term game of your organization. Contribution to shaping this long-term game is something that starts popping up on your plate more and more often.

🤝 Engagements

The circle of people you work with continually evolves as you grow. Because when you become a mid-level designer, your role changes, and you start doing slightly different things than when you were an intern or a junior designer. As a result, to do your job well, you end up forced to speak to a very different set of colleagues from your organization.

The most dramatic change occurs when an individual contributor becomes a manager. From this moment forward, they are expected to spend more time with stakeholders and C-level team members than with their direct reports. If you aspire to reach this level at some point, please bear this in mind.

However, in this article, I will focus only on IC roles. Let’s explore how engagements evolve between intern, junior, mid-level, and senior designers.

1️⃣ Intern

As an intern designer, you should have at least one work friend: your buddy, who is usually a more senior designer, helping you figure out how to crack various aspects of this job. Additionally, you are at the square one of collaborating cross-functionally with engineers and product team members.

2️⃣ Junior

As a junior designer, you feel quite confident in discussing your tasks, ideas, and artifacts with engineers and product managers. You speak to the end users of your product or leverage insights gathered by other teams (such as the user research team, customer support team, or commercial team). You still have a good relationship with a more senior designer (or multiple of those) that you learn from the most.

3️⃣ Mid-level

As a mid-level designer, you still work very closely with engineers and a product manager from your team. You may occasionally need to communicate with engineers from other product teams if your product has dependencies on other pieces of the puzzle within your organization’s ecosystem. As you become more involved in shaping strategy and making a business impact, you start to engage with business stakeholders. You feel confident in planning user research activities and speaking to the users.

4️⃣ Senior

As a senior designer, you are a master of cross-functional collaboration. You work with folks from departments across the board, from engineering, through sales, up to C-level people. You often wear a detective's hat, looking for information needed to complete your tasks in various places, both inside and outside the organization. You feel pretty confident in discussing strategy with stakeholders. By no means, you still co-operate very closely with your product team members. In addition, as a more experienced colleague, you may become a mentor to an intern or junior designer and share some of your priceless knowledge with them. You finally go very horizontal.

📃 Definition of design

The incentives for starting a career as a product designer for most of us circle around a few themes. It’s either that we wanted to change the world into a better place for humanity through design, we felt artistic in our childhood (but not enough to become serious visual artists), or we wanted to be makers in the digital space, but weren’t necessarily skilled at coding.

Whatever your motive, if you are in this game long enough, you will notice that your perspective on the role of a product designer and the entire design industry evolves. The same as the definition of design.

1️⃣ Intern

As an intern designer, you spend most of your time in design tools such as Figma. You are being told what needs to be done, and you (hopefully) follow the instructions to create mockups, wireframes, charts, and prototypes that your engineering team will use to build functionalities.

Your definition of design is most likely very close to:

Design dictates what it looks like and is a helpful guide for engineering teams in building functionalities for our users.

2️⃣ Junior

As a junior designer, you still spend the majority of your time in the design tools, fighting with components and trying to lay them out in the most usable and beautiful way before handing it over to the engineering team. However, you start to question your tasks and speak to the users. You think more and more about why you and your team build what you build. You also begin to consider how your decisions influence the lives of your users.

Your definition of design is somewhat close to:

Design is a tool enabling a nice user experience through beautiful and elegant customer-facing interfaces.

3️⃣ Mid-level

As a mid-level designer who has gained some experience, you are starting to realize that you weren’t hired to just draw lovely rectangles in Figma. You joined your organization to solve not only the users’ pains but also to figure out how your organization can capitalize on design. As you begin to gain traction in moving to the strategic end of the tactical-strategic spectrum, you can demonstrate a meaningful impact on the business.

Your definition of design is now very close to:

Design combines the interests of business, users, and engineering in an elegant and usable way.

4️⃣ Senior

As a senior designer who has already seen it all, you only spend a fraction of time on moving rectangles in Figma. The majority of your work is split between exploring customer needs and business problems, as well as identifying their root causes. Additionally, you think strategically about which problems are worth solving now and how to solve them in a way that maximizes your organization's potential. In some organizations, you may be responsible for driving innovation and exploring opportunities for new products and offerings in collaboration with your product manager.

You know exactly why you were hired, and that dictates your definition of design, which most likely is close to:

Design is a strategic component for solving business problems and driving innovation while keeping the good interest of users in mind.

Part 2 of this comparison, including 👨‍🎨 Design process, 🗺️ Scope and ambiguity of projects, 🛠️ Tooling, and 👩‍💻 1-on-1 meetings, comes to Fundament next week. Subscribe now and don’t miss it!

Subscribe now

How did you like this episode of Fundament?

😍 ・ 🙂 ・ 😐 ・ 🫤 ・ 😡