Radek: Hi, this is Radek.

‍

Ilona: And Ilona.

‍

‍

What Is a Mature Digital Product?

‍

Radek: Today we have another episode of the Design and Business podcast, in which we will talk about the problems of mature digital products.

‍

Ilona, could you explain what actually lies behind this name, or what characterizes a mature digital product?

‍

Ilona: A mature digital product is a product that has already been on the market for some time. So we are not talking about a new startup that was built one, two, three, or even five years ago.

We are talking about a product that has already established itself on the market. It may be the leader of that market or simply provide a service on a local market and have existed for 8, 10, or 15 years.

‍

‍

‍

Goals of Mature Digital Products

‍

Radek: So the product has achieved success. Since it has been on the market for so long, it means that it has been doing something right.

But usually, if it comes to us, it means that it has reached some kind of dead point and is looking for new ways to grow.

The goal of such a client, who might come to an agency like ours, is to retain existing customers, but also to acquire new ones. Especially younger customers who have not yet had the opportunity to use such a service but are just beginning to have such a need.

Such clients, as I have observed over the years, understand and know that modern design and a good customer experience can be the solution.

But why do so many products, despite having great design, fail to achieve this goal? Why do so many products fail, and why doesn't working with the best agencies or designers help them?

We asked ourselves this question at Zima. We analysed real cases that we carried out ourselves and that were carried out on the market. And we came to the conclusion that even the best interface or even the best-designed purchasing journey, based on the best analysis of market needs, is not enough to achieve the desired result.

It is also important to analyse what is happening in the product team that has to deliver these artefacts. How does this team perform? How does this team implement the design? What does the decision-making process look like? And what competencies does this team have?

‍

Ilona: Now that we have Zima, now that we have our own company, we see it as if through a magnifying glass.

And taking into account our experience from previous projects... everything connects together, and our experience confirms what Radek has just said.

And we thought that if these two things influence each other so strongly and are so important...

‍

Radek: So the product, the design, and the design process itself.

‍

Ilona: Yes, the project, the design, but also the team that carries out the process...

It would be strange not to address the needs of both groups.

That is why we divided our services into services for the product and services for the team.

But that's not what we want to talk about today. Today we want to share with you the most common problems that we see in these two areas.

‍

‍

Problems of Mature Digital Products

‍

Radek: So let's start with the product. What would you say are the most common problems of mature digital products that we identify at Zima?

‍

Ilona: I'll mention them in random order. They don't have any particular priority just because I mention one first and another last. In my opinion, they are all equally important.

‍

Radek: And they don't occur everywhere, right?

‍

Ilona: Yes. It's not that every single one of these problems appears in every product, but these are the ones that repeat most often.

‍

‍

Outdated Design

‍

Ilona: The first thing we see is that the design stops being current and attractive.

I'll refer to what I said at the beginning when defining a mature digital product. It is a product that has already been on the market for some time. Let's say we have a product that is ten years old. It's now 2023, so it was designed in 2013. It went through a redesign somewhere halfway, let's say after five years.

And now we are struggling with a design that is already five years old...

Radek: ...while the trends have moved forward.

Ilona: Yes, the trends have moved forward. And just because we don't update or change our product doesn't mean that our competitors aren't doing it. And it doesn't mean that our users don't notice it.

Radek: They also look at other products, right? New, attractive—or, as someone might say—more sexy.

And you can see it. Potential customers see it. Existing customers see it as well. This is a problem that the owners of such products often notice themselves. They can see that the design has become a bit outdated.

Ilona: Yes, it requires redesigning.

And we are aware of this problem, but somehow it is difficult to plan for it. Somehow it always ends up low on the priority list, and it is always difficult to make the decision.

Because, of course, it is a difficult decision.

‍

‍

New Competition Is Emerging

‍

Ilona: But our users compare our solution with others, just as you mentioned.

And this brings us to another problem—new competitors are emerging.

A new, interesting product appears, and at first we ignore it. At first we don't pay any attention to it...

"They're different."
"They have a different business model..."

Radek: And this applies not only to design, but also to the quality of the service.

Because the service may seem to be the same, but the quality—that is, the way the customer experience is built—is different.

Ilona: Yes. And for companies like that, it is difficult to compete for new customers.

With products that have already been on the market for some time, we constantly have to acquire younger audiences. People who are entering the market and developing a particular need.

The moment we ignore new competitors, our existing customers slowly begin to leave us, while new ones stop coming.

And then we have a problem.

Ignoring such a player as a result of insufficient market monitoring may cause our brand to lose its leading position.

‍

Inadequate Market Monitoring

‍

Radek: Tell me, what does market monitoring actually mean? Looking at websites? Turning on Brand24? What does it really mean?

Maybe this isn't a problem that affects everyone, but I have the impression that there is a common belief that, "Of course we monitor the competition. I know what the competition is doing because every time a new year starts, we prepare our strategy. We make a presentation, compare our competitors—both the close ones and the more distant ones... We know everything. That's enough for the whole year."

Ilona: What you're describing now, I would treat as a sub-point of the problem we're discussing, because brands don't conduct regular competitor analysis.

Whenever they need to build a new product, at the very beginning... everyone says, "Let's see how others solve this. Let's see what tools users are using today."

And everyone does research at the beginning. They look at what's happening on the market, and then they stay with that knowledge.

We get the feeling that we already know it because we've already checked it.

But imagine someone who carried out a competitor analysis before ChatGPT was released and says, "But I already did that a year ago."

We need to remember that the world is developing very quickly, and the release of something like ChatGPT can completely change our perspective and the way users interact with our product.

Not doing research on a regular basis unfortunately means that we don't have the necessary knowledge and cannot react in time.

Radek: I'd add another sub-point.

Let's say there's a plan to build a new feature.

We conduct competitor analysis for that feature. We look at what others are doing and think, "Okay, they do it this way..."

We implement something similar—or even better. We introduce some improvements.

And that's it.

We don't come back to it after appropriate periods of time.

We don't return to see what the competition is doing now and what they've done with that feature, with functionality similar to the one we've implemented.

How are they actually developing it? What decisions have they made?

These are things we really need to keep an eye on.

‍

‍

The Copycat Problem — A/B Testing

‍

Ilona: But this is connected to another problem that I observe—the lack of metrics and the lack of willingness to conduct A/B tests.

We observe how others have done something.

Then we copy it one-to-one into our own product...

...which doesn't always mean it will fit our product.

Or our customers.

Or our user journey.

Or even our business model.

We simply take a copy of what we saw somewhere else and move it into our own product.

We also talk about this in another episode of our podcast about benchmarkosis—creating benchmarks and copying competitors' solutions one-to-one.

Today I'd rather focus on the fact that we don't have our own metrics.

So we aren't actually able to say whether something is good or bad for our business.

And there is also a reluctance to conduct A/B tests.

I understand that as well, because an A/B test takes time.

It's not like we can show something to five users, collect feedback, and immediately move forward.

No.

We have to develop the functionality—or at least part of it—and test it in a live environment, meaning on real traffic in our website or application.

That process takes time.

Radek: Yes, and that creates yet another problem.

Not everyone—even if they want to run A/B tests—actually knows how to do them properly.

Launching an A/B test is not simply about sending 50% of traffic to one version and 50% to another.

That can actually be disastrous for the business.

You need to choose a portion of traffic that won't create the risk of damaging the business.

That's one of the dangers of running a poorly designed and poorly implemented A/B test.

There are many more risks—we won't list them all now.

But even if the willingness is there...

...how do we actually measure it?

What data do we receive?

And based on that data, can we really make informed decisions?

‍

‍

Intuition Doesn't Always Tell You the Truth
‍

Ilona: Another problem I see, apart from the lack of metrics and the unwillingness to conduct A/B testing—which directly results from that very issue—is making decisions based on intuition.

And while, at the very beginning of a business, many of our decisions have to be based on intuition, and that intuition is probably one of the factors behind the success of a given brand or service... once we've been on the market for some time, we can lose that sense of direction.

And again, we can't expect everyone in our organization to have flawless intuition either. More and more people are making decisions. That's why I see this as a serious problem.

Radek: I think it may also stem from the fact that when we created our digital product, when we built our brand... we were operating in very different times. In a completely different reality.

The needs were completely different. The market looked completely different. Our customers had slightly different needs. They also had slightly different preferences.

That intuition may have worked back then, and we may have had a very good feel for the market at that particular moment. But the context has changed because the world has changed.

And I suspect that's one of the reasons why we keep trying to rely on intuition, but it's no longer as effective as it used to be.

‍

‍

‍

Negative Experiences from Previous Collaborations

‍

Radek: I'd also like to mention something that may sound controversial again—maybe even like shooting ourselves in the foot—but it's a real problem. It's the issue of bad experiences working with UX/UI agencies and freelancers.

Honestly, I'm not surprised. It's incredibly difficult to create meaningful change by focusing solely on the product itself. Without understanding all the factors that determine how the product works, the company's characteristics, the brand, and everything surrounding it, it's simply impossible to develop a truly good solution.

I see two underlying problems here that aren't limited to working with agencies, although they become particularly visible in that context. The first is that designers often come up with ideas that are detached from business reality.

That's exactly what a business owner would say. That's what a product owner would say. And it's something that immediately raises red flags when agencies come in saying they're going to transform the product—that it's going to be amazing, packed with incredible features, and deliver a groundbreaking user experience.

Often, all it takes is digging a little deeper. Understanding the situation better. Becoming part of it. That way, you can deliver something that improves the product instead of putting it at risk.

Because, as I said at the beginning, that product is probably still doing many things right. So the goal isn't to completely tear down a huge machine that's already working. The goal is to approach it carefully, making changes at the right pace so they can be introduced successfully.

Ilona: Yes. From my own experience in previous companies, where I had the opportunity to work with external agencies... they often don't understand the business. They come in with flashy ideas that are difficult to implement or simply inconsistent with the product as a whole.

Most importantly, they don't dig deeply enough into the actual problems—their causes, their complexity, or the context in which they occur. And without truly understanding those things, it's very difficult to propose a solution that's actually appropriate.

Radek: And just so it doesn't sound like we're only criticizing other agencies—it happens to us too.

Imagine a client coming to us saying, "Design something that will help us achieve all of our goals." The natural reaction inside an agency is to prepare a proposal that addresses exactly the need the client has expressed.

Ilona: Yes—if you don't run a workshop first, right?

Radek: Exactly. And that happened to us too.

Ilona: Of course. It's part of learning.

Radek: A client comes in convinced they know exactly what they want. And that's why I don't want to blame agencies, because we've made the same mistake ourselves. We're not perfect.

Sometimes we believe our clients—or they're simply so convincing that we assume they truly know what they need. And that's exactly the issue. It happens to us as well.

But that's when problems begin to appear, and you end up having to go back to the very beginning...

Ilona: Yes, but today we already know that it doesn't make sense. At that point, it won't be a satisfying collaboration for either side, so we'd rather walk away.

‍

‍

Mess in the Product
‍

Radek: Exactly. I think we've covered the biggest problems...

Ilona: No, there's still one more.

Radek: One more?

Ilona: Yes, one more. My favorite one, actually—and that's mess in the product. A complete mess.

Radek: Right. I agree.

Ilona: So what do we mean by that? It's not even about the lack of a process—I don't even want to put it that way—it's about the lack of order when building the interface. There's no shared component library.

For example, there are five designers, and each of them works in their own way. Each one uses different elements to build the interface.

Business owners listening to us may not fully understand what we're talking about because this is more of a designer's world...

Radek: ...and a developer's world. I'd also replace "designers" with "developers." So when you say five designers each do whatever they want, I'd say five developers each do whatever they want.

Which means that even if we have one designer who's doing everything correctly and consistently, we still end up with five developers implementing things however they want.

Ilona: Exactly. Whoever gets the task does it differently. That's true as well.

So business owners listening to us might now be thinking, "Okay, but I have absolutely no idea how to control that or even how to verify it." And we're definitely not encouraging micromanagement—standing behind your designer and checking whether they're using the correct components.

However, if you can clearly see that different user journeys throughout your product look different—and simply by looking at a particular screen, you can tell which developer implemented it or which designer designed it—that's a problem.

It means there's a mess in the product.

Now, if that's intentional—for example, because one section has already been redesigned while another is still waiting for its redesign—then that's perfectly fine.

But if it isn't intentional, then we have a problem. Imagine that a designer leaves the company and someone new joins. They inherit a billion design files and have no idea which one is the source of truth. That's when things become a real issue.

Radek: And what does that lead to?

Ilona: A messy product—and users notice it. They see the inconsistencies.

Radek: ...

Alright, I guess we can finally wrap up discussing...

Ilona: One more!

Radek: Another one? We're never going to finish this episode today.

Ilona: Okay, the last one.

‍

Innovation or Safety?

Ilona: One of the biggest challenges for mature digital products is that we want to be innovative. We know we need to change. We commission a redesign because we know our current design is no longer attractive enough—but at the same time, we don't want to take too much risk.

So we're constantly trying to balance innovation with safety.

And that's incredibly difficult because what's in the middle is simply... something average.

Radek: Those are exactly the negotiations that have to happen within a team.

Problems Within Mature Teams

‍

Ilona: Now we can move on to the problems that occur within teams.

Radek: Yes, we can finally get to the topic of teams, which I personally think is extremely important. I really like this area because I believe it isn't properly addressed. People don't openly talk about it.

I think that, for many years at Zima, what we were doing—perhaps without even realizing it—was taking care of these issues. At first unconsciously, and later consciously by giving them names.

And that's exactly what we're going to do now.

We're going to talk about the challenges related to teams working on mature digital products.

‍

‍

An Inadequate Level of UX/UI Expertise Within the Team

‍

Radek: Ilona, what's the first problem you see?

Ilona: Companies often hire people whose UX or UI skills simply aren't at the level their organization actually requires. And I'm not saying every company needs to hire a Senior Designer—that would probably be the ideal solution for most businesses.

But if you have a mature digital product and you hire a UX designer with very little experience, you can end up doing significant damage to your product.

Radek: Well, I'm not sure I'd completely agree. It depends on the scale of the product and the type of product.

But every company needs at least one experienced person. There has to be someone at a senior level. Someone has to lead those decisions.

There has to be someone who can consciously, wisely, and responsibly guide everything related to the user, the interface, and the overall user experience. Otherwise, it will show in the interface, and it will have a major impact on how the product evolves.

And that's particularly important for mature digital products.

When you're just starting out—as long as you're still in the early stages of building a digital business—you don't need UX expertise or an experienced designer quite as much.

But once your product reaches maturity, both the designer and their expertise have to be at a very high level.

‍

‍

Lack of Leadership in Design Management

‍

Ilona: I also see another problematic area. It's related to creating and managing the roadmap.

While I can't imagine that, in a mature digital product, a UX designer alone would be responsible for creating the roadmap, they are still expected to execute it.

‍Radek: The lack of that kind of senior-level responsibility leads us to another major problem: the lack of leadership in design management.

And if there's uncertainty about what the designer is actually supposed to work on—if decisions keep changing throughout the quarter, or if those decisions simply aren't made for a long time...

...the quarter begins, and designers are still working on things from the previous quarter. No one is entirely sure what the priorities are.

All of this means we're wasting money, resources, and the potential of what that designer could actually deliver.

‍

‍

Decision-Making Deadlock

‍

Ilona: Which brings us to another problem—we're moving one level higher now.

It's the issue of decision-making deadlock.

Why isn't there a roadmap? Because there's some kind of decision-making stalemate. There's a conflict. Maybe not a direct conflict where people are arguing with each other, but rather a conflict of interests and different opinions about the direction the product should take.

That's what creates a decision-making deadlock.

There's no quarterly plan—or even an annual one—which means some initiatives never get completed, or...

Radek: ...or we simply stop moving forward.

Yes, I see this very often too. There's usually one person who has to make every single decision.

And when it comes to design, having one person approve every step, every interface element, or every design solution... that's taking things too far.

Ilona: Exactly. But there's something important to add here.

The problem is when that one decision-maker isn't a designer.

If we allow the designer to make design decisions, the interface will remain consistent.

But if someone else wants to approve every single screen, then we have a problem.

Radek: And again, that decision-maker might be a mature, experienced person within the organization who provides leadership for those decisions.

But if we don't address the issue of the person above them—someone who still wants to control or approve every design decision—we'll end up blocked anyway.

So even if we solve one problem, failing to solve the one above it means very little will actually change.

‍

‍

Distributed Responsibility

‍

Ilona: There's also another version of this problem: distributed responsibility.

That's when no one actually knows who's supposed to make the decision.

Radek: And that directly affects everything we just talked about.

Sometimes there's officially one decision-maker, but that person ends up letting someone else make the decision.

And in the end, nobody really knows who's actually responsible.

We also need to remember that many people in these teams—not just design teams—have been with the company for many years.

Over time, they change roles. And often those new roles aren't the best fit for them, or they're simply not experts in that particular field yet. They still need more learning and practical experience.

But because they've been with the company for so long, they're promoted into senior positions.

Then they struggle to make decisions because they simply don't have enough expertise in that area.

And that's exactly how decision-making becomes distributed.

People are simply afraid to make decisions.

Ilona: Or they're afraid to make decisions because, at some point in the past, they were punished for making one.

That's how distributed responsibility—and distributed decision-making—begins.

Eventually, nobody knows who's supposed to sign off on something or who should take responsibility for it.

‍

‍

Problems with the Roadmap

‍

Radek: Can I go back to the roadmap for a moment—and to the designer's role in it?

Ilona: Of course.

Radek: I think one of the biggest problems is that we don't fully understand what we should actually expect from a designer during the roadmap creation process, or what value a designer can truly contribute.

As you said, of course we're not responsible for creating the roadmap itself.

But business goals are also shaped by how well we understand users' needs.

Because if we address those needs successfully, we'll achieve our business goals as well.

So if we want to build a roadmap that truly supports business objectives, we first need to deeply understand our users.

I know I'm speaking in broad terms here, but it's precisely those insights that allow us to prioritize correctly and determine what our roadmap should actually look like.

The process of validating that roadmap is equally important.

We can create as many roadmaps as we want, but if we don't validate whether we're actually moving in the right direction—or if we don't include a process for validating our assumptions—the roadmap becomes nothing more than an artifact.

Something created simply for the sake of having one.

Ilona: Exactly.

And then nobody ever looks at it again.

By the end of the quarter, everyone realizes that things weren't completed because of A, B, C, or D.

Radek: That's interesting.

You know, delivering a roadmap is actually a lot like achieving KPIs.

Everyone has their own objectives they're supposed to complete.

And once again, every team focuses on its own individual goals in order to deliver a particular result.

The same thing happens on a smaller scale.

As an employee, I have my own annual objectives that I need to accomplish.

And I accomplish them because that's how the system in my company works.

Ilona: That's exactly why those goals exist—to be achieved.

Radek: Absolutely.

The real question is whether they're being validated.

If they are—and if they're meaningful—then achieving them creates value for both me and the company, because we've accomplished goals that genuinely improve the business.

The same applies when goals aren't defined properly.

And they can be defined properly through validation, through gathering requirements, through learning directly from users, and so on.

That's how we're able to reconcile two things at once.

Not only do I complete my own tasks...

...but I complete them in a way that also creates real value for the business.

‍

Poor Communication Within the Team

‍

Ilona: I'd like to move on to what I consider the biggest and most serious problem—not only in design teams, but probably in every team, in every company.

And that is poor communication.

I describe it as everyone working in isolation—everyone looking after their own little corner.

Whenever I think about this kind of situation, I'm reminded of a story from one of the companies I worked at before joining Zima.

I was working with other designers and needed to prepare a new feature for an application. I asked one of the UI designers to share the editable source file.

The UI designer simply replied, "No, I'm not giving it to you."

Radek: That's certainly a very direct form of communication, Ilona.

Ilona: It was. But the consequence was that I had to recreate the entire file myself.

I lost about two days redrawing everything from scratch just so I could add the new elements needed for the mockups and present a concept of how the new feature might work.

It was the perfect example of everyone working only for themselves.

"I'm working on my own part. I'm not going to share my files or my work with you. You stay in your area and do your own thing."

That was a huge problem in that company.

It taught me the importance of setting clear expectations for collaboration right from the beginning.

Although, to be honest, I'm not sure it would have helped much in that particular case. We'd already been working together for quite some time, and sometimes situations like that simply happen.

Radek: You know, I think communication also comes from establishing some fundamental principles for working together. Communication is only one part of that.

Because technically, you could say that person communicated very clearly that you weren't getting the file.

Ilona: And how do you know it was a man?

Radek: The moment you said "UI designer," my brain immediately imagined a man.

I don't know... Our brains are still full of stereotypes from the times we grew up in. They just do their thing automatically.

But this is important.

First, there's collaboration—the rules that define how we work together, how we want to cooperate.

Then comes communication—how we want to communicate, with whom, and about what.

Even communication style matters.

In some organizations, a certain communication style may come across as blunt or dismissive.

Some people like talking a lot, and that's exactly what's needed in their teams.

Others prefer writing messages.

Others would rather make a phone call.

The important question is:

What kind of information belongs in a chat message?

What should go into an email?

And when should we simply jump on a call?

Honestly, I've lost count of how many times I've seen important decisions discussed over the phone in a quick conversation...

...and then everything simply disappeared because nothing was documented.

Ilona: Exactly.

‍

‍

Challenges in Recruiting the Right Specialist

‍

Radek: These are such fundamental, foundational issues, yet they have a huge impact on how design is later developed and managed within an organization.

If we want to build great design, these things also need to work properly. They have to be addressed.

I'd like to go back to the topic of senior UX and UI experts—but actually, this applies more broadly.

When there's no leadership, as we mentioned earlier, companies often struggle enormously with recruitment.

It's incredibly difficult to hire the right person—someone who truly fits the organization, its challenges, its problems, and its way of working.

It's not only about hard skills.

It's also about soft skills, which are strongly influenced by the culture of a particular organization.

Without leadership, recruiting that kind of person becomes extremely difficult.

A Product Owner is probably the closest person who could recruit a designer.

But even then, they usually won't evaluate that person's work or competencies as thoroughly as an experienced design leader would.

And that's before we even mention the fact that hiring a senior designer is already a huge challenge.

Hiring real talent is an even bigger one.

Hiring a designer is relatively easy.

Hiring an expert—someone who's excellent across multiple dimensions—is a completely different challenge.

It's difficult even for us.

So imagine how difficult it is for companies that don't have someone internally who truly understands design and can properly evaluate candidates.

‍

‍

A Puzzle of Problems

‍

Ilona: That's absolutely true.

As an agency, we've made it our mission to specialize in solving real business problems.

We have the knowledge because we've spent a tremendous amount of time analyzing all the situations we've encountered—both at Zima and in our previous jobs.

And we've learned that it's very rare for a company to have just one of these problems—for example, only a product problem or only a team problem.

On the other hand, companies rarely have every single issue we've listed either.

Usually it's a complex puzzle.

A complicated equation made up of several smaller problems, a few medium-sized ones, and perhaps one major issue.

Some of them are product-related.

Others are connected to the team.

Our goal is to begin every collaboration by thoroughly understanding that specific problem—and understanding that entire equation.

I truly believe that this holistic approach allows us to identify what the situation really looks like in both areas.

Radek: I'd actually go one step further, Ilona.

I wouldn't even call it a matter of belief.

That's simply how it is.

We've stopped pretending that things work differently or telling ourselves that we deal only with the product.

Because we don't.

We also deal with everything surrounding the product—especially the factors that determine how that product is actually delivered.

‍

How Zima Solves the Problems of Mature Companies

‍

Radek: Those are the team-related issues.

And I think this is a good point to pause because, when it comes to discussing the problems of mature digital products, we've now reached the end of that topic.

Anyone who was interested only in that part can safely stop listening to this episode here.

From this point on, we're going to talk about how we approach solving these problems in both areas.

In other words, how we work and what exactly we can offer to help solve these challenges.

So, Ilona, let's begin with the way we work.

What does our process look like at a very high level?

I think it's only three steps—or even fewer.

‍

‍

Workshop Zero

‍

Ilona: We begin with Workshop Zero.

Radek: What exactly is Workshop Zero?

Ilona: It's a meeting that lasts around four to four and a half hours.

Radek: It can last that long. It varies.

Ilona: Yes, usually up to four hours.

The outcome of this workshop is an analysis of the current state of both the product and the team.

It's essentially a map for us.

We create that map.

We understand what the product looks like, what the team looks like, and by bringing those two worlds together, we're able to identify the problems we've diagnosed.

‍

‍

Action Plan

‍

Ilona: Only then can we move on to preparing an action plan.

It's only after we've mapped all of those problems that we're able to create a meaningful plan.

Radek: What's important is that Workshop Zero is conducted together with the client.

We extract all of this information directly from the client, synthesize it, and combine it with our own preparation, audits, and research.

Based on all of that, we prepare the action plan you just mentioned.

After that, we prepare a realistic proposal that the client can implement with us.

Or, if they prefer, they can take it to another agency.

Or even implement it internally on their own.

That's what makes it valuable.

It provides a genuine analysis of what actually needs to be done.

Some of those things are small improvements that can be implemented quickly.

Others are much larger initiatives that require more time and effort.

‍

‍

Book a Workshop Zero

‍

Radek: If you'd like to book a Workshop Zero, simply visit our website at designzima.com.

If you're browsing on a desktop computer, you'll find the "Ask an Expert" button in the upper-right corner.

And if you're on your phone...

...let me quickly check...

You can book the workshop there as well, and either Ilona or I will get back to you.

Our core assumption is that the analysis of your situation comes first—not the design process.

We're not the kind of agency that walks in and immediately says, "We'll build this," or "We'll redesign that."

First, we need to understand you thoroughly.

Just as we first research your customers during the design process before creating solutions, we first study your business.

Only then can we truly understand your challenges.

Because the truth is—we never know ourselves as well as we think we do.

Everyone benefits from an outside perspective.

From someone who can help identify what's really happening.

Ilona: I think the most important thing to emphasize is that your situation is at the center of the analysis—not the design process itself.

Radek: Exactly.

Ilona: The action plan—and eventually the implementation—are simply the result of the conclusions we reach during that analysis.

So if you feel that your company is facing any of the problems we've discussed today...

...we'd love to invite you to Workshop Zero.

‍

‍

Zima's Services for Solving Product Challenges

‍

Radek: Ilona, after Workshop Zero, our client receives a proposal from us.

That proposal includes specific services and concrete solutions—things that we, as Zima, can do to address both product-related and team-related challenges.

Could we briefly go through what we offer for the product first?

Ilona: Our product-related services begin with research.

We conduct research to understand the expectations and needs of your customers.

This includes user needs research, analysis of all the materials you already have available, analytical data, statistics, reports, A/B test results, and other existing resources.

We also facilitate design workshops, which we mentioned earlier.

These workshops allow us to gather knowledge and ideas directly from your team members.

They also do an excellent job of engaging the team in the entire design process.

We also offer a service focused on competitive intelligence.

We prepare regular reports containing information about your competitors' strategies, plans, and anything else we've been able to discover.

Of course, we also improve the UX and UI based on all the data we've collected.

The classic combination: User Experience Design and User Interface Design.

We build Design Systems specifically to solve the problem of product inconsistency and design chaos.

We also create Experience Strategies, which focus on customer satisfaction.

I know that the phrase Experience Strategy may sound a little vague.

But just as companies typically have a business strategy before implementation begins, we believe the customer experience should also be guided by a clear strategy.

Radek: In other words, we're defining what kind of emotions we want to create for our customers.

Do we want them to feel cared for?

Do we want them to feel that we've made their lives easier?

Do we want to give them an enjoyable experience?

There are countless possibilities.

And that's exactly what we work on together with our clients.

But what's equally important is that we define measurable indicators for that experience.

In other words, how do we know whether the experience of using a product or service is actually good?

And, more importantly, how do we know whether it's the experience we intended to create?

For example, to what extent does the customer feel genuinely taken care of?

We measure it.

We monitor it.

That allows us to continuously evaluate and improve the product in the direction we've defined in our Experience Strategy.

Are we really creating the experience we set out to build?

That's incredibly important because customer experience can easily become a vague concept.

And if you can't measure something, you can't truly improve or optimize it.

Of course, we also conduct a wide range of research methods, including Buy a Feature, Card Sorting, and Tree Testing for information architecture.

There are many more methods than these.

Each of the services we've mentioned actually includes numerous smaller activities and techniques that we use depending on the specific needs of the product.

As you've probably noticed, these are all services directly focused on improving the product itself and supporting its development.

‍

‍

Zima's Services for Solving Team Challenges

‍

Radek: But we also provide dedicated services aimed specifically at strengthening the team.

Their purpose is to improve the team's effectiveness, raise the quality of its work, and optimize the design processes within the organization.

We offer mentoring, where we mentor your existing design team—especially if it's not yet fully independent or still developing its capabilities.

We help the team deepen its design knowledge and support them in making better design decisions.

Ilona: We also offer a service called Design Lead as a Service (or Design Lead by the Hour).

In this model, an experienced design leader temporarily takes on the role of Design Manager within your project.

They help define the action plan and create the design roadmap.

They also manage the team of designers.

Radek: And they help build that team internally as well.

Ilona: Exactly.

And that naturally connects to another service we provide—recruitment.

We help companies recruit experienced UX designers, UI designers, and UX researchers.

We also run workshops focused on transferring responsibility, building high-performing teams, and developing the skills of individual team members.

In addition, we analyze the way your team works, along with your internal processes.

This helps identify areas where improvements or optimizations can be made.

We also facilitate decision-making workshops, which directly address the problem of decision-making deadlock.

So everything we're talking about here is directly connected to the problems we identified earlier.

Radek: Exactly.

And there can be many more services than the ones we've mentioned today.

Everything depends on the diagnosis.

These are simply examples.

I think it's worth visiting our website at www.designzima.com to learn more.

Or, even better, simply click "Ask an Expert" and get in touch with us.

If you'd like to learn more about these services—or discuss how we could create a customized set of services tailored specifically to your organization—we'd be happy to talk.

I think that's all for today's episode.

Ilona: Thank you very much for listening to this episode.

‍

‍

We'd Love Your Feedback!

‍

Radek: Before we finish, I'd like to ask you something.

If you have any thoughts about the problems we've discussed...

Maybe you're the owner of a digital product that's been on the market for several years.

Perhaps you're not currently looking for an agency, but you've gathered your own interesting insights about these challenges.

Or maybe you'd simply like to comment on one of the issues we've mentioned.

Ilona: Or perhaps you completely disagree with what we've said.

Radek: Exactly—that's just as valuable.

We'd love to hear from you.

Feel free to send us a message through our website.

We'd be incredibly grateful for your feedback.

And we'd be equally grateful for any additional insights you'd like to share.

I think all that's left now is to say goodbye.

Thank you all very much for joining us once again.

Ilona: Thank you, and see you in the next episode.

‍

‍