Most failed builds start with screens too early. A team asks for a website, dashboard or CRM, and everyone jumps into pages, cards and buttons before agreeing on the system underneath.
At AlterLabs, we start by mapping the operating system of the business: who enters data, where that data moves, what decisions it supports, and which handoffs need proof.
Map the entities first
Before designing a lead dashboard, name the things the business actually tracks. A simple sales system might include leads, companies, contacts, deals, tasks, notes and follow-ups. A service business may need enquiries, site visits, quotes, jobs, invoices and support tickets.
When the entities are clear, the interface becomes calmer. The website knows what a lead is. The CRM knows what stage means. The dashboard knows which numbers are real.
Design the handoffs
A business system usually breaks at the handoff: form to inbox, inbox to sales, sales to operations, operations to finance. Each handoff should have an owner, a status, a timestamp and a fallback.
- What triggers the handoff?
- Who owns the next action?
- What should happen if nothing moves?
- What does the team need to see later?
Then design screens
Once the entities and handoffs are stable, screens become easier to design. The homepage, intake form, CRM table and reporting view are no longer separate pieces. They are surfaces of one system.
That is the difference between a site that looks finished and a system the business can actually run on.