I started building Leaflo about a year and a half ago or so. Back then, I thought through the feature set, the rough positioning, did a competitor analysis, and after building about half of the product, I put it aside for different reasons. It happens.

When I came back to it, I started discussing the product with ChatGPT more often. And somehow, over time, I drifted into a completely different positioning — one that moved me away from my original idea.

Originally, I was planning to build a CBT journal that helps a person during therapy, and also before and after it. Because journaling is a common practice in therapy.

But in the end, I drifted into a wellness-style personal journal. And the product itself became a bit split.

On one hand, it had simple personal diary features. On the other hand, it had a library of prompts, which belongs more to a focused, goal-oriented writing format.

At some point, I realized I had moved in the wrong direction. And now I’m spending time and energy trying to get back to the starting point.

The conclusion is simple:

When you discuss your tasks and projects with AI, don’t forget your own ideas and intentions. Most likely, they are more valuable than anything AI will suggest to you.

Don’t switch off your own thinking. Use AI for specific tasks and specific requests, but try not to trust it with anything strategic.

It should not make conclusions for you or pull you away from your direction.

Sounds obvious — but I still fell into this trap.

I recently wrote about how ChatGPT had, in some ways, pulled me away from Leaflo’s original positioning.

So I spent the past week bringing the product closer to where it probably should have started.

First of all, Leaflo is now a CBT journal.

The daily ritual has become a guided check-in. The mood check has turned into a more powerful selection of specific emotions.

Inside the check-in, each emotion now has its own set of questions. This part still needs more work, but the direction is already much clearer.

The prompts changed too. They are now more thoughtful, more structured, and more closely based on CBT practices and guides.

They are also grouped by the areas where they can help.

Meditations have turned into breathing exercises.

I also changed the keywords, title, and description in the App Store.

And the cherry on top: localizations finally arrived.

This is still a first version, with plenty of rough edges, but the app and the App Store page are now translated into seven languages: English, German, French, Russian, Serbian, Spanish, and Portuguese.

I translated everything with ChatGPT, so I’m sure there is a small mountain of cringe in places I can’t see yet.

But it is still better than keeping everything in English for people who do not speak it. I’ll keep improving it from here.

Overall, this turned into a pretty big release.

Now I’m curious to see what it leads to over the next two or three months.

In the meantime, I’ll keep working on Leaflo’s marketing channels and start researching a second product. It looks like it might be something related to presentations.

Stay tuned, as they say.

I released an update for Leaflo with monetization, new themes, icons, meditation audio, PDF export, and several export options, including manual note selection and date ranges.

Preparing the release took about half of the week because there were quite a few scenarios to test. As I wrote earlier, this is one of the most time-consuming stages for a solo developer.

On top of that, it was my first time figuring out how monetization works in the App Store. So far, everything seems to have gone smoothly.

On the distribution side, I'm continuing to publish content to grow SEO and social media. I do not expect any serious short-term effect here. My guess is that it will take at least six months before the first noticeable results show up.

The plan for this week is to continue publishing, work on the design of future Leaflo features, and start thinking about a second app.

The active development stage of Leaflo is gradually coming to an end, so the main focus will now shift more toward marketing.

Once I have a more concrete idea, I will definitely share what kind of app it will be.

Writing specs is not the hard part for me. Neither is design.

But testing? Testing is slow, repetitive, and surprisingly difficult to make efficient.

I try to cover everything that can reasonably be covered with automated tests. But that still doesn’t remove the need for manual testing.

There are always flows, edge cases, small UI details, real-device checks, and other things that tests don’t fully catch.

Right now, I’m trying to stay disciplined and go through my test cases properly, because app quality matters to me. But as the product grows, this takes more and more time.

I’ve also tried to think about automation, but UI tests often feel too fragile to fully rely on.

So I’m curious: how do you optimize QA for small products or indie apps?

I still do not have a ritual for these notes. Starting is the hardest part. It rarely feels like "sit down and write." It quickly turns into a small product problem of its own: what should I write about, when should I do it, where should I publish it, how polished should it be, and how personal do I want to make it.

So instead of overthinking the format, I will start with a simple snapshot of what I am building right now.

The main bet is Leaflo.

That is where most of my focus goes now. The product is already live on the App Store, but that does not feel like a finish line. It feels more like the start of the next stage: improving the product, testing the positioning, finding users, figuring out distribution, and getting to the first sales.

Then there is Pilekeeper.

I quietly launched it, but I have barely talked about it publicly. It is still an alpha, it has plenty of bugs, and I still do not fully understand how to position it or whether the market really needs it. But I use it myself every day.

I also have a couple of Figma plugins, Commentor and Grider.

I made them a while ago and, to be honest, I did not give them enough time or care. Commentor had some interesting ideas for future development, but right now I am not sure whether it makes sense to keep pushing it forward.

And of course, there is a pool of other ideas in different stages of readiness.

The main problem is that most of my current projects started as things I made for fun. I built them because I liked the idea. At that point, I was not thinking enough about the market, the niche, sales, or monetization potential.

Now the situation is different.

It is no longer enough for me to make interesting things. I need to learn how to bring products to market, find customers, validate demand, and turn ideas into an actual business.

That is why I am concentrating on Leaflo.

Right now, it is the project with the clearest path to monetization. At the same time, the journaling app market is crowded. The competition is strong, the products are good, and many of them already have very clear positioning.

So we will see how it goes.

My plan for the near future is simple.

The first goal is to make the first dollar in sales.

Even that is not a small step. I need to improve the important parts of the product, package it better, explain the value clearly, bring people in, and convince someone to pay.

The second goal is to get to a point where the product can at least cover my basic expenses.

The third, more distant goal is to make it sustainably profitable.

The rough horizon I have in mind is 12 to 18 months.

At the same time, I do not plan to keep betting on one product forever no matter what. I will watch what actually moves, switch when needed, test hypotheses, and focus on the things that show real signs of life.

I want to share a bit about the motivation behind this positioning.

First, CBT is one of the most evidence-based approaches in therapy. Not all therapy methods are studied equally well, and that matters to me.

Second, I’ve been through therapy several times myself, read books and articles on the topic, and tried different techniques in practice.

I’m not a therapist, but I understand the basic logic fairly well: how thoughts, emotions, and behavior are connected, and why the right question can be more useful than another page of free writing.

Third, I think it’s important to make these methods more accessible. Not in a “fix yourself in 5 minutes” kind of way, but in a more honest way: here is a tool. It’s not magic, but it can help you better understand what’s going on inside.

And most importantly, it simply makes the product more useful.

A regular journal helps you record an experience. A CBT journal helps you work through a situation.

It’s not a replacement for therapy, and I don’t want to sell Leaflo as a replacement for therapy. But a journal can be a useful support: before therapy, alongside it, or after it, when you want to keep the habit of self-reflection.

That’s why Leaflo is gradually becoming not just a place where you can write about your day, but a more structured CBT journal that helps you not only record your state, but also work with it a little better.

But while building Leaflo, I decided there will be no streaks in the app.

First, a mental health app should not create pressure.

Leaflo is an app for situations when a person feels tired, anxious, overwhelmed, scattered, or emotionally stuck. In moments like that, there are few things worse than being told that you have also lost your streak.

A person in a difficult state is often already dealing with guilt, self-criticism, and the feeling that they are "not coping well enough." If an app adds one more small obligation on top of that, it can stop being supportive and become another source of pressure.

A mental health product should reduce the load, not create a new one.

The second problem with streaks is that they quietly replace the meaning of the action.

The user opens the app not because they need to understand what is going on inside, but because they do not want to lose the streak. From the outside, it looks like retention. But inside, the scenario changes from "I feel bad and want to understand what is happening" to "I need to open the app so I do not break the streak."

The goal is not to make a person mechanically open the app every day.

The goal is to give them a safe and non-judgmental way to return to themselves when they actually need it. A missed day should not be interpreted as a failure.

Returning matters more than continuity.

I wanted to test this in practice.

So I ran my own experiment and tried, in many tasks, to stop using Figma and use code-based prototyping instead. Not as a nice weekend demo, but inside a real product, in parallel with my normal work.

One important clarification first. This is not about a designer moving into production engineering. And it is not about writing code that later ships to production. In my case, a coded prototype is a separate design artifact. Its job is to help me build, show, discuss, and test a solution in a more realistic way than a static mockup can.

My hypotheses

I started with fairly simple expectations. I thought code prototyping would:

• speed up design creation;
• make handoff to engineering easier;
• make demos clearer for stakeholders;
• help me iterate faster;
• give me a more native artifact for UX research;
• help me feel the product more strongly than static screens;
• be more convenient than Figma in some types of tasks.

Looking back, I can say that some of these hypotheses were confirmed, but not where I expected. The main value was not really in drawing faster. It was in the type of artifact and in the quality of testing interface behavior.

Conditions of the experiment

I am not a programmer, but I am also not someone who saw code for the first time yesterday. I can read code, I understand the basic frontend and backend infrastructure, I know HTML/CSS, I wrote simple Figma plugins in the past, and I have always built and maintained my own portfolio myself. So, in short, code was not a foreign environment for me.

At the same time, the product I work on is not the easiest one, but it is very revealing for this kind of experiment. It is a mobile AI app. That means I somehow need to prototype a non-deterministic system. In interfaces like this, UX does not live only in the screen itself. It also lives in what the user typed, how the system interpreted it, and what kind of answer it showed next. Static screens do a poor job of showing that.

On top of that, a mobile interface prototype needs to be shown on desktop, on a phone, and sometimes on desktop while emulating a phone.

To make the prototype feel at least a bit like a real product, I had to connect it to a live ChatGPT. Not in a full product form, of course, but as a simplified chat simulation.

The team is also not small: several designers, many product managers, and two platforms — iOS and Android. I did not announce any official move to a new process. I ran the experiment more in stealth mode. That was intentional. First I wanted to understand whether this model worked at all before committing to anything.

The first attempt.
Failed. And that was useful

The first serious attempt ended badly. But that attempt gave me almost all of the important observations.

The first and most obvious problem — Figma is often faster. if you have three small edits in different places and you need the result in 10 minutes, Figma is almost always faster. This is especially noticeable before meetings, when you need to urgently fix something, move something around, or show several variations.

In practice, it looked very simple. For example, you are discussing a prototype with a product manager and want to freely move elements around, tweak them, swap them live during the conversation. Some things can be adjusted quickly through devtools, but far from everything. In the end, you hurriedly rebuild parts in Figma from screenshots of the prototype. It is awkward and slow. And obviously, in the middle of a discussion, nobody is going to write a prompt for an LLM and wait for it to carefully rework something.

The second problem is overview.
In Figma, you see screens side by side, quickly compare versions, stay on an in-between state, and show links between flows. In a coded prototype, everything is different: to understand what is implemented, where you can click, and what state the screen is in, you often have to literally “poke through” the interface. Flow transparency drops sharply.

The third problem is handoff.
When you give a developer a mockup, that is one communication model. When you give them a working app prototype, the model changes completely. You now also have to explain how to get to the right screen, how to reproduce the state, where the needed branch of the flow lives, and why it exists in the first place.

The fourth problem is versions and alternatives.
In Figma, you can easily place two, three, or four variants of the same flow side by side. In code, this is no longer “four frames.” It is almost four separate branches. Any cross-cutting change quickly turns into pain.

The fifth problem is data.
If you can put it all into one JSON file and load it into the prototype, it is still manageable. If not, you get generation, parsing, APIs, changing contracts, and constant maintenance of a temporary construction. As soon as the data is no longer a simple mock JSON, the prototype starts needing almost engineering-level support.

The sixth problem is the gap between web and native.
A PWA on a smartphone is still not a native app. For many tasks, that is good enough. For some, it is not. And building a real native prototype is harder and more expensive — both in terms of setup and team access. The simplest example is: “Can you please add haptics when the button is tapped?”

Finding 1.
The thinking process itself barely changed

This is important to say clearly, because there is too much confusion around “vibe coding.” Design thinking did not disappear. The need to think through scenarios, data, logic, states, and system behavior did not go away. All of that still has to be thought through in advance.

Yes, LLMs make it easier to discuss an idea, explore more hypotheses, build a rough version, and see it live. But if the logic of the solution is bad, a coded prototype will not save it. It will simply materialize a bad solution.

Finding 2.
A prototype needs an overview layer on top of it

The most important insight of the whole experiment was not about code generation and not about speed.

I realized that a coded prototype almost inevitably needs a second interface on top of the prototype itself. Some kind of overview layer — a separate canvas where you can see screens, states, versions, and entry points, and from which you can open the needed screen. Because a live interface by itself is bad for overview.

To solve this, I built a small service that takes a markdown file and turns it into a layout of screenshots. In other words, it is a canvas of versions and states. You can zoom it like in Figma, quickly switch between sets of screens, and open the real prototype by clicking on a screenshot.

For me, this was the turning point. At that moment, the coded prototype stopped being a black box and became a convenient discussion object again. A developer and a PM could see all the key states on a canvas, quickly open the needed scenario, compare versions, and understand what exactly they were being shown.

In other words, I came to a strange but logical conclusion: if a coded prototype really wants to compete with Figma as a communication environment, it needs its own Figma-like overview layer.

Finding 3.
For prototypes copy-per-use is useful

Another important thing became clear at the infrastructure level.

At first I thought about the usual ways of organizing variants: flags, branches, some more “correct” architecture. But very quickly it became obvious that this is inconvenient for a prototype. Flags spread across dozens of places and start affecting each other in hidden ways. Branches are more reliable, but too heavy for use, comparison, and deployment.

In the end, I came to an approach that would look like a bad idea for production, but turned out to be almost perfect for prototyping: copy-per-use. That means a separate copy for each specific experiment, without trying to build an ideal architecture too early. A separate folder for every scenario or group of scenarios, with all changes for that experiment inside it. Yes, the number of files grows. Yes, there is duplication. But experiments become fully isolated, do not break each other, and do not infect the main structure.

For prototyping, this turned out to be much more practical than trying to build a “clean” engineering system too early.

Finding 4.
Code prototypes most useful for UX research

Interesting things happened exactly where the product itself does not fit well into a static mockup.

For research, it is sometimes important that a user types a real question and gets an answer page in return. The problem is that the same intent can be phrased in ten different ways. In static screens, this quickly becomes fake: either you hardcode a very narrow scenario, or you show a generic placeholder that does not really test much.

Here a classifier helped me. It mapped differently worded user queries to the right prebuilt page, even when the answer itself was still hardcoded. Because of that, it became possible to run quantitative research for prototypes of non-deterministic systems without the whole thing feeling completely fake. Even though it was still a bit fake, because the returned page was static 🫠

There was another useful case too — onboarding testing. When a user selected several interests, the chat automatically generated relevant follow-up suggestions. I did not have to hardcode those manually for every possible set of interests. It already felt much closer to a real product than a normal static scenario. And for both research and stakeholder discussion, this kind of prototype worked noticeably better.

These were the moments when I started to understand why I was doing all of this in the first place. Not to “draw in code,” but to test UX where the UX actually lives in system behavior, not in one frozen screen.

Second attempt.
More successful. But there are still a lot of things to care about

Once the first wave of infrastructure problems was partly solved, more fundamental things appeared.

First, not everyone on the team needs a coded prototype at all.
Sometimes a product manager does not need an “almost live interface.” They need a familiar mockup that can be opened quickly, reviewed, and discussed in the usual way. This is also true for part of engineering.

Second, if the design team does not agree on one working model, the value of this approach drops fast.
Because supporting both code and Figma at the same time is just dumb double work. And there is still no reliable bridge between the two worlds.

Third, speed becomes an issue again.
Some bigger things in code really can produce a stronger and more mature artifact. But quick small edits, sudden “show it one more way” requests, and dozens of micro-variants still live much more naturally in Figma.

Fourth, the design system becomes critical.
Not in the sense of “you need a set of buttons,” but in the sense of a component library, understandable documentation, and a proper way to reuse things. Otherwise every new screen starts being assembled almost from scratch again. In my case, the problem was not the lack of a design system as such. The problem was that the existing one was heavy, full of legacy, and poorly prepared for agent-based assembly.

And finally, after some time, you stop remembering which components, flows, and screens even exist inside your prototype. That means you need at least a simple component showcase. And after that, probably something more systematic. So the prototype itself starts demanding its own mini-infrastructure. On the other hand, that infrastructure may turn out to be much more flexible and adaptable than Figma.

Conclusion 1.
Code is better for behavior-heavy tasks, not just screens

A coded prototype works better in tasks where the main thing is behavior, not visual layout alone. It is more useful when you need to show logic, navigation, transitions, data handling, complex states, real delays, AI interface dynamics, and scenarios. In these cases, it helps discuss not only how the interface looks, but how it actually works and feels.

In some situations, it can also be faster in practice. For example, when building a large set of screens, flows, states, tables, diagrams, and components for a major sports event, code made it possible to assemble a clickable and scrollable artifact in two or three days. In Figma, creating the same amount of realistic mockups with data would likely have taken more time.

Conclusion 2.
Figma is better for quick iteration and team routine

Figma is still stronger when the task is about speed, simplicity, and existing team workflow. It is better for small fixes, quick exploration, comparing several options side by side, leaving comments on a canvas, showing intermediate states, and syncing fast with a team that already works in that environment.

If designers and engineers are clearly separated by role, if the coded prototype is not reused later, and if stakeholders do not need that level of realism, then code will most likely just slow the work down. In those cases, the overhead is simply not worth it.

Conclusion 3.
It’s a separate mode of work, not a replacement for Figma

A coded prototype should not be treated as a universal replacement for Figma. The experiment did not prove that code is simply faster, and at early stages it often does the opposite, especially when there is no agreed process and no shared understanding of why this artifact is needed.

Its main value is not that the designer now “draws faster,” but that it produces a different kind of artifact, one that can be more honest and useful for certain UX problems.

So for me, code-based prototyping is not a new default. It is a separate working mode for a specific class of tasks, mainly where static screens fail to communicate the essence of the product. Without that understanding, it quickly turns into an expensive technical exercise.

What happens next

I do not think big teams will move from Figma to pure code any time soon without intermediate models. Too many processes depend on overview, collaboration, and a low entry barrier.

But I can absolutely believe in another scenario: a team has a shared prototyping layer connected to the component base, people have personal sandboxes for experiments, and on top of all of that there is a convenient overview interface that brings back the transparency people are used to in Figma.

This experiment was useful to me for exactly that reason. It did not prove that Figma is no longer needed. It showed where a coded prototype is truly stronger, and where the talk about “we do everything directly in code now” is still far from reality.

Appendix.
What the process looks like

Of course, a new tool changed the design process. The flow ended up looking roughly like this:

1. A task comes in.
2. Discussion with the product manager to clarify all details.
3. Research, task analysis, and solution design. Understanding the needed data, components, screen structure, and flow. Whether this is done with sketches, in Figma, or just by collecting screenshots is not that important. The main thing is to reach clarity. Reworking things is usually longer and harder, even with AI (or especially with AI).
4. Collecting, parsing, or generating the data needed for the first version of the task: images, headlines, texts, metadata, data for charts or tables, and so on. You can improve the data later, but you need a basic foundation first, so you can build components against some contract.
5. Writing prompts for new components or component variations needed to assemble the screens.
6. Building the components. In this process I actively use the Figma MCP server to get higher quality implementation, if the components were originally designed in Figma. If not, you can try building from screenshots or sketches. Or describe the elements, sizes, and rough spacing in text and then adjust everything in devtools.
7. Assembling screens and flow navigation. This is the final stage, where we build screens almost like from a constructor and connect data.
8. My personal extra step: assembling flow from screenshots, so different screen states can be shown more clearly through the service I built.
9. Discussion → research → next iteration.

So the thinking stage did not disappear. But the final artifact became closer to the product.

But there is a problem with principles. People often understand them in a vague way and replace them with slogans that sound nice but work badly in real discussions.

This is a short reminder of what a principle means in practice.

Principles are not a set of nice phrases about all the good things. They are not about choosing between good and bad.

If you are choosing between good and bad, that is not a principle. That is basic common sense. “Do good quality work,” “care about the user,” “do not make nonsense,” “aim for the best” — these are not principles. This is pop management language that costs nothing and helps with nothing in a real argument.

A principle starts where two good options collide. Not good and bad, but good and good. Or at least acceptable and acceptable. For example, speed or quality, consistency or local exceptions, simplicity or flexibility, one shared approach or freedom.

If you are choosing between good and bad, that is not a principle. That is basic common sense. A principle starts where two good options collide.

This is where the real conversation starts. Because now the choice has a cost: you choose one thing and cut off the other. That is why a principle is not a slogan. It is a fixed limitation that helps reduce chaos.

A principle written in a populist way is useless exactly where it is needed most. It does not help when both sides are right in their own way and both have real arguments. It does not reduce discussion and it does not make the decision easier. It only creates the feeling that the team has clarity.

That is why a real principle should almost always sound a bit uncomfortable. You should feel the tradeoff. The limit. The tilt. The cost.

Not “we choose quality,” but “in the current market we more often choose speed over perfectionism, because being late hurts us more than shipping something imperfect.” Not “we value flexibility,” but “we are ready to lose some consistency to get faster local decisions.” Not “we love simplicity,” but “we would rather leave out rare scenarios than make the main experience harder for everyone.”

That is already a principle. Someone will clearly be unhappy with it. And if nobody can feel any discomfort from your wording, then most likely you did not write a principle. You wrote safe nonsense.

Another uncomfortable truth: do not create principles where there is no friction. If there is no disagreement on an issue, then there is no need for a principle. Do not turn everything in advance into “our approach,” “our philosophy,” or “our decision culture.” That is just filling the space with words.

A principle makes sense when the same discussion happens for at least the second time. Because at that point the team is again spending energy not on solving the problem, but on repeating the same argument about the rules behind the decision.

A principle is not a law of nature and not the truth. It is a chosen tilt. It exists not to be objectively right, but to make repeated crossroads cheaper to pass.

A principle is not “we are for all good things.” It is a choice about which of two normal options we will cut more often so we do not have to go through the same fork in the road again and again. If that is not present in the wording, then it is most likely not a principle. It is noise.

We throw around terms like revenue, metrics, data-driven, PLG, quality, vision, mission. But in reality, Care is the essence of our work. We strive to take care of people, and in return, we receive their gratitude. In that order.

I often think about beauty, aesthetics, and functionality, about their balance. Care transcends both beauty and functionality. It is a deep human motivation that gives birth to both function as a desire to help, and beauty as a desire to inspire or make human experience enjoyable.

A person who truly cares is like a hospitable host: they welcome, nourish, sustain, and delight their guests. They do everything to make them feel comfortable, warm, and cherished. In this way, they forge and maintain an important connection with these people, showing how truly valued they are.

Transferring this idea to business, we can say that our work is aimed at the same thing. We meet people, help them, reduce their anxiety and doubts, improve their lives, and in return receive sincere gratitude for this experience. This is the main ethical path.

It seems to me that a lot could change if, when working on any project, we first asked ourselves questions not about metrics and money, but looked at it from a different position:

Is there care for the person who will interact with this?

Are we really caring now, or are we just solving someone's technical problem?

Will the person feel that someone cared about him, or will he feel manipulation and indifference?

How much sincere care have we brought to people this month?

How to make this project with care?

Of course, it may sound naive, like, business is not done that way. My opinion is different. A company will be in constant "survival mode" if its only value is the benefit it brings. Because benefit is a function, it is easy to copy. Even if it is a breakthrough technology, there will always be someone who will do the same, but perhaps cheaper or with more resources.

However, a business flourishes and gains loyal followers when its main value becomes Сare. Yes, you can and should still monitor profitability, conversion, and retention, it is just that the main key to decision-making becomes the thought of care. Then metrics will cease to dominate, and will take their modest and logical position as ordinary indicators of how successfully your care resonates with people and helps your business.

I'll approach this question from two angles. First, I believe that design is a form of art. This includes product design, interactive design, motion design, graphic design, and so on. Second, I am confident that art does solve problems. And it does so no less effectively than design.

When we contrast one with the other, we diminish both concepts. Design loses its depth of meaning and emotional resonance. Art loses its real practical impact. I want to show that this separation is a false dichotomy. It has no solid foundation.

Thesis 1
In art, the artist sets their task, while in design, someone else does

One common argument goes like this: in art, the artist formulates the task themselves, but in design, it's set by someone else. From this, they conclude that design is a mere craft that serves others, while art is free self-expression. But this is a rather weak distinction.

A designer can be an independent author and create a product based on their vision, without considering the market or audience. Or they can consciously abandon broad universality and create something for a narrow group of people. Conversely, try to appeal to everyone at once. This isn't a mistake, but a conscious strategy. Many indie designers work this way, creating utilities, apps, and websites for a community of like-minded individuals. And in this, they are no different from an artist who paints in their style and finds people who appreciate that style and are willing to pay for it.

Conversely, an artist can work based on a brief, paint portraits, illustrations, design books, or posters. This doesn't make them any less of an artist. What's important is not who sets the task, but how the person approaches it. How much effort is put into expressing something more than just meeting technical requirements. How much a personal perspective, a sense of form, time, and emotion can be felt in it.

Thesis 2
Art does not solve problems

Let's forget about the logic of conversions and retention for a moment and ask a simple question: why do people continue to create art, buy it, go to museums, hang paintings on walls, write music, and make films? The answer is simple: because it responds to specific internal and external needs. It solves problems: aesthetic, emotional, cultural, and social.

Art helps cope with anxiety, loneliness, gives a sense of beauty and meaning. It shapes perception, evokes feelings, raises important topics — from personal to political. It can point to a problem more accurately than analytics, faster than news, deeper than statistics. There are countless examples: Picasso's "Guernica," the works of Ai Weiwei, Rodchenko's posters, photographs from the Vietnam War. This is not just aesthetics. This is work aimed at specific goals: to attract attention, express protest, change opinion, create an effect.

Incidentally, the same can be said about design. Many techniques we currently use in UI and UX came from art. The Bauhaus in the 20th century blurred the line between artist and engineer, and we continue along this path. A designer creates not just an interface, but also meaning and form. Their work influences the user's thinking, behavior, and mood. This is the connection with art, just with different tools and on a different scale.

Thesis 3
Art is about self-expression, while design is about the user

This argument is also heard often, but it's false. Of course, there are works created by artists only for themselves, "for the drawer," without considering the audience. But in most cases, art is directed at the viewer. It expects a dialogue. It wants to evoke an emotion, a reaction, a thought. Sometimes even provocation.

At the same time, design can also be subjective, authorial, not obligated to please everyone. If you go beyond purely applied design, you'll find that a large amount of design work is not done for the user. It's created for oneself, for research, for experiments.

By the way, I often recommend myself, when working on a task, to first imagine how I would want to solve it for myself. Without considering the brief. Without accounting for the "average user." This is something between curiosity and the egoism of self-expression. But that's where the power lies. It is precisely this approach that often gives birth to unique, vibrant solutions in which the author's personality is revealed.

Thesis 4
Art is timeless, while design becomes outdated

Sometimes people say that art is "for the ages," while design exists within the framework of trends, technologies, and the tasks of its time. This argument easily falls apart when we look at what is currently called art, and how many real products created with both functional and aesthetic value have turned into art. This includes classic typefaces, Bauhaus objects, Scandinavian chairs, and much more.

At the same time, a vast amount of art "dies" within the context of its era. A colossal number of artworks have been created in the last 100 years. However, we still remember and consider truly valuable only a small portion of them. I am sure that if you calculate it, this proportion is no more than 1% of all works that could claim "timelessness."

Conversely, many works of art intentionally engage with the current context, as a reaction to the here and now, as an attempt to draw attention to a social problem. Take the works of performance artists, for example. Of course, we will remember their actions, but as a historical fact, not as an act of art that we could observe in its original context.

Thesis 5
Art has no metrics, design does

This argument sounds like, "design can be measured, but art cannot, so they are fundamentally different." Let's be honest. Scientists still don't fully understand how the human brain works. Scientists still don't understand how and why certain decisions are made. Until we decipher how the brain works, many things in design cannot be measured: emotions, the "wow" effect, style, memorability, associations.

We can only measure the consequences of this influence in the form of conversions or other business metrics. But we cannot measure the influence itself, or why it has a certain effect, or whether it affects everyone the same way or differently.

It's the same with art. Many metrics assess the popularity or importance of an object after the fact: criticism, reaction, value, market, popularity. Especially in the modern world with likes, comments, auction values, and price lists for paintings on Wikipedia. Many things can be measured. But all these assessments are given as a societal reaction to art, not as an assessment of the influence of art on each viewer individually.

Thesis 6
Art creates value in itself, while design creates it through function

This thesis largely overlaps with Thesis 2. Here too, it all boils down to what we consider valuable.

In my opinion, value can take different forms. A thoughtful and meaningful film can change a person's life and views. Kind, well-chosen words can ease emotional suffering. A magnificent painting can carry aesthetic value. And well-executed design can carry both aesthetic and functional value.

Sometimes the aesthetic value of a design object is so great that we want to have it in our home solely because of that, not because of its functional part. At the same time, functional but soulless things bring us no pleasure.

It is said that in design, only solutions that can be tested and proven work. But practical experience shows that everything that truly has an impact doesn't always fit neatly into a funnel. An emotional interface is perceived as more convenient. Aesthetics build trust. Form is not decoration; it is the language through which a product speaks to a person. If design starts to lose its artistic quality, this language is also lost. Design becomes dead, grey, flat. It becomes just a utility. And nobody loves utilities; they are merely used.

Thesis 7
Design is about business

This is a trend. In some companies and teams, design, especially product UI/UX design, has indeed started to serve one purpose: to extract as much money as possible from users, including by using any available manipulations bordering on dark patterns. The very concepts of dark patterns are also becoming increasingly blurred.

I recently asked a colleague, a product manager, how many story points he would be willing to spend to achieve beauty. He replied — zero. Do we agree to such a future for design?

When we try to "sit at the table with business," we sacrifice emotionality, aesthetics, feelings. We are essentially saying, "Look, look! We — designers — are just like you! We are like the CEO, CPO, CTO, CMO, CRO, CFO! We are calculating, pragmatic, cold! We are about metrics, business, and money! We disregard beauty if it brings more cash! We ignore the user if the metrics go up!"

This looks pathetic. And it's a trap. The designer's strength lies precisely in being different, not in being similar. In empathy. In the ability to create something unique, convenient, expressive, emotional. Something that is not visible on charts but is felt. The strength lies in the ability to create balance within the team, to balance the corporate race for money with something more humanistic.

In fact, this last thesis, if allowed to develop, is truly capable of destroying design as a form of art. It can turn it into a dry set of psychological manipulations aimed at achieving business goals: FOMO, Scarcity, Hidden Costs, Confirmshaming, and even Social Proof, which has become quite innocent over the years.

People get tired of such design; they lose their receptiveness to it. In response to this fatigue, design becomes increasingly pushy, aggressive, and refined each year. Notification bells ring and shake more and more fiercely. Boxes and chests with "gifts" are thrust upon people more aggressively. We are increasingly moving away from being user advocates and creating aesthetic functionality.

Yes, I know I sound naive. I have been working as a product UI/UX designer for the last 14 years, and I understand everything. My last project was about nudging people towards a choice using Social Proof. This project helped business metrics. Yay.

Design is Art

Nevertheless, to summarize everything that has been said, I believe that art and design should not be contrasted. They should not be pushed to opposite poles. They are one and the same force of creative vision. We solve different problems, but the essence of these problems is the same. We are trying to respond meaningfully and beautifully to the challenge of society, the market, the inner world, or the technical environment. In this sense, design is art, albeit more utilitarian, more applied, and more scalable.

I think our task as designers is to remember this. Not to lose our artistic essence. Not to be afraid to say that we are also artists, that we create meaning, the beauty of forms, and emotions, that we have a voice. That we have the ability not just to "fix scenarios," but also to propose something new, expressive, and have an emotional impact. To be authors. Because as soon as we agree to the role of applied craftsmen, we lose a part of what makes it worth doing.

In 2017 she wrote the book "Design Systems". This book is often referenced as a practical source of information on organizing work around a design system. Eight years have passed, but the book is still very relevant. Below, I provide a summary of the chapters, which I hope will help you form a general impression.

The book mainly targets small teams, though it often mentions Airbnb. At that time, Airbnb had more than 60 designers, which is hardly a small team. Still, the foundations described in the book are exactly what a small, starting team needs to lay the groundwork for a design system without making too many mistakes.

The book is divided into two parts. Foundations mostly cover the theory of design systems and their guiding principles. The process focuses on how to start creating the system and organize processes around it.

Chapter 1
Design systems

In this chapter, the author defines a design system as a collection of interconnected patterns and shared practices organized to serve a product. Patterns are the recurring elements that make up the interface. Practices are how we create, use those patterns, and organize teamwork.

A product’s domain influences the functional side of patterns. For example, a trading app needs charts, data visualization, various inputs, and tables. A course website needs articles, videos, progress indicators, etc.

A product’s brand language mostly influences the visual side of patterns. It forms the basis for what are called perceptual patterns: colors, typography, and so on.

These patterns together create the interface design language. To keep the language consistent, it’s important to document the patterns, explain them, and share them with the entire team – or even involve the whole team in that work. This depends on how the design system is organized.

Language is fundamental for collaboration. Every team member needs a clear understanding of each pattern, how and why it’s used, and why it was created that way. The more effectively this knowledge is shared, the higher the chance that patterns will be used correctly. Of course, the user also needs to understand the patterns well.

An effective design system reduces the cost of design and development while meeting user needs and achieving product goals. However, it has limits. A design system can’t fix poor design or poor UX/UI.

Chapter 2
Design Principles

The basis of any working system is its principles. They express the value and purpose of the product.

Qualities of good principles include:

1. Authenticity. Principles shouldn’t be too generic or vague – they need to be specific and applicable. For example, instead of “Simple,” try “Timeless.”
2. They’re practical and actionable. They should guide and direct decisions. “Make it simple” is too broad, but “No needless parts” is clearer. Think of advising on how to do things.
3. They have a point of view. Although design principles shouldn’t apply to every situation, they can help in complex or ambiguous scenarios.
4. They’re relatable and memorable. Having 3–5 principles works best.

To define principles, start with the product’s purpose. One good exercise is asking team members to propose principles and then looking for common themes. Focus on principles for your team and related groups. Keep developing principles and using them in your work. If they’re not applicable, iterate again. Principles may need adjusting as you implement them.

One of the hardest things is applying principles to UI/UX in practice. Use your principles when choosing a direction or making tough decisions. For instance, if you have 10 different options for a text editor or any other pattern, ask yourself which best reflects your design principles and why.

Chapter 3
Functional patterns

Functional patterns are the building blocks of the interface: buttons, banners, pop-ups, and so on. The product type and its needs can affect which patterns are necessary. Patterns evolve over a product’s lifetime, but their behavior and purpose usually remain the same.

Often in a product’s early stages, patterns aren’t defined, named, or shared within the team. This leads to recreating the same patterns many times. Over time, you need to organize these patterns. To do this:

1. Create a map of patterns grouped by their shared meaning. For example, group them by the user’s steps.
2. Audit your interface and gather all variations of the same element in one place. Ideally, do this regularly as the product grows.
3. Pick the necessary set of patterns and remove duplicates. Name the patterns based on their purpose, not just their appearance. For example, “Billboard” suggests a more action-focused, promotional role than a modest name like “Course Banner.”

Break down each pattern into its parts: text, graphics, etc. This helps combine several elements into one pattern. For example, if you have a few patterns in different sizes or shapes but with the same elements, it might be worth merging them into one component with size variations. It’s also a good way to clarify a pattern’s essence and confirm it with the team.

Sometimes you have to design a pattern that includes content (text or images) but you don’t have that real content yet. In this case, you can create it while imagining possible content. (However, it’s better to set content boundaries in advance and agree on them with the team.)

Chapter 4
Perceptual patterns

Perceptual patterns include typography, iconography, color, shape, spacing, grid, animation, tone of voice, etc. These patterns communicate the brand both on their own and in how they work together. If functional patterns reflect what people want or need, perceptual patterns reflect how they feel.

There are a few ways to explore these patterns: Mood boards, Style tiles, and Element collages (which are basically a variation of style tiles).

It’s important to find a balance between conformity and exceptions in brand perception. Too many exceptions weaken the brand. But if there are too few, things can feel too uniform and rigid.

When you’re fully focused on consistency, some of the important subtleties of what makes a product feel a certain way can be lost. Lucy Blackwell, creative director at FutureLearn

When you add new elements to the design, especially if business requirements demand them, always check if those elements reflect the brand. The more often an element is used, the more it either supports or weakens the brand.

Chapter 5
Shared language

Building a consistent, unified design system requires a shared language everyone on the team uses and understands.

First, accept that naming design system components is important. The easier they are to remember and the more inspiring they are for new ideas, the more reusable the pattern will be.

The name shouldn’t only describe what the object looks like but also its purpose. Good names often use metaphors and have their own identity. Examples might be “Brackets,” “Spotlight,” “Minions,” or “Boss-button.”

It’s best to name components together. You can create a separate chat and invite your coworkers and users for naming discussions.

Naming components isn’t enough to make the design system a daily tool for everyone. You need to immerse the entire team in all kinds of ways. For instance, you could create a special area in the office with all the styles printed out. You can also make posters or cards for each pattern.

Use the names of design system elements all the time, even if it feels awkward at first.

It’s good when learning about the design system is part of onboarding new team members. Regular meetings about the design system are also helpful. You can discuss changes, new components, and modules at these meetings.

Create and maintain your glossary of terms. This is valuable not just for explaining words to everyone on the team, but also for reinforcing a culture where words and shared language matter.

Part II

Chapter 6
Parameters of your system

Three main parameters define how a company manages a design system:

1. Rules: strict or flexible
2. Design system parts: modular or integrated
3. Organization of the work: centralized or distributed

These parameters are not binary. Each company can be somewhere in between. Below are descriptions of the extremes for each scale.

Rules

1. They can be strict, documented, and clearly described. Everyone must follow them at all times. Any exceptions are examined closely to confirm if they are needed.
2. On the other side, they can be flexible, leaving room for improvisation. In this case, rules are more like principles rather than strict guidelines.

Elements of the system

1. They can be modular. In this situation, the system is broken into small pieces that are used to build other pieces and so on. Everything is carefully adjusted and constantly reused. This approach is typical for standard digital products and apps.

2. Or they can be integrated. In this case, the chunks are larger and reused less often. The structure is less flexible. The main consistency might be the color palette, typography, and other basic elements. This format is more common in promo products and landing pages.

Organization

1. Centralized, where designated people are responsible for the design system. This format is more common for large design teams, where designers work in different areas and do not always interact closely.

2. Distributed, where everyone on the team is partially responsible for the design system and its growth.

As mentioned before, these parameters are not binary. Each team can find the balance that works best for them.

(For example, a small team might have a distributed format. Each team member contributes to the design system independently. However, one or two people might pay closer attention to consistency and focus on developing the system.)

Chapter 7
Planning and practicalities

A design system cannot be built by a few people without dedicated resources. To get resources assigned, you need to show the business how it will be useful. There are several ways to do this, but all involve showing clear, measurable value in business terms.

1. Saving time on designing and developing modules. Reusing design system elements pays off over the long term. The larger the team, the more beneficial it becomes.
2. Saving time on large-scale product changes. Without a design system, any complex change becomes a huge task. Many hidden bugs show up, and the team gets bogged down in testing and fixes. With a design system, such changes appear everywhere automatically if a component is used in multiple places. (Of course, this can still cause issues, but much less often.)
3. Faster product launches. Having a library of patterns can let you build new pages up to 10–20 times faster.

If your enterprise has 25 teams each making buttons, then it costs your enterprise $1,000,000 to have good buttons. Nathan Curtis

Besides these, there are less tangible but strategically important benefits: brand consistency, unified pattern use, collaboration, and teamwork.

Where to start when you have resources

1. Agree on your goals. Start by systematizing the interface. This includes defining design principles, identifying patterns, and building a pattern library. Also, think about how to maintain the library. You’ll likely need to refactor code and front-end architecture.
2. At the same time, set up processes. How will you share information with the team? Promote the pattern library and the shared design language within the team and encourage their use. Make sure onboarding includes an introduction to the design system.
3. Make the system’s progress visible to the entire team.
4. Create a culture of knowledge sharing. You can do this through dedicated Slack channels, newsletters, regular syncs, or workshops.

Chapter 8
Systemizing Functional Patterns

Systemizing starts with an audit of the patterns that exist in your product. You can do this in different ways, but the author suggests grouping them by their purpose.

It’s better to do an audit when the interface won’t change drastically shortly and there are no obvious UX problems. Such issues can interfere and distract.

To begin, identify your main screens. Then list the elements on those screens and group them by the function they serve. Keep the level of detail roughly the same for each. From these groups, you can pick out patterns. Some things can be combined into one pattern; others can be standardized into a single style.

Name the patterns. When choosing names, think about whether a pattern will be reused in different contexts. For example, “Button” is used everywhere, many times. However, a content card for a book, movie, or exhibit is a more specific component. The more often a pattern is reused, the more general its name can be. The more specific it is, the more the name should hint at its uniqueness.

The content structure of a pattern is the set of items it contains — text, images, labels, tags, and so on. Several patterns with a similar structure can be turned into a single component with variations. By looking at this structure, you can decide if a pattern should exist as a separate part of the system or not.

During this process, you need to keep deciding which patterns serve which tasks. You also need to decide how many variations each component can or should have. This is a team effort that sets important differences and usage rules for the system.

Chapter 9
Systemizing perceptual patterns

Perceptual patterns, as the author calls them, include colors, typography, spacings, corner radiuses, tone of voice (TOV), iconography, illustrations, photos, and sounds. All these elements shape how users perceive the brand in the product. They are the foundation on which all components are built.

The most effective systems match the team’s core design principles – for example, “timeless, not cutting-edge.” A good exercise is to think about how a pattern aligns with your chosen principles.

For each perceptual pattern, start with its purpose. Collect and group usage examples. Then identify patterns and write guidelines. The approach is the same as with functional patterns.

Example: Color palette. Start by seeing how colors are used in your product. Break them into logical categories: buttons, links, text, backgrounds, and dividers. After that, define the main patterns for using color. Remove shades that have no real meaning. Check colors for accessibility. In the end, write guidelines for using color in the interface.

Example: Animations. Do the same by auditing all animations in the product. Make a table of screenshots, animation types, timings, and motion settings. Then define the patterns for different uses – timings, animation types — and document them in guidelines.

Example: Tone of Voice. TOV is how the product talks to the user every step of the way. Again, start with an audit. Gather important text from the interface and determine the communication patterns that match your brand. Then describe principles and guidelines for writing text. It’s a great idea to include lots of real text examples for different situations.

Chapter 10
Pattern Libraries

As already mentioned, a pattern library is not the design system itself but a way of documenting patterns. Still, it’s a crucial part of the system. In this chapter, the author looks at different ways to organize a pattern library.

Content. Focus on the content. Gather an MVP version of your design system and its documentation as soon as possible. If collecting the entire system at once takes too long, start with screenshots and gradually build components from there.

Organizing patterns. At first, how you group and organize your library is not that important because you will likely change it later. You just need to agree on a basic approach. Some common methods are:

1. Abstracting Perceptual Patterns. Separating functional patterns (components) from styles is a common approach in many design systems.
2. There are also a few ways to organize functional patterns. The simplest is alphabetical order. A slightly more complex option is by purpose — for example, forms, promo elements, cards, controls, etc. Another option is a hierarchical approach. A classic structure breaks system elements down by complexity: Atoms — styles; Molecules — basic components; Organisms — large components made of molecules; Templates — layouts for interface blocks or even complete pages made of organisms and molecules.

Documenting patterns and styles. Keep it simple to start: the component or style name, its purpose, an example, and variations. Later on, you might add versioning, contributors, related components, dos and don’ts, components parts, and so on. Many existing design systems can give you ideas for documenting components.

Workflow. Here are a few points to consider:

1. Set up a process for adding new patterns and define criteria for adding them. One example of a criterion might be reuse: a pattern is added only when it’s reused a second or third time. Of course, you can also consider potential reuse. The key is to keep the process balanced.
2. Decide who is responsible for the design system. In a distributed team, you need a process so that incoming changes don’t lead to inconsistency. With a dedicated team, there are usually curator and producer roles who share responsibility for decision-making.
3. Keep the design library and codebase for the design system aligned. Ideally, they should be as synchronized as possible, including their content and naming.
4. Make sure all elements, documentation, and master design files stay up to date.
5. The component library should be the single source of truth for everyone — developers, designers, QA, and product managers.

In the context of this article, by "vision," I mean how the product should work, look, and bring value in the long run. This is not about business strategy but about understanding how that strategy translates into the product itself.

Building a product without a vision is like constructing a house without knowing what it should look like in the end or endlessly rearranging furniture in an apartment without a clear idea of the overall interior design.

Metrics are numbers that reflect how users behave within the product. They are important, but they have limitations.

First, user behavior is not always easy to explain and is often subject to misinterpretation. Teams tend to come up with rational explanations for any change, even when the real reasons might be completely different. Here are two completely opposite conclusions that could be drawn from the same fact:

• We made the video larger → users got stuck watching it, which caused button clicks to drop.
• We made the video larger → users understood the content better, which led to an increase in button clicks.

Which one is correct? Maybe both? Maybe neither? That’s the problem.

Second, metrics are not the most reliable tool in the short term (up to six months). In most products, experiment results are evaluated around 14 days after launch. Unfortunately, such short time frames often lead to situations where a follow-up experiment in 3–6 months shows that the initial effect has either disappeared or even reversed.

Shopify has found that 30% to 40% of experiments that show positive short-term results have no long-term impact. Initial lifts can be misleading, and some of your “losers” might actually yield unexpected long-term value. Lenny’s Podcast, Archie Abrams (VP Product, Head of Growth at Shopify)

And here’s the problem. A vision is rarely implemented all at once; it usually happens step by step. In this case, if you only focus on numbers, the first step might look like a "failure" without the second. The team gets stuck in endless discussions and analysis, and in the end, the business decides that the idea doesn’t work, causing the entire concept to collapse.

An obsession with metrics leads companies to fear temporary dips. This is especially true if your time-to-market is long, but you’re still operating under the pressure of quarterly reports to investors, where any drop in numbers is seen as a disaster.

In response, product teams come up with hacks. One of the funniest things I’ve seen is when a complex experiment that initially showed a statistically significant negative result is split into three smaller steps, each of which is "gray"—meaning not statistically significant. Since none of them alone show a clear negative impact, the experiment is considered acceptable. Voilà! The team still implements the change they wanted, but without an "official" failure—although they’ve now spent three times as much time on it.

Vision is more than just metrics. Implementing a vision should create new opportunities and growth points, and that’s a good thing — even if metrics temporarily decline. Metrics are there to ensure you’re not making a catastrophic mistake, but if they fluctuate by ±2–5%, that’s normal. Newness, habit changes, and user adaptation — there could be many reasons for small shifts.

Ideally, a vision should be launched as a complete update rather than in small pieces. That’s how companies like Airbnb, Figma, or Sketch do it — releasing updates once a quarter or every six months. This helps avoid pointless analysis of intermediate metrics and saves teams from stressing over every number.

At the end of the day, metrics are a tool, not a goal. A product doesn’t thrive on numbers — it thrives on how it improves users’ lives.

Additional links

Lenny’s Podcast. Archie Abrams, VP Product, Head of Growth at Shopify

Companies should step off the quarterly report treadmill. Nicolai Tangen

Airbnb 2024 Winter Release

Karri Saarinen’s 10 rules for crafting products that stand out

How Many People Do You Need to See Trip on Your Carpet Before Fixing It?
Jim Lewis, PhD and Jeff Sauro, PhD

In general, this article is about how to make decisions about eliminating problems based on research, and it emphasizes that even knowing about a problem—without direct research evidence—is already a reason to fix it. However, it also made me think a bit differently.

From time to time in my work, I come across debates about the effectiveness and reliability of UX research. The main argument is that it’s impossible to interview just five people and then draw reliable mathematical conclusions about existing issues, so why waste time on UX research?

UX researchers bear some responsibility here because they often avoid numbers and forecasts. They even write in their recommendations, “Don’t say how many respondents experienced the problem,” since everything gets complicated by the purity of the experiment, sampling, and so on. You can understand their caution, but it doesn’t always foster trust.

That’s why it’s important to remind ourselves and others, from time to time, that any research result comes with its confidence interval and is mathematically supported.

For example, if a study shows two problem triggers in a sample of just five people, then the confidence interval, according to the Clopper-Pearson method (with 95% confidence), ranges from 5.27% to 85.34%. In other words, if we extend the study to the entire audience for which this sample is relevant, with a 95% probability at least 5.27% of users will encounter the problem.

Have you ever seen a business dismiss issues affecting 5% of its core audience? It’s hard to imagine, yet I’ve seen exactly this kind of attitude toward research in conference rooms. If you ever run into the same thing, send them this article.

Balancing Text In CSS
Ahmad Shadeed

This article covers an important improvement in CSS that allows you to balance lines of text when they wrap.

First of all, I can’t help but say how much I admire the people who put together such in-depth articles, complete with interactive examples and all kinds of different content blocks. On top of that, they do it regularly and with impressive consistency.

As for the article itself, from a designer’s perspective, I’m really looking forward to text-wrap: pretty moving from “Limited availability” to “Baseline” so we can finally use it by default in all projects and basic settings.

I’d only recommend using text-wrap: balance if you have a clear reason to do so because the breaks it introduces often look worse than those slightly odd hyphenations.

The rise of the generalist
Carly Ayres

The main idea of the article is that the rise of AI will increasingly lead to the emergence of generalists across different professions. One of the first signs of this trend is the appearance of so-called “Design Engineers.”

I completely agree with the article’s message. In fact, I notice these same shifts in myself, moving right toward that well-known “design engineering.” And I have three main points on this topic.

First. The product trio will fall. If I’m a product designer with plenty of experience who’s gained developer skills through AI, the purpose of product management also starts to blur for me. I can build the strategy, come up with the design, create working prototypes, present them, groom with the development team, oversee implementation, and evaluate the results—all on my own.

Second. We’ve come full circle back to engineer-inventors. In the past, these were the people who did the entire process: drawing up blueprints, building prototypes of their inventions, and launching them into production. Later, as technology got more complex and economic processes sped up, this profession broke down into specialized parts. The product trio is one such piece. Now AI is bringing it all back together. The future of indie hacking and one-person companies is already here.

Third. Inside modern ultra-capitalist companies that focus on efficiency, I don’t see a bright future for these people. These new engineers will end up doing the work of three, yet still receive the same salary plus maybe a small 10–20% bonus. The problem is that even with AI, our brains have limitations, and switching contexts isn’t easy. I predict a push to learn new skills just to stay “in the market,” which in turn will lead to more burnout, depression, and rough transitions between professions.

Design artifacts
Robin Rendle

I see two main ideas in the article:

Create design artifacts only when they help move the design forward and support decision-making.

Producing artifacts that nobody cares about—just out of habit or because of some process—is pointless.

I fully agree with the first point. It reflects the classic understanding of any research: the goal is to influence a decision. If we already know that, no matter the result, it won’t have an impact, then the research itself is pointless.

The second point isn’t so straightforward. You can’t always predict what effect these artifacts might have. Every task is unique. Sometimes, the outcome ends up being useful, even if it’s not obvious at first. Moreover, an artifact might be underestimated not because it’s weak, but because the company’s decision-making process is broken.

So here’s how I’d put it: If your artifacts aren’t getting the attention they deserve but you have the resources, the interest, and the belief in their importance, don’t stop creating them. Keep presenting them to colleagues and stakeholders every time. Gradually, you can change how these materials are perceived, show their value, and possibly influence a shift in the decision-making approach.

User Research Myths
Jon Yablonski

The article covers five myths about user research. Overall, I agree with them, but the very first myth: “It takes too much time,” caught my attention.

Of course, we need to clarify what exactly “too much time” implies. But from my point of view, this isn’t a myth.

Qualitative research involving real interactions—like interviews and UX testing—does take a significant amount of time. For instance, if you’re recruiting a suitable sample from a B2B startup’s audience, you probably wouldn’t say it’s quick or cheap to find even five respondents.

With today’s “democratization” of UX, research often gets handed off to designers who might not always have the skills or experience of a professional UX researcher. This slows down an already time-consuming process. In addition, many designers aren’t comfortable doing calls “in the background,” especially given that many of us are introverts.

If by “research” we mean “just chatting with a handful of people,” then sure, that’s quick. But if you don’t follow the proper guidelines for conducting user research, the results will at least be invalid, and at worst they can be harmful, misleading, and even discredit the design team due to mistakes.

This is understandable. Beauty can’t be measured. You can’t easily sell it to stakeholders. You can’t be objective about Beauty. It’s hard to create, and in today’s world, it often costs almost nothing. Every CEO, CPO, and product manager will ask how it makes money. How much? What’s the ROI? Who knows.

Secondly, we live in a world where designers must serve business needs. Over time, we start evaluating each other by how much revenue we’ve generated. You’re told not to be like those ’Dribbblers’ creating ’useless’ pictures. But after a long day, we find ourselves looking at those very pictures and concepts, searching for inspiration. And somewhere inside, we ask, ’Why not?’ or ’What if?’

It’s like an internal trauma. We can’t quantify Beauty, so we retreat into the safety of our functional, efficient swamp. We hold ourselves back, we censor our creativity. We stifle everyone entering the profession, pushing them to follow the same current of conformity. Everything measured in dollars and green metrics feels straightforward — explainable, mathematical, statistical.

Designers like to think that it’s not about how it looks. It’s about how it works, or how it communicates, or how it changes the world. All true, except it’s also about how it looks. The artifacts we make are the Trojan horses that deliver our ideas to an unsuspecting public. Making them look beautiful — or engaging, or funny, or provocative — is anything but a superficial exercise. Michael Bierut. Now You See It and Other Essays on Design

Yet people don’t engage with metrics or calculations; they experience the product. People want to feel cared for, they want to play and experience positive emotions again and again. And when they only see functionality, they feel bored.

When creating products, especially large ones aimed at a broad audience evaluate your projects, screens, and elements. Ask yourself: are they beautiful or ugly from an aesthetic perspective? Don’t forget the emotions. Think of screens as buildings on the streets where people constantly walk. You wouldn’t want to live in a dull building, despite all its functionality. You’d like to see quality architecture every day and cultivate your taste. This is how we push our future beyond mere functionality, to create products that are not just effective but aesthetically pleasing.

His priority seemed always to be the creation of objects that were beautiful rather than simply functional. He was constantly questioning how things should be. “He hated ugly, black and tacky electronics,” recalled Grinyer. “He hated computers having names like ZX75 and numbers of megabytes. He hated technology as it was in the 1990s.” Leander Kahney. Jony Ive: The Genius Behind Apple’s Greatest Products

I don’t claim to be a super expert or a designer who can create exceptionally beautiful things. But I try because I want to see a world that’s beautiful, not just efficient. Of course, I’m not dismissing business needs, user needs, or functionality. I see them as a foundation or a trampoline, not the final solution.

We need a balance — it’s time to reclaim space for Beauty.

Additional links

“Beauty”. Stefan Sagmeister, Jessica Walsh

“Now You See It and Other Essays on Design”. Michael Bierut

“Jony Ive: The Genius Behind Apple’s Greatest Products”. Leander Kahney

“The obsession over craft” post from David Hoang

Intercom's application of the Jobs to Be Done framework shifts the focus to the motivations and outcomes that drive user behavior. Unlike traditional user stories, which often ignore context and concerns, JTBD uncovers deeper insights by asking the right questions.

The book shares how the company uses this method and how it can lead a product team to exceptional results

Criticism of the Persons method

We never use personas in Intercom. They artificially segment audiences and focus on audience attributes rather than on their motivations and the results they want to achieve. In other words, personas talk about who does what, but they don’t talk about why someone does something. And that’s much more important.

Personas work well if the product's user base can be broken down into specific segments. In this case, personas need to be carefully crafted. Each line in the description should serve a purpose, and the entire team, including stakeholders, should be involved in their development.

For the same reason, the persona method can be good for advertising. However, in product development, personas work poorly because products do not match people; they match problems.

User stories have three big problems: 1. They use personas. 2. They couple implementation with motivations and outcomes. 3. They ignore context, situations and anxieties.

Job Stories and Team around JTBD

That's why we invented Job Stories: [When __][I want to __][so I can __]. “When __” focuses on the situation, “I want to __” focuses on the motivation, and “so I can ____” focuses on the outcome.

Before each project starts, we create a one-page project brief that explains what we are doing from the user's perspective and focuses the team.

Here's a step-by-step plan for how to implement this approach:

1. Start with the high-level job;
2. Identify smaller jobs that help resolve the high-level jobs;
3. Observe how people solve the problem (the job they are currently using);
4. Come up with a Job Story to investigate the causality, anxieties, and motivations of what they do now;
5. Create a solution that resolves that Job Story.

About JTBD research

Everyone on the team should talk to customers. Designing successful products involves researching how people solve problems now, in what context, and understanding causality, anxiety, and motivation.

It’s helpful to find out what tools a person uses, what their experience is like, and how the process works. Asking your customers “Why?” is the best way to learn their deepest needs. With each new question, you may discover new insights.

One of the important parts of JTBD research is identifying the first thought that started the search for a solution or the recognition of an existing problem. This is easy to track in the example of physical products, but with software, it is not so simple, because there can be many different factors that influence the buyer. JTBD research helps you to uncover something deep — motivation, and real problems of people. This is something more than simple user research.

It is important to look for the person who is directly affected by the problem and decides to fix it. Talking to users of the product is useful, but only by talking to the decision maker can you understand the motivation and true reasons.

You’re really looking for the right people to talk to, the main decision maker

Typically, when researching the value of a product, the first three layers are important: Usefulness (why do you need a drill?), Usability (why do you need holes in the wall?), Desirability (what does it give you?).

Focusing on how people use a feature or product, without regard to categories, can quickly reveal how to improve the product or feature. JTBD also helps you better understand the competitive landscape. Ask yourself, “Who else is trying to solve the same job my product is trying to solve?”

The book also provides sample questions that can be used to conduct a JTBD study. For example, “Once you figured out you wanted to buy a new solution, did you do much research to figure out which tool was right for your company?”, “Were you the only one who was looking for something else at that time?” , “Where did you first hear about the tool you picked?”, “Can you recall how you came to purchase the specific tool you did?”, “When you were looking around, did you (or anyone else) try out any other tools?, What were they?”, “How long did you look around before you clicked “buy” on the website?”

About switching to a new product

People don't buy a product. They switch from something old to something new. That's why it's easier to make things people want than it is to make people want things. But to reduce the fear, anxiety, and doubt of switching to a new product, it's worth building an argument around the struggling moments your customers are experiencing.

ReWired Group identified four forces that influence the purchasing decision process: The push of what is happening currently. The pull of a new solution. The anxiety of what could happen. The attachment to what you currently have. Accordingly, product advertising should be built around these forces.

Many purchases are made out of habit without considering alternatives. For example, people buy the same coffee at the same cafe every morning out of habit. People are not against progress, they just prefer inertia.

What should a product be like and how to integrate the product into the user flow

If a product does too little, there is no point in buying it. If a product does too much, it will most likely collide with other products that do some of the work better. Finding the right balance is an important task for the team.

That said, compared to physical products, it's much easier for digital products to go off the rails and quietly turn into a feature-packed monster, but if the product doesn't do its job well at its core, adding new features will only make things worse.

Any new products need to be 10 times better to get mainstream adoption. It’s only at that point switching becomes a no-brainer.

The product should be as simple and effective as possible. However, you should be wary of MVPs with limited functionality, which can be called “a feature, not a product” or a narrowly specialized product.

Products are built into the user's workflow. This means they have a beginning and an end of use. You can only determine these points if you know the entire buyer's workflow.

The product should stop when one of the following is true: the next step overlaps with the work of large, well-known services and you don’t want to compete with them, the next step can be done in many different ways, the next step is done by other users, you can’t bring any value to the next step. It’s worth remembering that if there is no decision-making or insights in a series of steps, these steps may also need to be removed.

Below is a set of theses from the book, divided into chapters by meaning.

On Innovation, Causality, User Progress and JTBD

Progress Theory. Customers don’t buy products or services. They hire them to make some progress in their lives or work. They have some job to do and they hire a product to solve the problem. The job is some progress that a person is trying to make in certain circumstances. It’s not always a problem.

The engine of innovation that makes companies great works by understanding causality, not guesswork. The theory of disruptive innovations won’t lead you to where to look for new opportunities. But the theory of Jobs to be Done does because it’s based on the causality of human behavior. And so it can predict behavior, not explain success.

Causality is the foundation, not the data. Despite huge amounts of data, if companies do not understand the reasons why users hire their products under certain conditions and choose other products under other conditions, this data is unlikely to help create innovation. The fact is that when analyzing data, without understanding causality, we are prone to assumptions, approximations, and extrapolations, and can misinterpret the data. A good example is that based on micro-assumptions, people in the 18th century misinterpreted the changing positions of celestial bodies, thinking that everything revolves around the Earth.

“What job are you hiring this product to do?” is the best question to ask a business. For example, you might buy a magazine to pass the time in a doctor’s office or because you are a sports fan and want to read sports news. But in one case or another, you have some job that you want to hire this magazine to do.

JTBD stories. Buyers won’t be able to tell you what they want, but they can describe their struggles well. They can be written in the format: “Because of this, we did that ...”

A job can only be defined and decided on in relation to specific circumstances. Therefore, a job is inextricably linked to the user’s context: where is he, what did he do before, what will he do after, what is he doing in the process, who is he with, what are the social, cultural, or political frameworks around him? It can also be a period of life: retirement, graduation from college, marriage, or the birth of a child. These circumstances are a fundamental part of the concept of a job.

About the importance of social and emotional. We often focus our efforts on the functional and practical side of a product. But emotions and the social side often outweigh functionality.

Needs, like values, are not a job. Needs are too general, they do not include circumstances and context. Our values are also too abstract.

It’s not who did what, but why that matters.

We do not create jobs. Jobs themselves are constant, but the ways to solve them change dramatically with the development of technology. For example, look at how our communication with each other has changed from spoken language to letters, telegraph, telephone, email, and messengers.

Job theory is not suitable when current products work perfectly. And also when solutions lie in the area of mathematical analysis, and not in the area of social, emotional, and functional needs.

About data

Substituting Excel tables for user understanding. A separate problem with data is that while there is no data, product managers tend to ask the question “Why does something happen the way it does” and look for an answer in user responses. But as soon as data appears, it becomes much easier to look at Excel tables than to talk to people. As a result, managers begin to manage numbers, especially in large companies, where managers may never even meet customers. If a company enters the stock market, then the numbers begin to manage the company. This makes the company vulnerable to those who think first and foremost about users.

The fundamental problem with data is that quantitative data is more credible than qualitative data. But is quantitative data objective? For example, many studies are based on data from companies’ financial statements. Is this objective?

Data is not a phenomenon. The main function of data is to explain a phenomenon. Considering quantitative data to be objective is wrong, if only because data does not exist initially. All data is collected by people. People decide how to organize it, how to present it, and how to extract information from it. And all this can easily introduce errors in interpretation.

The same managers can make a company great and lead it to destruction. The question is what approach is used in working with innovations. Unfortunately, the pressure that innovators are under often leads to decisions that please investors and rapid growth, and not users.

Businesses focus on data on how their product sells in different markets, to different audiences, and with what margins. However, all this data does not provide an idea of what kind of job the product does for users and how well.

About metrics

Causality leads to The Right Metrics. It’s tempting to think that we recognize patterns in data, but too often businesses feel comfortable with correlations rather than casualities. However, it’s the shift from guesswork and correlations to understanding the causal mechanism that changes everything about how we solve problems and prevents new ones from arising. A properly described job will lead to the right process that will generate the right data that answers the question: “How are we doing?”

The right metrics are user-oriented. Instead of focusing on internal business financial and production metrics, it is better to think about external customer-benefit metrics. Think about what is important to the user and formulate metrics from his side. Conversions and retentions are very simple clear and tempting, but you cannot confuse business efficiency with user effectiveness.

About Features

Features are not the main thing. By focusing on the parameters of the product, for example, its features, we think that we are improving the product. However, only by understanding for what job people hire the product and in what specific circumstances can we achieve an a-ha moment. These insights are fragile, they are more like stories than statistics. But through them, you understand the user, look at the world through his eyes.

About the feature race. If you ask users about features in a product, they can suggest hundreds of changes, which will lead to a false feature race. But you should ask not about features, but about experience, about deep problems or progress that the user needs in life.

About the company and the processes around work

When the product job is revealed, experiments are conducted and guides for developing the product or service are formed. And then the company culture is formed around JTBD. This leads to the fact that even if a competitor can copy the product, he will not be able to copy the processes that allow you to implement innovations.

Purpose Brand. This is a brand created to become a synonym for the job user. When you hear the names of such brands, you immediately understand what they were created for. Purpose brands provide remarkable clarity. A well-developed purpose brand will stop a consumer from even considering looking for another option. They want that product.

Process as a competitive advantage. Resources can be bought or sold. Products can be copied, but through integrated processes, companies create an ideal experience and competitive advantage. Processes are created from hundreds of small decisions and cannot be easily copied.

Structure companies around jobs. Companies can be built not around artificial departments or divisions but around users’ jobs. If you don’t focus on users’ jobs, the organization will sooner or later become bogged down in individual opinions and politics.

The company’s mission is usually vague and does not help in making daily decisions. But a clear job spec helps. It helps both high-level managers and each employee understand what to do.

Amazon’s Press Release Framework. Innovation at Amazon often starts with a mockup of a “press release” that is presented to the team that will work on it. The press release contains all the details, user experience, and processes.

About competition

When a customer decides which product to hire for a job, they have something like a resume in their head for your product and for any other competitor. Moreover, people can hire the same product for different jobs in different circumstances.

The product does not define the customer’s job. The product solves it. As a rule, jobs, especially widespread ones, can be solved in different ways. If you concentrate on your product and not on solving the user’s job, sooner or later you can lose the initiative, because someone else will solve the problem better, perhaps in a completely different area and with different tools.

Competitive landscape. By studying jobs in detail, you can understand that competition often goes beyond the usual understanding. For example, products from different categories, such as Facebook and cigarettes, can compete with each other in certain circumstances. For example, Netflix competes with everything that helps people relax, and Uber competes with the subway, the bus, or calling a friend. So if you don’t know what and who you are competing with, how can you know that you are better than other alternatives and create something innovative regularly?

Competition with inaction. Some companies can compete not only with other companies or activities but also with nothing. Because the status quo is also a strong competitor because you can always choose to do nothing.

Companies become vulnerable to disruptors when they start spreading themselves thin and creating many products for different users. Because a disruptor focuses on a small number of jobs and does them well.

Ways to detect jobs

• Take jobs in your own life
• Find jobs uncovered by-products. People often don’t hire a product for a job
• Where a problem is so upsetting and frustrating that they try to solve it themselves
• Negative jobs. Where people don’t want to do something
• When products aren’t used for their intended purpose

The moments of struggle, nagging tradeoffs, imperfect experiences, and frustrations in peoples’ lives—those are what you’re looking for. You’re looking for recurring episodes in which consumers seek progress but are thwarted by the limitations of available solutions.

About people and their behavior

Negative feedback. If the product does not satisfy the user’s work, it’s not so bad. The problem is that there is always a risk of being forever entrenched in a person’s mind as an unsuitable product, or even getting negative feedback and ruining their reputation. Research confirms that 95% of people read reviews, and for 86%, reviews are the main factor in making a purchase decision.

People sometimes speak and act in direct opposition. If you ask people if they consider it important to take care of nature, everyone will answer positively.

To hire something, a person will most likely have to fire something. What to fire and why this should happen are important questions.

Forces of change. When a person switches to a new solution, two pairs of opposing forces fight. The first pair is the fight against the problem and the attractiveness of the new solution. The second pair is the habit of the existing solution and the anxiety to try something new.

About theories

Good theories lead to insights. You can produce insights if you have a set of good theories. A good theory is the best way to work with problems because it is like a universal key that allows you to solve a variety of problems by formulating questions correctly. Good theories are not meant to teach us what to think. Rather, they teach us how to think.

The book is divided into two parts. The first part, “The Method” provides an overview of the process and how to organize Growth Teams.

The second part, “The Growth Hacking Playbook” offers detailed tactics for implementing the method, including separate chapters on user acquisition, activation, retention, and monetization, as well as how to maintain and accelerate growth once achieved.

Problem formulation

One of the most popular illusions is the “Fallacy of the Field of Dreams” when entrepreneurs believe that creating an outstanding product is enough, and customers will come to it themselves. However, this is far from reality. Many startups face high churn rates. Traditional marketing methods, including print and TV advertising and new online formats, are losing their effectiveness.

69.8 million Internet users in the US (up 34 percent year over year), including nearly two out of three millennials, report using ad blocking software.

At the same time, a significant portion of companies continue to focus on so-called “vanity metrics” that look good on paper but do not reflect real growth in product usage or revenue. For example, the number of visits to a site may impress but does not indicate the quality of user engagement.

The lack of focus on data analysis leads to companies relying on Google Analytics, which cannot effectively integrate various data sources, such as sales and customer service. This limits their ability to make valuable discoveries that could lead to growth.

In most product companies, the task of increasing user activation and retention falls not on marketers but on product and engineering teams that focus on building features that help users fall in love with the product. However, these groups rarely collaborate, creating additional barriers to successful growth.

Growth hacking helps overcome these challenges by combining data, cross-functional teams, and innovative methods to achieve real results in customer acquisition and retention.

What is Growth Hacking

Growth Hacking is a method that can be easily adapted to the specific needs of any team or company, regardless of their size or stage of growth. It allows you to extract specific, relevant insights into user behavior in real time from data. These insights can be used to shape growth strategies.

This approach has become the basis for a methodology aimed at accelerating market growth through high-velocity experimentation. The philosophy is similar to that of Agile or Lean Startup. Both have transformed business models and product development, while Growth Hacking focuses on customer acquisition, retention, and revenue growth.

The most significant successes in this area are achieved through a combination of programming knowledge, data analytics skills, and a strong marketing background. Key elements include creating a cross-functional team that breaks down traditional barriers between marketing and product development and using both qualitative research and quantitative data analysis to deeply understand user behavior and preferences.

Growth hacking is not about throwing ideas against the wall as fast as you can to see what sticks, it’s about applying rapid experimentation to find and then optimize the most promising areas of opportunity.

The key aspect of Growth Hacking is the rapid generation and testing of ideas using rigorous metrics to evaluate results and make further decisions. This method allows companies to grow fast without spending money on outdated and expensive marketing campaigns with questionable business value.

About processes in Growth teams

One of the important rules for starting high-speed experimentation is to understand that the product has reached the Must-Have state. For this, it is useful to conduct a so-called Must-Have Survey. If 40% of users answer that they will be “very disappointed” if the product is not available, we can assume that the product has sufficient must-have status. However, if the product is already far beyond the initial development stage, such a survey is not recommended. Imagine if Facebook publishes a survey tomorrow and asks about disappointment from its absence.

As the product develops, it is important to regularly monitor Retention metrics to notice problems in time and not relax, even if a stable base of loyal users has been achieved.

Analysis of user behavior helps to understand what exactly they do but does not always reveal why they do it. Therefore, for successful growth, it is critical to understand what the main value of the product is, who its target audience is, and why it is irreplaceable for them. You need to communicate with users to study their true needs. To do this, you need to “get out of the building” and find out what customers want from the product.

Even the most sophisticated analysis can really only tell you definitively what users are doing, not why they’re behaving that way.

Growth teams play an important role in experimenting with new features and collecting feedback, whether through prototypes or beta versions. Experiments to validate ideas should be low-cost, in the form of a “Minimum Viable Test” (MVT). This could be a prototype or demo that can be used to see how users react. It is important to record the results of experiments in a report and store them in a knowledge base so that future teams can refer to past experiences.

Effective analysis requires creating what’s often called a data lake or data warehouse, where all customer information is collected to identify distinct user groups and their unique behavior patterns. An example of the importance of good data is the Facebook team’s decision in 2009 to pause all experiments for a month to focus on improving data collection and processing processes, highlighting the key role of accurate data for product growth.

Now a little about prioritization and hypothesis generation. Prioritization of ideas for testing is carried out according to the ICE (Impact, Confidence, Ease) system, where each idea is assessed based on its impact, confidence in success, and ease of implementation. During prioritization, it is also worth paying attention to the impact of the experiment per unit of time. For example, you should not “move buttons”, especially at the initial stages, when traffic is low. Such experiments will require a lot of time for testing and will most likely have little impact. It is better to postpone them to a later stage.

When generating hypotheses, it is worth sticking to a standard form and description, which should contain information about what you want to test, why it should have an impact, and how to measure it.

Based on the results of the tests, if the results are equal, preference should be given to the control option in order to avoid potential risks.

Growth teams should also periodically switch to different stages of the funnel — from user acquisition to activation, and then to retention. Many of the best ideas arise unexpectedly, and their implementation requires flexibility.

About the structure and organization of Growth teams

Effective Growth Teams require a multidisciplinary approach, bringing together specialists from different departments, such as marketing, product, engineering, and analytics. This facilitates collaboration and helps teams share knowledge and better understand each other’s views and challenges. This interaction is especially useful for generating new ideas, where, for example, engineering and marketing can work together to create interesting “hacks” to experiment with.

Growth teams should bring together staff who have a deep understanding of the strategy and business goals, those with the expertise to conduct data analysis, and those with the engineering chops to implement changes in the design, functionality, or marketing of the product and program experiments to test those changes.

Typically, product teams follow a clear roadmap for updates, including feature or onboarding process improvements, but as the company grows and processes become more complex, such teams may work less flexibly.

Creating a separate Growth Team with its leader allows you to focus on specific tasks necessary for growth. This leader, combining the roles of manager, product owner, and analyst, is responsible for choosing priorities and key metrics that the team will strive to improve.

There are two main organizational models for Growth Teams. Within the first, functional structure, teams report to product management and focus on experiments to improve all stages of the growth funnel.

The second model involves the allocation of an independent growth team that reports directly to the VP of Growth or even directly to the CEO. Such independent teams are easier to form in the early stages of the company, while organizational structures are not yet fixed.

It is worth mentioning separately the involvement of external experts. These individuals can help the team think outside the box and offer new perspectives. However, handing over key growth responsibilities to outsiders carries risks—they may not have the authority or motivation to drive long-term, sustainable growth. Growth Teams also need support from senior management to avoid bureaucracy, conflict, and inertia that can slow down growth. External teams will have a hard time getting that support.

Fundamental growth equation

To grow, it’s important to boil down complex business operations to a simple formula that captures the key drivers of growth. This allows growth teams to focus on key signals, separating them from the data deluge.

A key element of the formula is the so-called North Star metric — a metric that most accurately reflects the core value delivered to customers. It helps the team stay on track and not get distracted by irrelevant metrics that may be attractive, but do not contribute to real growth.

Creating visual reports and dashboards that reflect progress on North Stars and key growth levers is important. This makes the data more accessible and visible to everyone in the company, helping to ensure that data-driven thinking becomes part of the culture at all levels of the organization, not just the growth team.

Marketing channels

Successful marketing requires taking into account the specifics of your business model and user behavior, such as types of Google queries, preferred stores, and social networks.

One method of prioritizing channels is to rank them by six factors, assigning each channel a high, medium, or low score, and then calculate the average to prioritize channels for experiments:

1. Cost — how much do you expect to spend to run the experiment
2. Targeting — how easily can you reach your target audience in the experiment
3. Control — can you make changes to the experiment after it runs, or stop and adjust it
4. Time to run — how much time and resources will it take your team to run the experiment
5. Time to exit — how long will it take to see results from the experiment after it runs

You should also consider the cost of customer acquisition — if it exceeds your potential revenue, that’s a problem. Growth Hacking is about finding the most cost-effective methods of acquiring new customers and optimizing them for sustainable growth.

When changing focus to a new growth driver, it’s important to re-analyze the data to find unique insights for the new goal. Even if you have already found working channels, it is always worth looking for innovative methods for testing.

Aha moment

Aha moment is the moment when users begin to understand the value of the product for themselves. Why they might need it, and what benefit they can get from using it.

98 percent of traffic to websites does not lead to activation, and most mobile apps lose up to 80 percent of their users within three days.

To understand whether a product has “aha” potential, find loyal users by collecting data and feedback, and then understand how these people use the product, and what value it gives them. It can also be very useful to compare data on how users who tried the product and became regular users differ from those who tried it and left.

Analyze each point of the user’s path to reaching the aha moment. Build a funnel report measuring conversions at each stage. Even if you think you already know everything, after this exercise you can find many surprises.

A simple formula worth remembering: DESIRE — FRICTION = CONVERSION RATE

Language

Sometimes achieving growth results requires not a change in the product, but an adjustment in the communication of value to potential and current customers. Even small changes can have a significant impact.

Simply changing the language from “Sign Up for Free Trial” to “See Plans and Pricing” netted 200 percent more sign-ups.

The initial phase of customer growth involves achieving two key fits:

1. Language/market fit, where the language used to describe the product resonates with the target audience
2. Channel/product fit, where the chosen channels, such as search advertising or content marketing, effectively deliver the product to the right audience. This covers all aspects of communication, from emails and notifications to promotional materials and text on product interfaces.

The key requirement for language is that it answers the customer’s question: “How will this improve my life?” Successful headlines and copy can have a significant impact on reach and perception. Therefore, when testing growth strategies, you should focus on the language and style of communication and then move on to other aspects.

“A good headline can be the difference between 1,000 people and 1,000,000 people reading,”

New User Experience

The basic principles of creating and optimizing the New User Experience (NUX) include an approach in which this stage is perceived as a separate product, requiring a unique design. The first landing page should clearly reflect the relevance of the product to the query, show its value to the user, and contain a clear call to action.

The value of the product should quickly answer the question: “What will I get?”, and the call to action should encourage the user to take the next step. Sometimes it is useful to immediately let the user try the product, before signing up, to reduce friction and get to the “aha” moment faster.

This is your moment. You have more attention than you ever will have again, from that user, to try to teach them what your product is really about. To really help them learn the product in a meaningful way.

However, not all friction is bad — adding “positive friction” (e.g. gradual steps) helps users understand the product better and is achieved through experimentation. Methods based on Mihaly Csikszentmihalyi’s “flow” theory and the principle of gradual involvement are also effective. Such methods are constantly used in the Game industry to gradually introduce the player to the game world and the main mechanics.

The team also tested adding more text around the call to action to encourage sign-ups, inserting a testimonial from a happy Airbnb customer. This additional text actually hurt sign-ups. This is an example of a more subtle type of friction, which isn’t actually experienced as annoying, yet still deters visitors or users from taking the action you want them to. You can really only discover whether this kind of friction exists—and how it is impacting your activation rates—through experimentation.

If you decide to experiment with positive friction, it is useful to use questionnaires and gamification elements. Questionnaires with several questions aimed at the interests and problems of users create a sense of involvement and strengthen the connection with the product. Neil Patel advises limiting the number of questions to five and making them with a choice of up to four answer options, as well as adding visual elements to increase engagement.

Now users were first shown just one screen, which asked them to select five topics that they were interested in. After they made their selections, the app delivered them to a feed made up solely of that type of content, where they could practice pinning and saving items. The change resulted in a 20 percent increase in activation rate, a massive win.

The principles of forming “stored value” are also actively used: the more information users enter into the product, the higher their involvement. Useful techniques include surveys and gamification, for example, welcome questionnaires with short questions about the user’s preferences and goals.

Virality

For most products, getting users to send and accept invites requires significant initial experimentation and ongoing optimization. Successful virality is achieved through a balance between how well the product is “packaged” and its value. Finding words that will grab users’ attention is important, but true value is essential to achieving viral growth.

There are several types of virality: traditional (word of mouth) and instrumental — when the product includes features that help users invite new participants. In this case, the experience of the sharing product itself should be intuitive and enjoyable.

A product is considered truly viral if the virality coefficient (K-factor) is greater than 1, i.e. each new user attracts at least one more. The main factors of virality are payload (the number of invitations sent), the conversion of invitations, and the frequency with which people receive invitations. This formula should be taken into account when creating viral engagement cycles.

The choice of invitation delivery method is important for the formation of a natural flow of new users. The best viral engagement loops are created when invitations are integrated into the product and emerge naturally through use.

Often, you want to motivate users through a two-way reward, where both the sender and the recipient benefit. The reward must be related to the product: the closer the value of the incentive is to the product, the more effective it will be. Effective viral loops motivate users to invite others because it improves their own experience with the product.

A common mistake is not optimizing enough for the invited users. When an invitee accepts an invitation, it is important not to immediately ask them to sign up, but first to show the value of the product so that they understand why they should join.

Gamification

Gamification should be viewed as a toolkit rather than a fixed set of tactics that work for all businesses.

The key aspects of gamification include providing meaningful rewards, creating surprise and enjoyment by changing the way rewards are received and presented, and adding an element of instant gratification. Effective rewards in a gamified environment include status, access, power, and tangible rewards (such as financial incentives or gifts).

Triggers work best when they both motivate the user to take the desired action and make it as easy as possible to do so when the trigger is given. The best approach to using triggers is to provide users with information about an opportunity that is useful to them. Triggers fall into three categories based on the user’s motivation and ability:

• Facilitator — helps highly motivated but low-skilled users take action.
• Signal Trigger — targets highly motivated and low-skilled users, helping them stay on track for repeat actions.
• Spark — motivates high-skill, low-motivation users to take action.

It is also useful to consider Robert Cialdini’s six principles of persuasion:

1. Reciprocity — people tend to reciprocate favors, even if the reciprocal action is different from the original.
2. Commitment and Consistency — people who have done one action are more likely to take another, regardless of the magnitude.
3. Social Proof — people rely on the actions of others when faced with uncertainty.
4. Authority — users are more likely to follow the recommendations of authority figures.
5. Liking — people are more likely to engage with companies and people they like.
6. Scarcity — people are willing to act faster if they fear missing out on future opportunities.

Retention

To effectively retain users, companies need to find the right balance in communication: successful messages and their frequency directly affect the loyalty of the audience. In digital products, retention also increases if users find value in the product that only strengthens over the years — as in the case of Evernote, where the likelihood of users returning increases over time due to “stored value”.

Retention can be divided into three phases.

In the initial phase, the main goal is to help the user quickly understand the main benefit of the product so that he decides to stay.

Creating a deeper level of attachment can be achieved through so-called “continuous learning”. The better users master the product, the higher the likelihood of their return. An approach called “continuous onboarding” can be useful, which guides the user along the learning curve of new functionality. This approach is similar to learning to play a musical instrument or to learn a language — the product always offers something new.

According to data published by mobile intelligence company Quettra, most mobile apps, for example, retain just 10 percent of their audience after one month, while the best mobile apps retain more than 60 percent of their users one month after installation.

An important aspect is the perception of the value of rewards. Interestingly, intangible rewards (such as status or access to exclusive features) are often more effective than financial incentives. In the long term, such rewards can become habitual and valuable to users.

Finally, in the long-term phase, it is necessary to continuously maintain the feeling of value of the product, ensuring its relevance and usefulness to the user. To do this, it is useful to update the perception of the product as something “indispensable”.

A long-term retention strategy also involves a combination of improvements to current features and notifications about regular launches of new functionality. These updates and innovations (especially for SaaS products, video games, and content platforms) create a sense of upcoming improvements in users. However, messages about such innovations need to be balanced so as not to irritate with a long wait.

If a user’s activity gradually fades, they can be re-engaged through a process called “resurrection,” which is typically done through targeted advertising and emails that remind them of products or new features designed to meet their needs. When users stop interacting with the product, they can be added to the “resurrection” flow by sending them a series of messages with offers that are likely to pique their interest.

When analyzing retention rates, it’s worth comparing them to industry averages and competitor data to establish objective benchmarks and develop a retention strategy.

Accurate analysis often requires breaking the audience into cohorts — subgroups that can be analyzed based on different retention metrics. Specialized tools (such as Mixpanel, Kissmetrics, and Amplitude) can help with this process, especially if you don’t have a dedicated data analyst on your team.

Business products, such as software as a service, fare much better, with annual retention rates north of 90 percent, according to a study of private SaaS companies done by Pacific Crest in 2013. A 2013 study concluded that credit card companies in the US see annual churn rates of roughly 20 percent, while European cellphone carriers see churn of anywhere between 20 and 40 percent.

Monetization

To successfully monetize a company, it is important to conduct a deep analysis of the data to identify experiments with the greatest potential.

You need to start by building a customer journey map, which will allow you to see at what stages the client brings in the most revenue and where losses occur. After that, it is important to divide customers into cohorts, focusing on which groups bring in the most revenue. This division can be supplemented with other criteria: location, age, gender, acquisition sources, device type, first visit or purchase, etc. Instead of analyzing retention, at this stage, it is worth looking for correlations with revenue, which will give ideas for new experiments.

In some countries, for example, in the US, subscription models are perceived better than in others. This creates an opportunity to test different monetization models by region. One of the proven ways to increase profits is to offer users additional products or features.

Personalization also works for monetization: recommendations can be built, for example, using the Jaccard coefficient. What the equation says is that the similarity between two items, A and B, is equal to the size of the intersection of A and B divided by the union of A and B. However, excessive personalization can cause discomfort for users.

Another common mistake companies make is setting fixed prices, which can and should be tested like other elements of the business. It is important to conduct such experiments at least once a quarter. Dynamic pricing that takes into account factors such as seasonality, purchase history, and device type can also significantly improve profits.

The comparison pricing effect can be managed by offering intermediate options that lead users to more expensive products. For example, companies sometimes introduce a decoy product with limited functionality and a price slightly lower than the main one, which encourages users to choose more expensive offers. This is because users tend to see a high price as an indicator of quality, especially in areas such as technology and professional services. To maintain the customer experience, users must see the same version of the pricing page on repeat visits.

In some cases, such as digital products, even small payments can scare away users, and therefore offering a free tier can be more profitable. An example is the limitations of the free version: Spotify clearly shows its free users the possibilities of a premium account, pushing them to buy it.

Most freemium product conversion rates, [...] hover around 1 percent.

To increase revenue, companies can experiment with subscriptions for upgrades, virtual goods, and in-game currency. Understanding consumer psychology can also help monetize a product. The core principles discussed earlier, such as reciprocity (the desire to reciprocate a benefit provided), consistency (the tendency to repeat an action), social proof (the influence of others’ opinions), authority, likability, and scarcity, are important tools for increasing sales.

Applying these principles, for example by adding testimonials and logos of famous customers, can increase customers’ desire to make a purchase. The principle of scarcity, which creates a sense of “missed opportunity,” is also effective in pushing for action.

Finally, for growth, it is important to overcome the local maximum effect, when the result of improvements ceases to increase. Switching to a new approach, such as changing the structure of the pricing page, can open the way to higher results.

Continuous Cycle of Growth

Business growth is often achieved through many small successes that accumulate over time. This process can be described as a continuous cycle consisting of four main stages: first, analyzing data and collecting insights, then generating ideas, then prioritizing experiments, and finally executing them. Once the experiments are complete, the cycle returns to the analysis stage, where the results are reviewed and next steps are determined.

One of the key aspects of successful growth is the ability to increase the average revenue per customer. This allows more resources to be directed toward growth, creating a so-called “virtuous cycle” where growth itself contributes to further growth.

All growth hackers must always keep in mind that, as the growth team at Airbnb says, “love creates growth, not the other way around.”

However, companies often face the problem of “feature overload,” where the rush to add many new features results in a product that is inferior in quality. Rather than improving, feature overload can confuse users and distract them from the core value the product offers.

Research shows that having too many features can have a negative impact on long-term customer retention. For example, in a study conducted for the Marketing Science Institute, researchers concluded that companies should focus on creating more, more focused products with a limited set of features, rather than trying to include every possible feature in a single product. In this context, reducing the excess can lead to more successful results than constantly adding new features.

The right approach to growth, then, involves not only innovation and experimentation but also paying close attention to what already exists, so as not to lose the value the product brings to its users.