All services

    Product & UX/UI Design

    A good digital product doesn't end with a finished design. It has to be well structured, easy to use, consistent through development, and checked in a real environment before it reaches its users.

    We work on new products as well as on existing platforms that need a redesign, new functionality, or an improvement to the user experience.

    Besides the product structure and the UX/UI design, the work covers prototyping, testing, a design system, handover to development, and QA on the built product. We check whether what was built matches the design, how it behaves across different situations and devices, and fix the problems we find before the final handover.

    • UX analysis and product structure
    • Information architecture
    • User flows
    • Wireframes
    • UX/UI design
    • Interactive prototypes
    • Usability testing
    • Responsive design
    • Accessibility
    • Design system
    • Handover to development
    • Design QA after development
    • Checks on functionality and edge states
    • Finding and fixing visual and functional problems
    • A final check before the product goes live

    A good interface doesn't just look good. It makes the decision easier.

    In e-commerce every visit has a cost - whether it came from advertising, Google, social media or organic search. If a customer reaches the shop but can't find the product easily, doesn't understand the difference between the options, or struggles at checkout, more traffic won't solve the problem.

    UX/UI design works on exactly that part of the journey - from finding and choosing a product through to the cart, the payment and the completed order. Every unnecessary obstacle along the way makes it more likely the customer gives up before they buy.

    The goal isn't simply to make the shop prettier or to remove a few clicks. It's to reduce the reasons customers drop off along the way, make buying easier, and build an experience they have a reason to come back to.

    The screens nobody demos are where products fail

    A demo runs the smooth path. The data is there, the account is full, the connection works. Nobody's first day looks like that.

    Their first day is an empty dashboard with nothing in it yet, a payment refused, an invitation to a team they don't have permission to see. Those screens decide whether someone stays, and they are the ones that reach a developer as a shrug.

    So we design them. Empty, loading, refused, expired, half-finished - each one written down, so the answer exists before the question comes up in the middle of development.

    • Empty screens, before there is any data
    • What an error actually tells the user
    • Who is allowed to see and do what
    • The awkward cases, not just the demo path
    • Loading and waiting
    • The first session of a brand new user

    Design a developer can build without guessing

    A design file is only finished when someone who sat in none of the meetings can build from it. Until then it is a picture of a product.

    The test is boring and specific. What does this button look like while it is loading. What does the table do with one row, and with four hundred. What is the smallest screen this still has to work on. If the file does not say, a developer decides late at night, and that decision ships.

    So the handoff is made to be read, not admired. Components with their states, spacing that is a rule rather than a decision taken on the day, and behaviour written down wherever a static screen cannot show it.

    The awkward questions get answered in the file, not in a message thread while your team waits. And when the product needs a site to sell it, or a visual identity it does not have yet, that is the same system carried outwards rather than a second one invented.

    How we work

    The order is deliberate. The cheapest place to change a product is a conversation, then a sketch, then a screen. Code is the most expensive place, so we settle as much as possible before anyone writes any.

    Learn the product

    What it does, who uses it, and where people get stuck today.

    Watch real use

    A few hours with actual users usually settles the arguments the team has been having for months.

    Map the flows

    The order of the steps, the decisions, and what the product must know at each one.

    Sketch the screens

    Layout and hierarchy in grey, while changing them still costs nothing.

    Design the interface

    The visual layer, every state a screen can be in, and a system to keep the tenth one cheap.

    Prototype and handover

    Something clickable to test with, then files a developer can build from without asking us.

    What you actually get

    Screens are the part you see. Here is what the business is left holding once the design is done.

    • 01

      A product that explains itself

      Someone arrives, works out what it does and who it is for, and reaches the first useful action without being taught.

      A product that explains itself
    • 02

      Complexity that stays readable

      Dense screens are where products get abandoned. Grouping, hierarchy and restraint do more for them than redrawing the charts.

      Complexity that stays readable
    • 03

      Flows that survive the awkward cases

      Out of stock, a card refused, a session that expired mid-basket - the path holds when things don't go to plan.

      Flows that survive the awkward cases
    • 04

      A system, so the tenth screen is cheap

      Components, states and rules already decided, so a new feature arrives looking like it belongs instead of starting an argument.

      A system, so the tenth screen is cheap
    • 05

      Something real before you pay to build

      A clickable version to test with users, show a partner, or hand to a development team with the decisions already made.

      Something real before you pay to build

    What does your product cost you every time a user has to work it out alone?

    Send us the product as it stands - a link, a login, or the screens you have drawn so far. We'll tell you where people are getting stuck and what it would take to fix the structure underneath.