A design system for a product
We reduce the interface to a set of repeating parts with rules for using them, so new screens get assembled rather than invented. Starts with a free review.
15–45 days
4 services
UX audit, prototype, product page and design system for websites and stores
“Design” here covers four separate jobs, and each answers its own question. A UX audit asks why people reach the store and still don't buy: we walk the buyer's path and show where it breaks. A prototype settles what goes on every page before any coding, in grey blocks with no colour, so a change means moving a rectangle rather than rewriting code. The product page gets its own job because that is where the decision to add to cart is made. A design system is for a product that has grown to the point where every new screen is invented from scratch. You don't need all four. If the site is live and has visitors, the audit is usually the place to start; if there is no site yet, start with the prototype. The first review is free.
- Jobs in this area
- UX audit · prototype · product page · design system
- each has its own scope and result; you can take just one
- Timelines
- 5–45
- business days
- audit 5–15, prototype 5–20, product page 10–30, design system 15–45
- Platforms
- Mostly OpenCart and Next.js
- websites and stores; the prototyping cases include a one-page site and a corporate site on Next.js
- The result
- Stays yours
- ownership transfers after full payment; a prototype can go to another developer
- First review
- Free
- 1–3 business days, telling you which job to start with and whether you need it now
Design systems
Prototypes
Research
Stores
Who it's for
Situations where this service delivers results
Scenario 1 of 4
Visitors, but few orders
People come in, scroll and leave, and there are as many theories as there are advisers: the button colour, the home page, a whole new site. A UX audit replaces guesswork with a list of specific places where the buyer stops, and why. The phone is walked through separately, not as a shrunken browser window.
We'll review your situation in a free auditScenario 2 of 4
The site is only planned, or being rebuilt
The most expensive changes arrive after coding, when every “where is the delivery page?” costs a day or two of work. A prototype moves those conversations to the start: you approve the contents of each page in writing, and the development scope is counted from that.
Scenario 3 of 4
People reach the product page but don't add to cart
They found the product and the filters worked, and right there they can't see the price with delivery, whether it's in stock, or the one parameter they choose by. We rebuild the page in the order of the questions buyers ask your sales staff, not the order the platform happened to lay out.
Scenario 4 of 4
The product has grown and sprawled
Buttons, fields and messages that do the same thing look different from screen to screen, and every change has to be hunted down everywhere. A design system reduces the interface to a set of parts that are already decided — once the product exists, not in place of it.
What's included
Complete list of work and what you get as a result
- A free first review that tells you which of the four jobs to start with — and whether you need any of them right now
- Each job with its own scope and timeline in business days: you can take one without ordering the rest
- The buyer's path walked as a buyer: search, catalogue, product page, cart, checkout — with the places where it breaks
- The phone as a separate path and a separate decision in every job, not a desktop squeezed onto a narrow screen
- An explicit “this is an assumption” label wherever there is no data to check against, instead of guesses passed off as facts
- A result approved in writing at each stage, which the next job is scoped from: development from the prototype, fixes from the audit
- Testing on awkward cases: a product with no photo, a very long name, twenty specifications, an empty state
- Analytics events on the problem steps before any changes, so the effect shows in your data rather than in our words
- Work under a contract with a 30-calendar-day warranty from the day the acceptance certificate is signed
Process steps
Transparent stages with approval at every step
Reviewing the task
We find out what already exists: a live store with visitors, an idea with no pages yet, or a product that has sprawled. That decides which job to start with — and whether to start at all.
Audit, if the site is already live
For a site with visitors, the first step is walking the buyer's path, separately on a phone, and checking it against analytics. The output is a list of findings sorted by impact and by the cost of fixing.
Prototype before coding
The list of pages and the contents of each in grey blocks, for wide and narrow screens. We approve it in writing: the scope of mockups and development is counted from the prototype.
Mockups and the product page
Visual design on top of the approved structure. For a store, the product page separately — with variants, honest stock status and delivery cost, tested on awkward products.
A system, once there are many screens
We derive a set of components from the screens you already have, with all their states, and move several real pages onto it — as proof that the system holds up in actual work.
When this service isn't right
What's not included — so there are no surprises at delivery
- Promises of higher conversion or sales: design removes obstacles, but people buy because of the product, the price and your sales team
- Judging the look as “like it / don't like it”: only the places where a person stops, and the reason
- Writing page copy, product descriptions or product photography — we tell you exactly what is needed but don't produce it
- Research with recruited live respondents: the audit relies on walking the path, comparison with the niche and analytics data
- Fixing the findings as part of the audit itself: that is a separate job with its own estimate
- Rebuilding the whole product onto a new system in one go: new screens go straight onto it, old ones when they need touching anyway
FAQ
Questions asked before starting
Where do we start if the site is already live?
Usually with a UX audit. It shows exactly where people stop, and quite often it turns out the whole design doesn't need redoing: fixing a few steps on the product page or at checkout is enough. A new design without that knowledge is a blind bet that can remove what was working too.
How is this section different from the “UI/UX design” service?
“UI/UX design” is mockups for development: visual design in Figma for several screen sizes, handed over to a developer. This section collects the work around mockups. The audit and the prototype come before them: the first shows what to change, the second fixes the structure. The product page and the design system are taken on without a full redesign too.
Can we order just a prototype or just an audit?
Yes, each job has its own scope, timeline and result. The prototype stays yours whether or not you continue with us, and you can hand it to another developer. Some of the audit findings your own people will be able to fix — we mark which ones explicitly.
When is a design system needed, and when is it too early?
It's needed when parts that do the same thing look different across the product and every new screen gets invented from scratch. It's too early when there is no product yet: a system built from ideas rather than real screens almost always turns out to be about the wrong thing. Then it's more honest to start with a first version and derive the system from it.
Do we need a new product page or a redesign of the whole store?
If people reach the product page and don't add to cart, while the catalogue and search are fine, the product page is enough. If the problems are spread along the whole path, start with an audit: it will show whether the issue stops at the product page. Sometimes the cause isn't design at all but empty product specifications — then we will say so at the review.
Do you design for OpenCart stores?
Yes, it's the main platform we work with. Design for it takes into account how the theme is built inside: in older themes markup and logic are often tangled together, and a mockup that ignores this falls apart during coding. We built our own OpenCart theme precisely as a system with a set of settings, so we have a good idea of where it hurts.
Will design increase conversion?
We don't quote percentages: an honest figure depends on the store, and one promised in advance is a sales pitch, not an estimate. Design removes obstacles on the buyer's path; whether a person buys also depends on the product, the price and your sales team. To make the effect visible, we set up analytics events on the problem steps before changing anything.
Not sure which service is yours?
Describe the task in your own words — we will tell you where to start and whether you need what you came for. If you do not, we will say so.
- Reply within 2 hours
- No commitment
- We work under a contract