Definder · Case study
The system came before the pages
Definder is an asset tokenization platform: real estate split into tokens so it can be sold in pieces, companies raising capital without a conventional round, and a white-label version for other operators.
My first website designed from nothing. No existing pages to react to, no structure to inherit, no components to reuse.
01 — From One Contact Box to Four Ways In
Splitting the entry point by who is arriving
Four people arrive at the same homepage wanting four different things, and none of them wants the same sentence.
Who arrives, and for what
- Asset ownerLiquidity out of something illiquid
- Fund managerAllocation and reporting
- Retail investorAccess below a minimum they could not meet
- IssuerDistribution
Before
- Four participants
- One “contact us”
- Nobody served
Solution
- Four numbered cards
- Its own route
- Seven application forms
Each card states what the platform offers that participant. Behind the routes sit seven separate forms rather than one generic enquiry: somebody listing a building and somebody buying a fraction of one are not filling in the same fields.
02 — From Nothing to a Structure
Wireframing the whole site before choosing a colour
What had to hold together
- Site
- Nine content pages
- Main · Our product · About us · Ways to join · Team
- News · Article · Contacts · Privacy policy
- Seven-step application flow
- A mobile version of all of it
- Nine content pages
That is a lot of surface for a first from-scratch project. The only way I know to keep it coherent is to settle the structure while changing it is still cheap.
The order of the file
- Wireframes
- UI and components
- Designed screens
In that order, and nothing was drawn twice.
03 — From Screens to a Component Library
Drawing the states that only exist mid-interaction
The grid, on its own page
- 12 columns
- 100 px margins
- 20 px gutters
- Written down
Specified rather than kept in my head, so any spacing could be checked against it instead of guessed at.
The library
- Library
- Buttons
- Primary · Secondary · Category · Small · Outline · Scroll-to-top
- Inputs and dropdowns
- Default · Focus · Filled · Selected
- Header — five variants, one per active navigation item
- Flows — search, subscription
- Buttons
A flow, drawn to its end
- Default
- Active
- Typed
- Success
The success state is the one that gets skipped. Drawing it is what separates a component library from a set of pictures.
04 — From a Content Dump to a Readable One
Pages built for a company that publishes constantly
Regulatory updates, monthly reports, market commentary — and coverage by outlets its investors read. The site had to hold that without turning into a wall.
Three reading intentions, not one feed
- News
- News
- Blog
- Monthly report
Separated for the cost of one row of controls, plus text search. Alongside it, a press page where Coindesk, Forbes, VentureBeat, Yahoo Finance and Investors Chronicle are evidence rather than decoration.
The article, with no dead end
- Article
- Tags
- “Read more” rail
- Related articles
Contacts, split by who is actually asking
- Marketing
- Press
- Support
Required in the form
For a company raising capital across jurisdictions, who is asking and where they are asking from is not an optional field — it determines whether they can be answered at all.
05 — From a Drawing to a Build
Handoff that answers its own questions
- Grid
- Components
- Redlines
- Development
Header, footer and cards were specified with measurements marked directly on the drawing. Not because a developer cannot measure — because a marked drawing removes the question before it is asked, and questions asked mid-build are the expensive kind.
Marked on the page
The specification and the system live in one place instead of two.
Status