UX/UI Design

We design UX/UI for web and mobile applications and B2B systems - from analyzing user needs and early wireframes to the finished interface and a design system in Figma. We don't design screens in isolation from the product. We look at user journeys, analytics data and technical constraints to create a solution that's easy to use and can be built efficiently. After the product launches, we can come back to heatmaps, session recordings, analytics and user interviews, so that the next changes are driven by data, not assumptions.

Companies that trusted us

  • SAO
  • BlueApart
  • Balticon
  • MZURI
  • iSing
  • Global Parts
  • Mooveno
  • Dr. Marcus
  • Kwant
  • PadRes
  • SRDK Studio
  • HrHints
  • Home Chefs logo
  • SkinApe
  • ROMAY AG
  • Baza Cosmetics logo
  • SignorLeone logo
  • horyzont capital logo
  • KMR Restrukturyzacje
  • Jabłoński & Wspólnicy
  • mo-kancelaria logo
  • GrowTent
  • sunny family logo
  • PolandBuild
  • CeeCam logo
  • Konsorcjum Migracyjne

Interested in UX/UI services? Let's talk.

Up to 5 MB — documents and images

or email us directly at
hello@boringowl.io

The basics

What is UX/UI design and when is it worth investing in?

UX design is about how a product works and how users move through each step of a process. UI design is its visual layer - the layout, typography, colors, components and the way information is presented. In practice, we usually design UX and UI together. Good looks won't fix a badly designed process, and a well-thought-out user journey can lose its effectiveness because of a hard-to-read interface.

It's worth considering UX/UI design or a redesign when, among other things, users:

  • abandon a form or checkout at a specific step,
  • don't know what the next step should be,
  • regularly ask customer service about the same features,
  • have trouble finding important information,
  • take too many steps to complete a simple task.

It's also a good time for a redesign if the product's growth has led to inconsistent navigation, lots of exceptions and screens designed independently of each other. If it isn't clear yet exactly where the problem lies, we start with a UX audit. We analyze the key user journeys and identify problems along with recommendations and priorities for change.

„The mock-ups for our website and online store were completed as planned. We are very happy with their quality and polish. The efficiency with which they ran and delivered the project was impressive.”

Krzysztof Kornas — CEO, High Culture sp. z o.o.

Review from Clutch
Figma mockups of the Boring Owl website

How we work

How we work: from understanding the problem to designs that can actually be built

We start by understanding who uses the product and why - based on what you already know about your users, analytics data and conversations with customer service staff. Only then do we sketch the user flows, and the visual layer comes last. The reverse order happens often and ends with beautiful screens that have to be redesigned the first time they meet real data. We design in Figma and hand over designs in a form that can be built: with error states, empty views, versions for long text and for mobile. A screen looks great in a presentation until it meets a product name a hundred characters long - we settle those cases in the design, not in the code.

On your side, we need access to analytics or session recordings if they exist, contact with the people who handle customers, and a decision-maker who signs off on the direction. On our side are research, design, the component system and the handover for development.

The timeline depends mainly on the number of processes and unique views, the product's complexity and whether a design system already exists. Redesigning one key user journey can be a relatively small project. Designing a large platform or a B2B system with an admin panel will require a much larger scope of work.

Decisions

Design decisions that affect cost and product growth

A design system or individual screens? A component system costs more at the start and pays for itself by the third or fourth screen - because from then on, design and development are about assembling rather than drawing from scratch. For a short, self-contained project, it can be overkill.

How much UX research do you need before designing? The scope of research should reflect the project's risk and scale. Sometimes data analysis, conversations with the team and a few user tests are enough. For a larger product, or decisions where a mistake is costly, more extensive qualitative and quantitative research may be needed. What matters most is that key design decisions aren't based solely on the team's beliefs.

Consistency with what users already know. An unconventional, custom interface may win design awards and lose on conversion. Departing from established patterns is worth doing deliberately and in one place, not everywhere at once.

What not to do. Don't approve a design only on a large screen if your traffic is mobile. Don't design empty views at the end - a user's first contact with a product is usually exactly that, an empty screen. And don't treat accessibility as a post-design stage: contrast and navigation order are cheaper to settle in the design than to fix in the code.

Two designers drawing a diagram on a whiteboard

Scope

UX/UI design that ends with a working product, not a Figma file

The process can include workshops, information architecture, user flows, wireframes, prototyping and final UI design. We design high-fidelity mockups in parallel with a component library. This way, developers get a consistent system of elements with their states and behavior rules, instead of recreating each screen separately from a picture. Our advantage is that we design products we then build ourselves. So designers and developers can discuss solutions before development even starts.

That's how we created the online suit configurator for Signor Leone, the new financing application path for Horyzont Capital and CeeCam's B2B and B2C websites built on a shared architecture, among others.

Technologies we work with

Design

We design in Figma - from research and lo-fi wireframes to a design system with tokens that developers take ready-made values from.

Design implementation

We implement designs in React with Tailwind, and lighter websites directly in Webflow; the designer and the developer work from the same tokens.

Research

Design decisions based on user behavior

A designer's role doesn't end with handing files over to development. After launch, we can analyze heatmaps, session recordings, analytics data and feedback gathered directly from users. That lets us check whether the solution we designed actually works the way we intended.

We also run research before design starts: interviews, personas and journey mapping show where users really get lost in a process. At Horyzont Capital, it was an analysis of application drop-offs that showed which form fields to cut and which to move to a later step - the result was a simpler path to financing and fewer abandoned applications.

A design isn't finished when the mockup looks nice, but when it works in code with real data: long names, empty states and network errors. That's why we design with implementation in mind - the components in Figma have counterparts in the front-end library, and edge cases are mapped out before a developer ever sees them.

A designer working with a design system

Design system

Consistency that speeds up every new screen

We build design systems using a component-based approach: color and typography tokens, a component library in Figma and its mirror image in code. The first screens take longer, every one after that is faster, and the product stops drifting visually from page to page. The same system keeps our own website — the one you're looking at right now — consistent.

For client teams, we prepare usage documentation: when to use which button variant, how to write error messages, how to add new pages without breaking everything else. The HR Hints redesign in Webflow with a CMS put the website in the hands of the marketing team - they update it without a developer.

Real Estate / PropTech

For developers, real estate agencies, rental operators and PropTech companies, we build systems that bring order to sales, rentals and property data.

Real Estate / PropTech ↗
A render of the new SAO headquarters — a building with wooden louvres and a rooftop garden

PRODUCTS

Tell us what you want to build — we'll take care of the rest

We design and build mobile apps for companies and startups — from concept and UX/UI to development, backend, app store release and ongoing development. We work natively in Swift and Kotlin, and cross-platform in React Native and Flutter. We choose the technology based on the product, its features, the budget and plans for growth.

We build booking systems that take a booking, collect payment and handle cancellations without human involvement — for accommodation providers, equipment and space rental, and appointment-based services. We connect bookings with payments, availability calendars, a channel manager and service automation, so customers can check availability, book and pay without contacting staff.

We design and build B2B and B2C marketplace platforms — from an MVP to full-scale multi-vendor systems. We build the buyer and seller sides, commission models, payments, integrations and operator tools. A marketplace is two products at once: one for the buyer and another for the seller — we design both, together with the settlement model.

We design and implement CMS systems that let teams manage website content on their own — without involving a developer for every change. We choose the technology to fit the project and the way your editorial team works. We mainly implement headless CMS solutions, including Strapi, and help migrate from existing systems.

FAQ

Questions we hear before a design project

  • It depends mainly on the scope and number of unique views. Redesigning a few key flows can take a few weeks, while a complete product with multiple user roles and an admin panel is usually a project measured in months. We agree on the scope and timeline before the project starts.
  • The cost depends mainly on the number and complexity of views, the number of user flows, the scope of research and whether the project requires building a design system. A single key flow is priced differently from a full application with an admin panel. Once we understand the scope we prepare a quote matched to what actually needs to be designed.
  • We start by getting to know the product, its users and the problem we're solving. We then design user flows and lo-fi wireframes, and once the direction is approved we move on to hi-fi views and components. We also design error states, empty views, mobile versions and edge cases, so decisions don't have to be made on the fly during development.
  • We don't need a complete, detailed specification. If the product already exists, analytics data, heatmaps or session recordings are useful, as is the chance to talk with people who have direct contact with users. We also need someone on your side who knows the product's business goals and can make decisions about the project's direction.
  • A Figma file with the complete set of designed views, error states, empty views and mobile versions. Depending on the scope, we also deliver a component library or a full design system, along with descriptions of interactions that can't be shown in a static screen.
  • Yes. We can hand over the designs to your development team. We prepare mockups with developers in mind: with components, variants, states and descriptions of interface behaviour. We can also take on the whole process — from design through to implementation.
  • Yes. An audit is particularly valuable when a product is already live but it's unclear exactly why users drop off at a certain point or struggle with a specific action. The outcome is a prioritised list of issues and recommendations on what to fix quickly and what's worth redesigning.
  • If it's needed — yes. We use analytics data, heatmaps, session recordings and user interviews, among other methods. We match the scope of research to the product and the risk of the decisions: not every project needs extensive research, but designing entirely without data means basing decisions mainly on assumptions.
  • Not always. For a handful of screens, a full design system may be an unnecessary cost. For a product that will be developed over the coming months or years, a component library quickly starts saving designers' and developers' time and keeps new features consistent.
  • Yes. From the design stage we address contrast, interactive element sizes, navigation order and visible focus state. These decisions are much easier and cheaper to make in the design than to correct after implementation.
Let's talk

Let's build digital products for your company together