Principles of Productive Design Work
In short Vlad Golovach’s eleven rules are not about what a good interface looks like but about how to work on one without wasting the project. Most of them apply just as well to requirements work, and one gives you a simple formula for prioritizing UI improvements.
Based on: V. Golovach, User Interface Design 2: The Art of Washing an Elephant (in Russian), part I “Productive Work”.
On this page
Key ideas#
Getting better, not perfect#
1. Improve rather than perfect. Nothing is ever finished; things are declared done because they have to be. Don’t polish what is too early to polish, and don’t chase new features while known problems remain. Golovach treats a day spent only adding good things, without fixing bad ones, as a day lost.
2. Be pessimistic about your own work. If everything can be improved, then everything you have done is still bad. Admitting that is what drives improvement.
3. Set up the work so you never wonder what you forgot. Write lists before you start (interface objects, checklists, target qualities) instead of relying on memory when you check.
4. Rework rather than overthink. A quick bad version, quickly reworked, gets the same result as long planning. But the work can be stopped at any point, and colleagues and clients can review it from the first iteration. This needs a fast prototyping method.
5. Start with the most painful part. Users judge a product by its worst part, not by its average, so fix the worst first. Find out what hurts most, by asking the client or by testing, before you start.
Knowledge and its limits#
6. Don’t act like an expert. Knowledge is useless until it becomes a design action. Assuming you know nothing makes you check the interface against a list rather than trust that it “will be fine”.
7. Don’t philosophize. There are very few universal answers; Fitts’s and Hick’s laws are among them. Only testing proves that a solution works. Don’t look for a general answer until you have solved the specific problem at least three times.
Optimizing what matters#
8. Do only the optimization that improves the product. Golovach’s formula:
improvement = share of users who use the fragment × importance weight of that user group × noticeability of the improvement
A full redesign of a rarely used dialog can score far lower than a small change to a screen everyone uses. He also explains why small improvements get blocked: deadlines, managers who can’t see them, and marketing that needs improvements explainable in a few words. Start with “will this help the product sell?”, not “do I like it?”
Professional conduct#
9. Act professionally. Use correct terminology. Don’t promise the client large improvements; Golovach suggests no more than 10–15%. If a client insists on their own solution, state the consequences clearly and make it explicit that you are not responsible for advice that was not followed.
10. Don’t do what you can’t do. Golovach lists five prerequisites for the job: listening and empathy, taste, writing, logic, and curiosity. All of them can be developed, but through years of deliberate work.
11. Accept that you will be wrong. He estimates that at least a third of interface decisions work worse than expected or not at all, because the user’s half of the interaction can’t be fully predicted. The answer is testing, not a grand theory.
How to apply it#
- Score UI backlog items with the formula before estimating effort. Agree user-group weights with the product owner once, then reuse them.
- Find the worst screen first. Before a UI review, ask users and support staff which screen they dislike most, and start there.
- Prepare checklists before reviews, not during them.
- Prototype early and cheaply, so stakeholders review something real.
- Record rejected recommendations and their expected consequences in the decision log.
- Plan for rework. Budget iterations in the plan instead of assuming the first design will hold.
Review checklist#
- UI improvements are ranked by reach × importance × noticeability.
- The most painful screen was identified and addressed first.
- Review checklists existed before the review started.
- Decisions are backed by tests, not only by arguments.
- Rejected recommendations are recorded with their consequences.
Example#
At The Workshop, a fictional chain of bike-repair workshops, the UI backlog has two candidates. One is a full redesign of the yearly price-list import screen, used by one office administrator. The other is a small change to the booking calendar, used by every customer. The team scores both with agreed, purely illustrative weights:
| Item | Share of users | Group weight | Noticeability | Score |
|---|---|---|---|---|
| Redesign the price-list import | 0.02 | 1 | 1.5 | 0.03 |
| Show the next free slot first | 1.0 | 5 | 1.1 | 5.5 |
The small calendar change wins by a wide margin, even though it needs far less work.
Sources and further reading#
- V. Golovach. User Interface Design 2: The Art of Washing an Elephant, v2.11 (in Russian; freely distributed), 2010, part I “Productive Work”.