Algeria AgencyBranding & design
Repairing an interface without rebuilding it: where to start
A redesign is the most expensive answer and rarely the right one. How to find the layer the fault is actually in, and fix it there.
When an interface is not working, the proposal that arrives is almost always the same: rebuild it. That is the most expensive answer, the slowest, and the one most likely to reproduce the fault, since nobody has yet established where it is.
Most of what is taken for a design problem is a wording problem. Some of what survives that correction is an ordering problem. What survives both needs a developer, and it is a minority — but it is the only layer the original proposal ever considered.
This article is about that search and those repairs: separating a design fault from a speed fault, drawing up the list of blockages by watching rather than supposing, sorting fixes by cost, and knowing how to measure when you are too small to measure.
The article accompanying this one is about the design itself — the task as criterion, the thumb, target size, Arabic as its own layout rather than French reversed, the states nobody draws. It is worth reading first: it says how an interface is made, this one says what to do with the one you have.
A redesign is rarely the answer
A redesign has one quality nothing else has: it feels like the problem has been dealt with, because it changes everything visible. That is also its main defect, since it changes everything visible without having established what was responsible.
The reasoning that justifies it is almost always circular. The interface is not working, therefore it is badly designed, therefore it must be designed again. None of those three statements is measured, and the third follows from the second only if the second was verified, which almost never happens.
There is a hidden cost nobody counts as well: a redesign resets everything people had learned about your interface. Your regular customers knew where things were; they no longer do, and they write to ask you for six weeks.
The reasonable position is not that redesigns are useless — the section before last says when they are justified — but that they are a last resort rather than a first reflex. A failed repair costs a day; a failed redesign costs a quarter and leaves the same problem.
This article’s programme is therefore simple: establish where the fault is, fix it at the shallowest layer that will do, and only move up a layer once the previous one has been tried and was not enough.
A design fault, or a speed fault
Before anything else one confusion has to be ruled out, because it costs months: a slow interface is indistinguishable from a badly designed one, from the point of view of the person using it. They do not say "this is slow", they say "this does not work" and leave.
The distinction takes one minute and it is mechanical. Open the page on a phone, on an ordinary connection, and count. If the first useful content appears after several seconds, or if a button sits inert for a moment after being touched, you have a speed problem and no design fix will improve it.
That is especially true here, where most visits happen on a phone and where connection quality varies a great deal between neighbourhoods. An interface tested in the office, on Wi-Fi, on a computer, is tested in the conditions where the fault is invisible.
If speed is responsible, that is not this subject — the article on slow sites covers that chain — and it has to be dealt with first, because any measurement taken on a slow interface measures the slowness. Fixing the design first is repainting while the floor is unstable.
Once that possibility is ruled out, and only then, the rest of this article applies. The check is short and it regularly saves an entire project.
The list of blockages is written by watching
The diagnosis is not made in a meeting or from statistics. It is made by watching five people try to complete a specific task on the interface as it stands, and noting the exact place each of them stops, hesitates or asks for help.
The method is described in the article accompanying this one and should not be repeated here. What matters for a repair is the output: a list of places, not a list of impressions. "The home page is confusing" is not a blockage; "four people out of five looked for the price in the description before finding the button" is.
Record each blockage with three pieces of information: where it happens, how many of the five hit it, and what they were looking for at that moment. The third is the one people omit and it is the one that indicates the fix — a blockage is always the gap between what the person was looking for and what the screen offered.
A word on the number: five people do not give a statistic and do not claim to. They give a list of places, and a list of places is exactly what a repair needs. The statistic would come afterwards, and section 8 explains why it will not.
Finish by eliminating what are not blockages. Somebody who hesitates for two seconds and finds it has reported nothing; somebody who says out loud that they "do not like the colour" has reported nothing either. What counts is a stop, not an opinion.
Sort by cost, not by severity
The instinct is to deal with the most serious blockage first. That is the wrong order, for a practical reason: the cheapest fixes ship in hours, and they often remove blockages from the list that looked deep.
So sort the list into three layers. What is fixed by changing words. What is fixed by changing the order or spacing of what already exists. What requires writing code. Almost every list divides roughly into two thirds, a quarter, and a remainder.
That sorting is also a diagnosis, because a blockage placed in the wrong layer announces itself: if you cannot describe the fix in one sentence, it is not in the layer you think. "Make the checkout clearer" is not a wording fix, it is a sentence hiding four unidentified ones.
Deal with each layer completely before moving to the next, and remeasure in between — that is, watch five new people. It is the only way to know how many of the remaining blockages are real, and it is regularly fewer than half.
What is fixed in an hour: the words
The shallowest layer is also the one holding the most faults, and that is this exercise’s least intuitive result. A button label, a field name, an error message, a line of explanation: these are strings, they change without touching the structure, and they cause the majority of observed stops.
Three families turn up everywhere. Labels describing an internal action rather than the person’s intention — "Submit" instead of "Send my request". Names using your trade’s vocabulary instead of the customer’s. And error messages saying there is an error without saying which or where.
A fourth family belongs to a trilingual site: the translation that is correct and is not the phrasing people use. A word that is sound in academic French and never used in an Algerian commercial conversation makes people hesitate, and hesitation reads exactly like a design fault.
The rewriting rule comes down to one question asked of every label: does this answer what the person is wondering at this instant? A button answers "what happens if I touch this", a field name answers "what do I put here", an error message answers "what do I do now".
This layer has a property that makes it valuable: it is reversible in a minute. You can therefore fix quickly, be wrong, and go back at no cost — which is true of neither of the two layers that follow.
What is fixed in a day: order and space
The second layer creates nothing and deletes nothing: it moves things. Raising an element above the fold, separating two blocks that read as one, bringing a label next to its field, removing three things from a screen that carried eleven.
Removal is the most effective operation in this layer and the hardest to get accepted, because every element was added by somebody for a reason. The question to ask is not "is this useful" — almost everything is a little — but "is this useful to the task this page serves".
Proximity is the second operation, and it settles a whole family of blockages without anybody understanding why. Two elements close together read as related and two far apart as independent, whatever the logic of the content. A price far from its product is a price belonging to something else.
Order is the third, and it has one useful rule here: what the person is looking for first comes first. That seems obvious and is almost always violated, because a page’s order generally reflects the order in which the business thinks about its subjects, not the order in which the visitor asks their questions.
What requires a developer
The third layer is the only one that genuinely costs, and it is smaller than advertised: a field that rejects a valid format, a checkout that loses data when you go back, a missing state, a page that does not work on a narrow screen.
What a developer must be given is described in the article accompanying this one, and there is one thing to add when it is a repair rather than a design: the observed blockage, written as it happened. Not the fix you imagine — the behaviour seen, on which device, at which step.
The reason is practical. A developer given "make the button more visible" applies the fix and the blockage remains; the same developer told "three people out of five touched the area and nothing happened" often finds the touchable area is smaller than the drawing, which nobody would have guessed.
Group these fixes rather than requesting them one at a time. Every release has a fixed cost — checking, deploying, risk — and six small fixes delivered together cost far less than six deliveries, exactly as modifications to a printed piece are grouped.
Measuring when you are too small to measure
The question asked after a repair is always "by how much did that improve things". It calls for a percentage, and for most small and medium Algerian sites that percentage cannot honestly be calculated.
The reason is not that a figure is missing: it is that the sample is too small. A site receiving a few dozen visits a day and a few conversions a week varies naturally from one week to the next by more than the improvement you are trying to detect. The figure obtained measures the week, not the fix.
That is why we quote no order of magnitude of gain here, and it is a limit of your situation rather than a gap in the world. The problem is not that an average exists nowhere; it is that yours, measured on your traffic, cannot be separated from the noise. A supplier announcing "plus eighteen per cent" at that volume is presenting a weekly variation as a result.
What can honestly be measured at this size is of a different kind: the number of people, out of five, who stop at the same place. Before the fix, four out of five; after, none out of five. That is not a statistic and does not claim to be — it is a direct observation of the precise thing you changed, and it is sturdier than a percentage calculated on too little.
The consequence for method is clear. Choose one task, count the observed failures before, fix one layer, count again with five different people. When your traffic has grown enough to permit a real measurement, the article on comparative testing describes what is then needed — but do not borrow its methods before you have the volume for them.
Fixes that break something else
A repair has an intended local effect and effects at a distance nobody is looking for. That is the main reason to fix in small batches rather than all at once: a batch of three fixes where one breaks something can be diagnosed, a batch of thirty cannot.
Three distant effects recur regularly. Widening an element to make it visible pushes another below the fold. Shortening a French label leaves it correct and breaks the layout in Arabic, where the same word is longer or shorter. And removing an element judged useless deletes the only path some people were using.
The Arabic case deserves isolating because it is systematic on this site as on our clients’: every wording or spacing fix must be seen in all three languages before it ships. A fix approved in one language is a fix approved for a third of your visitors.
Finally, keep a record: one line per fix, the date, what changed, and the blockage it targeted. That is what lets you go back precisely when an unexpected effect appears three days later, and it is also what stops the same thing being fixed twice in opposite directions.
The interface already fixed ten times
There is a particular state worth recognising: the interface that has received successive fixes over years, each reasonable, whose sum no longer is. Every addition answered a real request and nobody ever removed anything.
The symptom is recognisable: a screen carries elements nobody in the business can explain any more, and the answer to every question is "just in case". Local fixes no longer do anything, because the problem is not any element but their number.
The answer is still not a redesign: it is a removal pass, which is a second-layer operation carried out at scale. List every element, find who actually uses it, and remove what nobody can name a use for. Warn people first, and keep the ability to put things back.
That pass regularly produces a bigger improvement than the previous ten fixes combined, and it costs almost nothing. It is difficult for another reason: removing something is a decision with an owner, while adding never had one.
When a redesign is genuinely justified
There are cases where repair is not the right answer, and they need naming so that the refusals in the previous sections stay credible. They are few and they are recognisable.
The first is a change in what the product does. If the business now sells something else, to other people, through another path, the interface describes a company that no longer exists, and no wording fix catches that up.
The second is technical and it is the most frequent: the base the interface is built on no longer permits fixes. When the third layer is refused not because it is expensive but because it is impossible — the system cannot display that state, cannot be adapted to a narrow screen — you are no longer repairing, you are working around.
The third is the accumulation described in the previous section, but only after a removal pass has been carried out and was not enough. In that order: the removal pass costs a week and often makes the redesign unnecessary; done afterwards it would have happened inside the redesign anyway, and you would have paid to learn it.
In all three cases the repair is still useful beforehand: it produces the list of real blockages, and that list is the best brief a redesign can receive. A redesign run without it starts again blind, which is precisely how the current interface was made.
What we do, and what we refuse
What we do is bounded. We rule out speed first, we run the five-person observation, we draw a list of located blockages from it, we sort the fixes by layer, and we fix from the shallowest towards the deepest, remeasuring in between.
We refuse to take a redesign brief before the wording layer has been tried. It is a refusal that reduces what we invoice, and it holds because the opposite is checkable: in most cases a week of rewriting removes half of what justified the redesign from the list.
We also refuse to announce a percentage improvement on traffic that cannot produce one. What we report at this size is the number of people who stopped at the same place before and after, which is a less flattering and truer measurement.
And we do not ship a fix approved in one language, because a layout that holds in French can break in Arabic on the same word. There is also work you can do without us that is worth half of all this: watch five people use your interface, without helping them, and note where they stop.
Frequently asked questions
Our site does not convert. Should we rebuild it?
Almost never first. Rule out speed — a slow interface is indistinguishable from a badly designed one to the person using it — then watch five people attempt a specific task and note where they stop. In most cases half of what justified the redesign disappears after a week of rewriting labels.
Where do we start when the list of problems is long?
With cost, not severity. Three layers: what is fixed by changing words, what is fixed by moving what exists, and what requires code. Deal with each layer completely then remeasure before moving on — it is the only way to know how many remaining blockages are real, and it is often fewer than half.
Why would labels cause so many problems?
Because they answer — or fail to answer — what the person is wondering at that instant. A button answers "what happens if I touch this", a field "what do I put here", an error "what do I do now". Add here the translation that is correct and never used in an Algerian commercial conversation: it makes people hesitate, and hesitation reads as a design fault.
How do we measure whether a fix worked?
Not as a percentage, if your traffic is small: a few dozen visits a day vary week to week by more than the improvement you are looking for, so the figure would measure the week. Count the observed failures on one named task instead — four out of five before, none out of five after. It is not a statistic, and it is sturdier than a percentage calculated on too little.
Can a fix break something else?
Regularly, in three ways: widening an element pushes another below the fold, shortening a French label breaks the Arabic layout, and removing an element deletes the path some people were using. Fix in small batches, check all three languages before shipping, and keep one line per fix so you can go back.
When is a redesign genuinely justified?
Three cases. The product now does something else for other people. The technical base makes fixes impossible rather than expensive. Or a removal pass was carried out and was not enough. In all three, do the repair first: it produces the list of real blockages, which is the best brief a redesign can receive.
Where we come in
The list of places where five people stopped is very nearly everything you need. What is missing is the order in which to take them.
- We try the words first: the label, the order, what is written on the button.
- We rank your blockages by cost to fix rather than by how bad they felt.
- We check every fix in Arabic before it goes anywhere near production.
- We repeat the five-person observation a month later, with the same tasks.
If your first useful content takes more than five seconds to arrive, touch no drawing at all: you have a speed problem and nothing else.
Read next
An AI writing in Arabic: what breaks in your interface
The Arabic a model produces is correct and your screen no longer is. Here are the eight places it breaks, and the check that finds them in an hour.UI/UX: an interface is judged on a task completed
Not on how it looks. Name the five things people come to do, watch five people do them, and fix what blocks them.A small business’s visual identity: what works and what decorates
A logo is not an identity. What is almost always missing is what happens the day after it is delivered.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.