People don't finish the task
They start the request, the purchase or the sign-up, and give up halfway through, always at the same point.
Design
UX/UI design: interfaces that need no manual
The structure, the journey and the look of a digital product, decided before any code gets written.
Who UX/UI design is for
UX/UI design covers the two halves of a digital product. The experience, or UX, is the journey: what steps someone takes, in what order, what they need to know at each point, and where they usually give up. The interface, or UI, is what you see and touch: screens, buttons, forms, error messages, typography and colour.
It's a service for anyone about to build a website, a shop or a platform who wants to decide the things that matter before paying for them in code. It's also for anyone with a product already running but with poor numbers: visits that go nowhere, abandoned baskets, forms started and never submitted, support calls about tasks that should be obvious.
After the design comes the build, in web application development or in building the website.
Problems this service solves
The symptoms that typically bring a digital product to this point.
Customer support explains the same thing, every time
If the same question comes up every week, it's the interface causing it.
On a phone, it's a different story
What works on a computer becomes cramped, unreadable or unusable on a small screen.
Every screen was made its own way
Different buttons for the same action and inconsistent wording mean relearning on every page.
Too many features
A lot got built, little gets used, and what does get used is buried under everything else.
An interface that needs a manual has already failed before it opens.
How we work
Designing is deciding. The earlier you decide, the cheaper it gets.
Understanding the business and the people
We talk to whoever knows the customers and, whenever possible, to the users themselves. We define the main tasks the product has to make easy, because they can't all be priorities.
Structure and journey
We organise the content and map out the path for each task, step by step, in simple wireframes with no colour. Discussing the structure at this stage takes minutes and saves having to rebuild later.
Interface
We apply the brand identity defined in branding, starting with the phone version, and we also design the states that usually get forgotten: empty lists, errors, loading and confirmation messages.
Component system
Instead of loose screens, we deliver reusable pieces with their own rules. That's what lets you add features later without the product losing its unity.
Validation and support
Whenever possible, we get real people trying it out before we build, and we stay close to the development team until what's on screen matches what was designed.
What you get
Enough material for any team to build without guessing.
Product map
Content structure and journeys for the main tasks, by user profile.
Wireframes
Screens sketched out, with no colour, to approve structure and hierarchy before the final look.
Final screens
Phone and desktop versions, with the error, empty and success states designed.
Component system
Buttons, fields, tables, alerts and cards, with rules for use and spacing.
Accessibility notes
Checked contrasts, minimum sizes and keyboard navigation order.
Working files
Access to the originals, so another team can carry the product forward.
Common questions about UX/UI design
The questions that come up most often about this stage of the project.
Can I hire just the design and build with another team?
You can. We hand over the screens, the component system and the technical notes in a format any development team can use, and we stay available to answer questions during the build.
Isn't this just making the site look nice?
Looking nice is a consequence, not the goal. The work starts by deciding what someone needs to be able to do, and in what order. A pleasant screen that hides the main button is a failed screen, however careful the look.
Do you test with users?
Whenever the project allows it. You don't need a big study: getting half a dozen people to try completing a task nearly always reveals the biggest problems, and does it before they cost money to fix.
What about accessibility?
It's built in from the design stage: enough contrast, generous tap areas, keyboard navigation order and alt text. As well as being a legal requirement in many contexts, it benefits everyone, especially on small screens and in poor light.
Does this apply to an internal platform, used only by the team?
It does, and it's often where the return is greatest. When a screen is used dozens of times a day by the same people, every unnecessary step multiplies into hours of work over the year.
Let's design before we build
Tell us what you want to build, or what isn't working in what you already have. We'll propose the scope of the design and what you'll have at the end.
Other services in Design