What does a design system become when the thing reading it is a machine?

The app, running here

This is the real build, not a click-through. Every score below is computed live from the birth data of eight synthetic people.

The frame runs a copy of the production app with the database credentials removed, so it seeds a demo account in memory and makes no network calls at all. The maps, the roles, the scores, the readings and the copy pools are the shipped code. Try the three map views, open a friend, switch between Today, Month and Life.

Open full screen →

A map of the people around you

Astrology apps are read alone, or one friend at a time. This one puts everyone on the same page and gives each person a job.

The people I built this for read their horoscope and then talk about it, with a partner, a sibling, a group chat, the person at the next desk. The existing apps do not support that conversation. They give you a paragraph about yourself, or a compatibility score against one other person, and the talking has to happen somewhere else.

So the unit of this product is not the reading. It is the map. Thirteen friends, six roles, one chart you can point at. Distance from the center is how good that person is for you today, which means the picture changes every morning and gives you something new to say.

Three views of the same thirteen people

My StarCloser to the center is better for you today. The black sun is you.

RolesSix sectors. The sixth is defined by the user.

Zodiac wheelEveryone sits in their own sun sign.

The six roles are the product decision

What the six meanEvery term in the app is one tap from a plain-language definition. No degrees, no houses, no aspect names anywhere in body text.

FriendsRole, sign, today score, and one line. The grid is the only place in the app where content sits in a card.

A reading

Me, todayOne large serif number, one headline, then the day in plain sentences.

Luck, do and don'tNouns rather than sentences, for reasons the research section explains.

A friendThe same skeleton, pointed at one person.

935 KB of source. 23 KB of it is math.

The artifact is the rule that produced the screen. The screen is what falls out of it.

I measured the source when the case study was written. The astrology engine, the part that positions planets and computes a score, is the smallest thing in the project. Everything above it is language and rules: what the app is allowed to say, in what tone, in two languages, under which conditions.

That ratio is the whole argument. When an agent writes the code, the scarce thing stops being implementation and becomes specification. A screen I do not like is rarely a screen problem. It is a rule that was missing, or a rule that was wrong, and the fix has to land in the rule or it comes back on the next screen.

Working this way changed the question I ask in a review. It used to be what does this screen look like. Now it is which rule produced this screen, and is that rule right.

Three files, three kinds of failure

The design system is not one document. It is three, and they exist because three different things kept going wrong. Each one is a markdown file an agent reads before it touches anything.

The third file is the one most design systems do not have, and it is the one that saved the project. A design system that a machine executes needs a section about what the machine is forbidden to do, not only what it should produce.

Five rules, and the failure that produced each one

None of these were written in advance. Every one is the scar of something that went wrong in a build, got diagnosed, and got turned into a line an agent now reads before it starts.

The same system in both themes

LightIvory canvas, hairline rings, serif names.

Light, readingSame skeleton, same type scale.

Light, sheetRole colours carry meaning in both themes.

Two competitor findings that changed the writing

I read the four apps people in this category actually use, and two of them changed a rule rather than confirming one.

What is still wrong, on the day this was written

The design system has a Known Gaps section. It is the section I trust most.

These are four defects visible in the screenshots above, taken from the live build on September 8. Three of them the rule files already predicted.

Two of them, in the build

CollisionTwo names in one sector render as one string.

Scale conflict90 above, 38 below, no explanation between them.

The promise the app has not kept yet

The reason to build this was that people talk about their horoscope together. Right now every user still looks at their own map alone. Sharing is an invite link and nothing more. That is the largest gap between the concept and the build, and it is bigger than any of the four defects above.

The next version has to make the map a thing two people look at at once. Everything else on the roadmap, the account system, the paid tier, the ad placements, is downstream of that.

The part I will carry into any team is the working method. A design system written for a machine to execute, with a section on what the machine must not do, and a rule for every failure that has already happened once.

SPOT OM case study → · Platform Modernization → · Service Platform →