
Hito happened to be a bit late to the party. In 2022, **the market of hardware crypto wallets was already full of competitors. Ledger, Trezor, CoolWallet and others had been around for some time.** Yet Hito's founder saw an opportunity in offering a wallet that would be not just secure but also user-friendly — a gadget that could be used by anyone, not just crypto enthusiasts.

For a team working on Hito's initial design code, this premise offered a challeging task. The goals were grand:

- to help the new brand stand out in the competitive envoironment;
- to communicate Hito's distinct values and key advantages;
- to be scalable across different mediums (web, app interfaces, packaging, etc.).

At the same time there were significant constrains: all this had to be achieved with the very limited resources of an early stage startup.

## Mapping the world of crypto

To better understand the context, the team studied all the existing crypto wallets, crypto projects in general, banks and financial institutions.

3 key trends were observed:

1. The crypto ecosystem didn't have any shared and disctinctive style.

2. At the same time, crypto wallets often copied Apple trying to present themselves stylish, polished, and premium.

3. Forward-thinking banks and financial projects wanted to appear more accessible and colorful (NatWest or Apple Card).

![Ledger homepage](/images/posts/hito/ledger.png)

## Talking to crypto enthusiasts

The team also conducted a number of interviews to better understand the targed audience and to identify the messages that would resonate most. Here are the key takeaways:

- Even crypto enthusiasts had a hard time understanding all the details of how crypto technologies worked;
- At the same time, security of crypto assets was a big concern for everyone;
- None of the existing hard wallets were really suitable for storing valuable NFTs for the lack of a screen on which NFTs could be seen;
- There was a significant audience eager to try new things even if practical implementations weren't even clear.

## Identifying Hito's personality

Based on customer interviews, the team identified 5 key messages for Hito.

- Like other hardware wallets, Hito is secure.
- Unlike other hardware wallets, Hito is extremely easy to set up and use.
- Unlike other hardware wallets, Hito has a full-color touch screen which is perfect for NFTs.
- Unlike other hardware wallets, Hito is compact — almost the size of a credit card.
- Also, Hito is built by crypto enthusiasts.

Overall, _the brand had to appear user-friendly, approachable, not dead serious and corporate but community-driven and maybe even a bit humorous._

Since "hito" itself was a Japaneese word (meaning "person") and clearly conveyed references to Japan, even for English-speaking people, using Japan as a style reference was a viable option.

![Japaneese refs](/images/posts/hito/japan.png)

## Defyning the tone of voice

The team defined that in order to sound not "corporate", the brand should not only be straightforward, laconic and down-to-earth, but also a bit ironic. This approach resulted in adding a bit of humor to the copy, like in the following sentences:

- You don’t need a ten-page manual to know how to protect your crypto assets.
- You can check the details of every transaction you sign — and actually see all the (very precious) NFTs you store.
- This wallet fits into a wallet — it’s a gadget the size of a credit card. For your inner nerd, here are the exact dimensions: 82.5x52x4mm.
- Everyone — even your Granny or that friend of yours who’s still on Skype — should be comfortable with a cold crypto wallet.

## The final result

It took a few design iterations to nail the right style — simple, unique, and scalable.

![Hito landing](/images/posts/hito/hito-landing.png)

A few features are worth mentioning:

- The design is clearly inspired by pixel art that resonates with the target audience but it manages to stay clear of pixelateed fonts, which makes it unique and defensible in the long run.
- _The use of aminated "emojies" makes the page "live" yet minimalistic and very easy to implement and develop further_ (a big win for a startup since usually, animations are one of the most time-consuming parts of front-ends).
- This solution also solves another common problem: animtaions often become too anoying and distract the reader from the content (while looking impressive on the surface). The Hito animations are subtle — they keep the content at the forefront.
- Having two types of illustrations (emoji-like and linear), the brand book becomes highly adaptable to different mediums. This allowed the startup to secure a future-proof style without overinvesting in costly design process from the very beginning. See below some draft for mobile app interfaces and packaging.

To fully experience the final product with all its animations and little nice touches, visit a copy of the site: [click to see it live](https://playful-cat-d59258.netlify.app/).

![mobile](/images/posts/hito/ui-and-packaging.png)


Simple and scalable: design code for a hardware wallet


"Let's just build the damn thing — and see what happens!"

That's what you inevitably say when you realize that wireframes, fake buttons, or no-code solutions won't do the trick in the case at hand.

When the only way forward with your idea is to build "the damn thing" — as minimum viable as they get — and see how it performs.

It's delicate. You have just a few engineers at your disposal (it might be a startup or a new initiative in a big org), you don't care how clean their code is (they will still do), and you don't think twice about scalability (yet you'll be punished for that later if you are lucky) - you just need to get results as soon as possible.

At this stage, _the speed of development becomes crucial. Slow startups die fast._ Here are a few thoughts on how to prevent this unfortunate outcome — and build prototypes and MVPs faster.

## Unified tech stack

Building everything on JS — React/NextJS for frontend, NodeJS for the backend, and React Native for mobile — was one of the best decisions we made in the last project. For a small team, JS is a lifeline. The JavaScript stack covers all of the needs of most early-stage projects and prototypes. The advantages are as follows:

- flexibility: we could move front-enders from web to mobile and back depending on the current needs;
- code sharing: while you cannot directly copy-paste code between, for example, React and React Native, we could still reuse lots of logic in terms of API requests, state management, etc.
- our tech lead working mostly on the backend could review the code of junior engineers and help them when they were stuck.

## Leveraging frameworks and libraries

I noticed that ambitious developers often default to building "perfect solutions" from scratch. But when you test ideas, it's much better to leverage already existing tools, frameworks, and libraries — instead of reinventing the wheel.

The key here is **to make sure that your tech lead shares this notion, that she enjoys working with libraries and frameworks, and recognizes the advantages of this approach for an early-stage initiative.** If, on the contrary, she defaults to building "perfect solutions", you're screwed.

## "What have you already used?"

Let's face it: any experienced developer can figure out how to leverage any existing framework or tool. They will simply read the docs, poke around them, and voila! The problem is that reading and experimenting takes time — and time is money.

That's why I learned to ask which libraries the coders know well — and opt for them if it's possible.

- Example: our tech lead had had a lot of experience with Strapi before joining our startup so we opted for this library to manage our backend. The speed of development was really astonishing.

## Good old is better than the latest

I also noticed that some developers have a natural tendency to choose the trendiest and newest solutions. "The trendiest and newest" might also mean unproven, buggy, or not having good docs or enough support from the community. It also means that replacing team members will be more problematic or not optimal (assuming your initiative survives long enough to have problems on the staffing front).

- Example: when someone suggests that we should employ Hugo or Astro for static page generation, I ask: what's wrong with the good-old NextJS?

## When the time comes, build your own thing

A paradox: sometimes, building your own thing is faster indeed. **We once spent a few days trying to make a React Native component from one existing library work — and failed. Then we built our own component in just a day.** The catch here is that you rarely know such things in advance. So the right strategy is to be vigilant — and change your tactics as soon as your team starts lagging behind your estimated schedule with the implementation of a certain ready-made solution.

## Simplifying layouts

Some layouts are easy to build — and some are tricky. Designers do not always even think in these categories, and it's critical to constantly remind them of this. Is a certain element really needed? Is that animation necessary? _Making changes in Figma can take a few minutes — and entail hours if not days of development._ While for the end user, there might be NO REAL DIFFERENCE whatsoever.

- So I try to involve engineers early on in the design process so they can have their say. I also encourage them to actively participate. The worst thing you can do is dump designs on your tech team — and expect them to deliver the results fast.

## You can also reuse designs

By the way, this approach of leveraging existing frameworks and tools in development can be applied on the design level as well. There are tons of design elements out there — icons, pictures, animations — that can be reused. Lots of them are free or cost pennies. You just need to tweak them a little so that they will match your style guide — but it's much faster than making something from scratch.

## The M in MVP

Products can — and should be — simplified as well. What is crucial? The ability to decide what NOT to do, and how to simplify things and cut off functionality without compromising the user experience to deliver not a half-baked prototype but a product that feels real and still does the job, despite being an MVP.

I’d argue that **this skill — managing scope based on how much capacity you have — is the most crucial in product development. Maybe in life too.** People often underestimate the complexity of their decisions/solutions — in online businesses and offline ones equally. At least I witnessed that almost daily in all the companies I worked for.

Simplification is the key. Do we need an app — or can we just make do with a web solution? Do we need locations on a map when we can show them in a list sorted by distance? Does marketing need all these tricky types of discounts — or can they maybe work with just one? Every decision has to be justified from the user's perspective.

## Word of caution: fixating on speed too much might slow you down

Life (and business) is the art of balance. I'm fully aware that the problem with the described approach might be that the team might feel too limited and demotivated at some point — especially if you go on in this "prototyping mode" for too long.

If you as a developer only get to employ the tools you know and can't get a new toy (framework) to play around with, where is the fun in it? Also, the whole idea of an engineer's career is to constantly acquire new tech skills by doing new things. Your designer wouldn't be super thrilled either if you limit them too much.

So overdoing what I've just described can be harmful as well.


8 strategies to speed up software development and ship prototypes faster


One of my bosses didn't believe in customer interviews.

"I've always felt it was a waste of time," he confided in me at some point. "I know they are valuable, in theory. In reality, you invest a lot in finding leads and talking to random people and get only superficial stuff in return."

It seemed that for some reason, he couldn't get any value out of his conversations with customers.

I used to work as a reporter (a long time ago, basically in my previous incarnation). And my interview skills were considered above the industry average. I was always able to get value out of my conversations.

This got me thinking — _how much of what I know from my career in reporting translates to customer interviews?_ I realized that since I switched to product work, I have unconsciously followed the same technics that I had learned as a journalist.

So I put together a short manual explaining my approach to interviews.

## "Interesting" is never interesting

All reporters quickly learn not to ask people to "tell them something interesting." Because most people will draw a blank in this case. Asking "what was the most interesting in X" or "What is your opinion on Y" is like asking someone to tell you a joke all of a sudden. You can know dozens of good jokes, but without any context and natural flow of conversation, the brain will just refuse to produce any. The same with "interesting" things — or any straightforward theoretical question. It doesn't mean that nothing interesting or noteworthy happened. It only means that this is the wrong way of having a conversation about it.

## Step by step

What's the alternative? I always got the best results when I asked about what actually happened, what people thought about it, and what they did as a result. Basically, I always asked people to walk me through their personal story as it developed — like it was a sequence of events in a movie — so I could understand the logic of their actions. I did it even when the focus of my article wasn't the story itself. Why? It turned out that **based on events, it was easier for people to recall things and to give me "interesting" (deep) stuff — insights, revelations, observations, and killer quotes.**

## The more context, the better

I always cast a wide net and never limited my questions to the time or the subject I was interested in. Usually, I'd want to have a much broader context. The rule of thumb was: the deeper you want to dig, the more context you need, and the further back in time you go. Writing a story about restaurant operators and their experience with delivery aggregators, I'd probably start with when they decided to open a restaurant and why and how they did it — even if it was a decade ago.

## React! (Not the framework but the verb)

How I started as a rookie: I'd have a paper with a list of questions and ask them one after another no matter what. Of course, I got superficial dull answers. After some practice, I completely changed my approach: I threw away the script and instead listened actively, reacted to every word I heard, and then constantly asked follow-up questions to dig deeper into the subject. _This ability to "listen actively" turned out to be the key to everything. In daily life, people almost never really listen — they usually just wait till you finish talking to say their own piece._ Active listening consumes a lot of energy, by the way. After a 2-hour interview, I was usually so tired that I couldn't do anything meaningful that day.

## The power of arguing

A big part of this active listening thing was... arguing. At first, I was afraid to do that even when I heard something dubious. As a result, I ended up with an interview that I couldn't really use for the article because too many things didn't make any sense — or required additional explanations. So I had to go back and ask follow-up questions. Then I realized that **the more you argue during the interview without accepting everything you hear at face value, the better material I got — so I started making counterarguments at every corner.** When you make a counterargument, you force your vis-a-vis to better explain themselves, and you help them refine their argument. I would often argue even if in reality I personally agreed with them.

## Using a proxy

Sometimes it was beneficial to be super direct and even "aggressive" — and have a somewhat heated discussion. But more often, I didn't want to alienate my "opponents." In this case, I presented my arguments as not my personal opinion but as something that certain people might think. This mitigated the risk of sounding hostile — it wasn't me who was arguing, I was just a proxy giving other people's perspectives. I would say something like: "If I publish this, many people would say that..." This was enough to move the conversation forward.

## The benefits of being dumb

Junior reporters — me included — were often afraid to admit that they didn't understand something that was said. They just pretended that they did. The opposite tactics brought me much better results — I quickly learned that **openly admitting your lack of knowledge was the best way to extract information.** Counterintuitively, it gained people's respect. They saw that I was actively engaged in the conversation processing their every word instead of just blinking and nodding to whatever they were saying.

## Why-why-why

I was a business reporter, so I knew a popular business concept called "5 why analysis." It posits that you should ask "why" at least five times to get to the root cause of any event, trend, or problem. This was the framework I always kept in mind because it was 100% applicable to interviews. Often, just asking "why" a few times would give you much deeper insight.

## Never let it slide

It's easy to get carried away in any conversation and forget about the question you asked — especially if your respondent is talkative. People often start answering your question, then remember something related, and sometime later nobody can recall what led to all this... When I just started, it happened to me quite often — and my interviews had some big nasty gaps in them. I learned to "keep my eye on the ball" — and if I didn't get what I needed, to return to my initial question even after a five-minute detour.

## Being open to ask for openness

Whenever I wanted to dig deeper and get really interesting insights, I inevitably encroached on people's personal stuff. I knew they had to feel comfortable enough to share something more or less intimate. I found that the best way to create a safe space for them was to openly explain my goals as a reporter (so they'd have context and understand my motivation) — and to be open myself and share some personal stuff as well. If there was a logical opportunity to do that in the conversation without going into too many details and wasting precious interview time, I'd always seize it. When one person only asks questions and the other has to answer them, such conversation reminds me more of an interrogation.

## Keeping the language casual

Finally, it was simple as that: I'd keep it casual. As a business reporter, I met "Forbes 100" folks, and it was hard not to be intimidated at first, but over the years I learned to be respectful but still relaxed. _As a reporter, you generally want your sources to give you great quotes. Great quotes are never formal. So I figured that if I wanted my vis-a-vis to be informal in their speech, I needed to be informal myself._ It usually worked.

---

That's about it. Since I started doing customer interviews, I found that most of these technics translated quite nicely to business research.

The biggest challenge was — and still is — time. Such a quality interview needs at least 30 minutes, and you as a PM don't always have that much. But if you want to dig deeper, this might be the only way.

At least this is what I try to explain to my boss.

## Bonus track 1 "The Mom Test" classics

If you haven't read this book yet, you should. Here are a few notes I made for myself after reading it:

- never pitch your idea to your respondents (they will lie, say nice things so as not to hurt your feelings — and will never buy your stuff when you launch it);
- avoid asking about opinions, generalizations, and hypotheticals (people will lie because they want to appear better than they are);
- ask about past actions, the more precisely the better: "How often do you go to the gym?" is worse than asking "When were you at the gym last time? And before that?"
- do your interviews in person to really connect with the people for the best result (after the pandemic, we can say that you can just as efficiently do it over Zoom).

## Bonus track 2: some advice from Reforge

Last year, I was also [studying with Reforge](/posts/one-year-with-reforge). As the number-one cust dev technic, interviews were covered in a few programs, including "User Insights for Product Decisions" and "Finding Product-Market Fit." Here are a few notes I made for myself:

- 25% of your research time should be spent on planning the interview — it's always better to do fewer interviews but better prepared than the other way around;
- super important to debrief after each interview as soon as possible - 1) this helps you make better notes when the conversation is fresh in the memory 2) and your reflections can inform how you do your next interview;
- as a rule, don't go to the next interview, if you haven't processed the previous one;
- iterate on your interviews as you iterate on your product or your team's processes — you can change what questions you ask and how you ask them based on the results you've got in the previous interviews;
- it's important to source respondents properly: PMs often talk to the people who are easy to access but who are not the real target audience; also it's beneficial to include not just your "now" audience but also your wider "future" audience;
- usually, it's enough to do 3-5 interviews for each customer segment (which might be an undertaking if your product is marketed to many segments)
- if you hear radically different opinions, it's a signal that this is the area of your riskiest product assumption.


How I do customer interviews (after 15 years of doing interviews every day)


Today, I finished my 8th — and last — program on Reforge.

Reforge comes up most often on this subreddit when someone asks where to go if you want to learn something useful. It is probably _the most popular educational institution for product, tech, and growth people._

I joined the program a year ago, having paid 2K out of my own pocket for the annual membership.

I'm writing this very much subjective review partly to reflect on the experience for myself — and partly in hopes of helping those of you who might be deciding if it's worth it.

(Spoiler alert: it is. Mostly)

## My angle: focus on product and growing orgs

I started migrating to product work a few years ago from a senior role in comms. It happened naturally when I was assigned the task of managing a complex b2b website.

Only less than a year ago I switched to 100% product work, and from b2b and a company of 700 employees to b2c and a company of 10.

I have little interest in working for big orgs anymore. This might have impacted my perception of Reforge, as I am more interested in building products and finding (and expanding) product-market fit than navigating the politics of a big organization with lots of stakeholders.

## What Reforge is in a nutshell

Once you go beyond the paywall, you get access to the following:

- live programs, in which you can participate via Zoom (usually, it's one 2-hr session per week — and 4 weeks); currently, you'll get 4 of those per year;
- for each program there is also a few hours of theory for self-study - I say "hours" because although there are texts and graphs, these texts are narrated in a video along with graphs and charts so you can listen to the text instead of reading it.
- you also get access to all the past programs materials/recordings, and previous live sessions including;
- programs cover 4 key areas: product, engineering, growth, marketing; currently there are 20 of them (but some an outdated and some overlap - for example, the longest "Growth series" encapsulates programs on monetization, retention, and experimentation).
- Reforge slack - it's used to communicate during live sessions and to discuss stuff in related channels,

## Why Reforge live programs didn't do it for me

I took part in only 2 live programs instead of 4. Partly because the timing didn't fit my schedule. Partly because I quickly lost interest.

Usually, there is a guest who helps you understand the theory by walking you through a real case study. Participants are prompted to answer questions and write answers in Slack. Sometimes, moderators will pick someone to appear live and voice it.

My problems with live sessions were as follows:

- in general, useful insights per hour were ten times less frequent in live sessions as compared to materials for self-study; this shows in my notes — sometimes, I didn't even make a single note from a live session;
- with 200-300 participants in a session from all over the world, you cannot realistically expect a meaningful conversation — so the whole interactivity thing is hardly a dealbreaker;
- everything is recorded, so you can listen to the event afterward without losing much value - on a 1.25/1.5 speed.

## Why Reforge Slack wasn't that useful

It's well-known that a great deal of value people get from universities and MBA programs is the network they acquire during their studies. Some even argue that it's the only value of traditional education.

It seems like with a Slack channel, the Reforge team also tries to create opportunities for members to connect and build their networks. But unless you're between jobs, it's really hard to actively engage on Slack.

I tried following conversations in a few channels but quickly gave up. I had enough of "slacking" at work.

Other Reforge members probably suffer from the same problem. Many questions in channels remain unanswered or get only a couple of responses. Some channels don't have any activity to begin with. I'm based in Berlin, and sometimes a couple of months pass without any update in a dedicated Berlin channel.

_"Talk-job-openings" is probably the most active of all channels, and there are lots of job offerings posted daily._ For those actively looking for opportunities, it's probably a really useful source, especially for those based in the US.

## Best value for money on Reforge: self-studying

The best value I got from Reforge was those lessons and materials made for self-studying in preparation for live sessions.

Usually, Reforge programs are made in collaboration with accomplished practitioners from top companies — and it shows. Lessons cover the most pressing areas of business across product/engineering work and growth. They give you the most useful frameworks and tools to deal with real-life situations.

Overall, the content is of high quality: well-structured, to the point, with a nice balance between theory and real practice. Thanks to the quality of this content, I don't regret spending my money on Reforge membership, even though the other parts of the package weren't that useful for me.

## My ranking of Reforge programs

**Absolute best: the growth series (117 lessons)**

This is the heart of the entire curriculum, made by Reforge founder, Brian Balfour, and based on his concept of "loops." It covers the key aspects of any product: acquisition, retention, and monetization — and it's an absolute must.

**3 really useful programs for PMs**

These 3 I found the most useful for me:

- User insights for product decisions (36 lessons) - everything a PM needs to know about all kinds of research
- Finding product/market fit (37 lessons) - useful frameworks for developing new products from scratch
- Experimentation and testing - a deep dive into everything related to... experimentations and testing (77 lessons)

**Less value but still good**

- Mastering product management (38 lessons) - some advanced concepts of product work
- Technical strategy (31 lessons) - how to manage tech debt and stuff like that
- Engineering management (35 lessons) - for eng. managers, still interesting to understand how your counterparts think and operate
- Product management foundations (41 lessons) - good content, although seemed a bit basic to me

There is one program I started and dropped because it seemed extremely boring: Data for product managers. Maybe I'm just not the TA.

## Bonus 1: how I cracked so many programs

My secret is simple: a lot of chores.

Whenever I do dishes or clean up (and I do that, obviously, every day), I have my AirPods on — and also a laptop somewhere nearby so I can take a note when I hear something interesting. This approach allowed me to make Reforge programs an intrinsic part of my life this past year and progress almost effortlessly.

It also turned chores from "wasted time" into something really useful and enjoyable.

## Bonus 2: what I'd do if I were PM at Reforge

This is funny since Reforge has been built by gurus of product management. But still... It's an interesting exercise to think about how I would develop this to mitigate the weak spots of the product (weak from my perspective, of course).

I think I'd look into this: will it be possible to introduce some exercises to the learning process?

Reforge is now something like a programming course on Udemy. Can it be turned into something more interactive (but still automated) like a program on Codacademy? This can add more practice and help "students" engage with the material while building and analyzing cohorts for example.

The best solution would be to build it so that the task can be completed only in collaboration with a few other members. It will enable building networks for members, especially if you group members based on their location.

## Am I paying for the next year?

Nope. It feels like I extracted all the value from existing programs. It will probably take a decade to put everything I learned into practice. And this is what I plan on doing :)


1 year with Reforge: was it worth $2K?


This might seem bananas to you, yet it’s real: as a radically transparent enterprise, Dodo Brands **makes its sales data totally open** to the public.

You can study the entire network’s metrics — or dive deep into the performance of any of the company’s 700+ foodservice locations across 15 countries. Dodo’s management strongly believes that openness…

- builds trust for partners (prospective franchisees);
- provides more security for potential investors;
- encourages benchmarking across the chain and ultimately improves performance.

This premise posed a challenge for the team responsible for the development of Dodo’s corporate website: _how to leverage transparency and make troves of data accessible for users with different agendas, knowledge, and backgrounds?_

## Lost in data: what research revealed

Every unit in the network — be it a pizza place, a coffee shop, or a doner kebab joint — has a dedicated page on the website. Since sales are processed by Dodo’s proprietary tech platform, this enables streaming key data right on the website via APIs.

User research revealed a few issues with the way the data was presented in the website’s initial version.

1. Users need context to interpret data. 27-minute delivery — is it good or bad? The answer depends on the context. If the network’s average is 35 minutes, a 27-minute delivery seems impressive — and not so much when most of the units deliver orders in under 25 minutes.
   ![Old Dodo site example](/images/posts/theory-of-relativity-in-data/dodo-site1.png)

2. Users tend to get lost in the abundance of numbers. The initial spreadsheet-like visualization didn’t provide enough stimulus to guide users’ attention and differentiate between key and secondary metrics.
   ![Old Dodo site example](/images/posts/theory-of-relativity-in-data/dodo-site2.png)

3. As a result, the page provided enough value neither for experienced users (too little actionable data) nor for the users browsing the website for the first time (too many metrics, easy to get lost).

## Putting numbers in a broader context

The first step the team made was to **combine the unit’s metrics and network averages in one graph** — and put them on a vertical bar relatively to their place on the possible range of values.

The unit’s metrics are represented by the red lines, while the gray lines represent averages.

![Dodo Unit Page](/images/posts/theory-of-relativity-in-data/dodo-site3.png)

In this example, it’s relatively easy to notice that the unit in question performs better than the average across all metrics — and that in terms of average ticket, it lands at the very top of the range.

This approach also allowed the team to introduce a new feature for the power users: like using filters to change the context (see averages for a specific country or the brand in question).

## Getting rid of complexity

The next important step was to make _a rather radical decision to use the same UI for every metric_ on the page. This entailed challenging some norms and industry conventions.

For example, traditionally, foodservice companies differentiate sales in dine-in, takeaway, and delivery. A conventional “pie” diagram would be a safe choice in this case.

In reality, the difference between dine-in and takeaway sales is insignificant, and % of delivery sales appears to be the most important for the financial assessment. And that’s exactly what UI reveals.

![Dodo Unit Page](/images/posts/theory-of-relativity-in-data/dodo-site4.png)

The same logic is applied to the sales channels. Instead of breaking them down by possible sources (contact center, website, app, register/cashdesk), the page focuses on the most significant one in the digital age: % of app sales.

Using just one type of visualization also **reduces cognitive load. Once a user figures out how the interface is designed, reading data becomes extremely easy.**

## Details matter: polishing the interface

The team made a few smaller decisions to improve UX/UI.

1. There is value in showing the precise range of a metric, especially for power users. They can access them by hovering over the “?” signs. This way, these additional data don’t clutter the main interface.

2. The layout allows having different numbers of bars in every row. This gives flexibility, making it easy to add or remove new data in the future.
   ![Dodo Unit Page](/images/posts/theory-of-relativity-in-data/dodo-site6.png)

3. Showing data on mobile is always challenging due to the limited size of the screens. The team found a solution in turning every bar into a separate card. Cards are grouped together in a slider element.
   ![Dodo Unit Page: mobile](/images/posts/theory-of-relativity-in-data/dodo-site7.png)

## The result

After internal testing, the design went into production, and the new version of the unit page was launched in Spring 2022. See it live at dodobrands.io.

![Dodo Unit Page: full image](/images/posts/theory-of-relativity-in-data/dodo-unit-full.png)


Research

Product

Design