ANODA Discuss your product

Construction tablet app, every kitchen planned and tracked

Cabinit runs kitchen and vanity installation in multi-unit residential buildings.We designed its tablet-first product for every role on a project.

Cabinit projects register on a tablet: ten projects with their status, dates, customer and sales manager; Cabinit Directory on a tablet: the Teams tab with the Office team open and its members’ invitation status
5
roles admin, office, site, installation team and customer
Tablet
first with a phablet adaptation
2
stages the product, then its Directory and project access

Cabinit is a web app for companies that install kitchens and vanities in multi-unit residential buildings. The office prices and plans a project, site managers track it floor by floor, installation teams close their tasks and punches, and the customer follows what they are allowed to see. We designed the product’s UX and UI tablet-first, with a full design system .

What one project holds

One chain, from the office’s register to the people around a project:

  1. Projects

    • Register
    • Status
    • Filters

  2. Estimate

    • Kitchens
    • Vanities
    • Services

  3. Building

    • Floors
    • Units
    • Statuses

  4. Tracking

    • Tasks
    • Punches
    • Photos

  5. Records

    • Activity log
    • Plans
    • Reports

  6. Directory

    • Users
    • Teams
    • Connections
Office detail Site speed
Dense tables for planning; big targets and short words for the person on a ladder.
One project Separate views
Everyone works on the same project; each role sees only its part.
The original What came later
Directory and project access added in the language people already knew.

A project’s state, read in one pass

Found
A project runs to dozens of tasks and punches across floors and units, and a list of them doesn’t say whether the job is on track.
Decided
A summary tab that reads top down: tasks by status, each split by type of work; the week’s punches, with the customer’s own punches apart; then the task mix as one chart.
For the user
The office sees where a project stands, and whether the customer is raising issues, before opening a single unit.
Cabinit project summary for Oakwood: 55 tasks split into done, not ready, delivered and closed by kitchen, vanity and dishwasher, the week’s punches, customer-created punches and a task status donut
After: the office’s project summary; every figure is example data

  1. Where you are

    The project, its sections, and the tracking tabs.

  2. Tasks by status

    Done, not ready, delivered, closed, split by type of work.

  3. This week’s punches

    Done, updated, created and delivered in the last seven days.

  4. The customer’s punches

    Issues the customer raised, kept apart from the team’s.

  5. The mix

    The task statuses as one chart.

How the work progressed

The process first, then the roles and their paths, then every screen in one system, then the returning scope in the same language.

  1. Discovery

    How the client’s installation work already ran, from its concept and requirements

    Artifact A review of the existing operational concept and requirements

  2. User Flow

    Who does what: five roles, and where their work meets on one project

    Artifact Information architecture and multi-role user flows

    Part of the punch-list user flow: the punch list with its content notes, the search branch and the upload-from-document branch that starts with the template

  3. Wireframes

    What a tablet screen can carry: units, dense tables, filters and forms

    Artifact Tablet and phablet wireframes

    Grey tablet wireframe of a project’s units: search and filter, then unit cards with kitchen photos and links to their punches and tasks

  4. UI & Design System

    One look for every role, from the estimate tables to the forms used on site

    Artifact The tablet-first UI in all its states, a design system and a UI kit

    Three style options for the tablet UI, each with its palette and the same new-project form: steps as circles, as bars and as a progress line

  5. Delivery

    What developers and QA need to build it without guessing

    Artifact Screen maps, a clickable prototype and feature-level documentation

One product, a menu for each role

Found
Five roles share one product, and a menu that showed everyone everything would put an installer one tap away from the estimates.
Decided
Each role’s paths were mapped first, screen by screen with what each one holds; then each role got its own menu, and the Directory added later was mapped the same way before it was drawn.

  1. Site manager: putting a project on tracking

    From the tracking page through four setup steps, then units, the report and the logs.

    Open the full map
    Site manager map fragment: project tracking, the tracking page and create project tracking steps 1 to 4, each with its content list, then search, unit cards, the units page and the report download

  2. Admin: teams in the Directory

    Open Directory, then either an empty state or the teams list, and a team’s details with its members.

    Open the full map
    Directory Teams tab flow: flow start, the any-teams check, the populated teams list with its elements, and team details with statuses and actions
Two Cabinit side menus: the office’s with User Management, Settings and Logs, and the site manager’s with Settings and Logs

The menu changes with the role

Left, the office: user management, settings and logs. Right, the site manager: settings and logs.

  • Information architecture
  • Multi-role user flows
  • Role and workflow screen maps
  • Clickable prototype

From the first estimate to the last punch

In the order a project meets them: the office’s register and estimate, the building set up once, the site’s daily work, the records, then the Directory added later. Every name and figure on these screens is example data.

Every project in one register

Found
An office runs many buildings at different stages, and a spreadsheet row per project hides which ones are waiting on someone.
Decided
A projects register with status, start and follow-up dates, customer and sales manager on every row, with search, filters, sorting, and a card view for those who prefer it.
Cabinit projects register: ten projects with pending, waiting for info, follow up, approved, rejected, in progress and closed statuses, start and follow-up dates, customer and sales manager

An estimate that counts the work

Found
A building’s estimate is a pile of kitchen types, vanity codes and extras, and turning it into installation days by hand is where mistakes start.
Decided
An estimate form that takes the drawings, the calculator’s settings, kitchens by type and layout, vanities and extra services, and totals the tasks and days as it goes.
Create estimate form: uploaded PDFs, calculator settings, kitchen types K-1 to K-12, vanity codes, dishwasher, wine fridge and steam oven, and the total tasks table in installation days

A building set up once

Found
Tracking only works if the building is described first, and floors, units and statuses typed differently on every project make every report different.
Decided
Putting a project on tracking is a short wizard: floors and units ticked on one grid, then the task and punch statuses the project will use, with a default for each.
Set project on tracking, first step: a grid of units A to D against basement, floor 1 and floor 2, with add floor and add unit
Set project on tracking, second step: task statuses Backlog and Completed, punch statuses Open and Resolved, each with a default

A unit’s work in one view

Found
On site, the question is always about one apartment: what is left there, who is on it, what is still open.
Decided
A unit page with its tasks, their status and payment state, and its punches with the crew and photos, each list with its own filters.
Unit B on floor 2: seven tasks with status, timestamp, payment status and payment date, and seven punches with status, timestamp, crew and photos

Tasks changed in bulk

Found
A crew finishes a floor in a day, and updating each task one by one is how the tracking falls behind the site.
Decided
Tasks select in the table and change together through Edit Selected, with search, filters and the payment state kept in the same rows.
Oakwood tasks table with three rows selected and the Edit Selected (3) button, statuses, timestamps and payment states

A punch raised where it’s found

Found
A snag noticed on a walk-through gets lost unless it is written down with its place and a photo on the spot.
Decided
A punch form built for the site: a name, the floors and units it applies to, its status and a photo, in one screen.
Add new punch form: the punch name, floors and units as multiple choice, the Open status and an uploaded photo

The crew and the customer, in the same project

Found
An installer finishing a unit and a customer checking on it work in the same project, but neither needs what the office sees.
Decided
The installation team updates a task’s status with a photo from the unit; the customer follows the punches raised on their project and where each one stands.
Update task status dialog on the installation team’s tablet: the unit Floor 2, Unit B, a photo upload in JPG or PNG up to 10 MB, Cancel and Apply
The customer’s punch list for the Oakwood project: counts of punches done, updated and created in the last seven days, and a table of punches by unit and floor with status, date and photos

A history nobody has to write

Found
When something is disputed later, the office needs to know who changed what, where and when, without asking around.
Decided
An activity log of photos, estimates, invitations and status changes, each with its time, the person and their role, the floor, the unit and the project.
Activity log: uploaded photos, edited and created estimates, an invitation and task status changes, each with timestamp, person and role, floor, unit and project

A report the office can hand over

Found
The office and the customer need a floor’s progress as a document they can keep, not a screen they have to open.
Decided
Reports grouped by floor, unit or task, each with a task list and a punch list whose columns can be chosen, then downloaded as a file.
Oakwood report grouped by floor with floor 2 open: seven tasks by unit with status, timestamps and payment, seven punches by unit with status and crew, and the Download Report button

People, teams and companies in one Directory

Found
The original product managed people as a list of invitations; the returning scope had to hold crews, customers and partner companies too, and the links between them.
Decided
A Directory with tabs for users, teams, customers, companies and connections; every user with an invitation status, a role and a team, and changes made in bulk.
Directory users tab: nine people with active, not invited, pending, deactivated and declined statuses, their role and their team, customer or company

One kit for the office and the site

Found
Dozens of tables, filters and forms across five roles would drift apart if each were drawn on its own.
Decided
A design system and UI kit of components, tables, filters, navigation and status patterns, reused by every role and carried into the Directory later.

Status cards, built once

The kit’s status cards head the project summary, the tasks tab and every report, with the same numbers in the same places.

  • UI kit task status cards: done, not ready and delivered, each with its share of tasks split into kitchen, vanity and dishwasher
    Task cards: Each status, split by type of work.
  • UI kit punch cards: done, updated and created in the last seven days
    Punch cards: The last seven days at a glance.

A new project, from empty to filled

The first step of creating a project in each of its states: empty, typing, missing fields, and ready to continue.

  • Create new project, first step, empty: project name and address fields with placeholders
    Empty
  • Create new project with the project name field focused
    Typing
  • Create new project with both fields outlined in red and the prompt to fill in all required fields
    Missing fields
  • Create new project filled in: Oakwood, 40 Oakwood Avenue, Springfield, IL
    Filled

What the developers received

The work ended in files a development team could build from, with the design logic written down and the backend left to them.

Screen maps
Every role’s screens and states laid out by workflow, numbered in order.
Clickable prototype
The tablet product, clickable flow by flow.
Design system and UI kit
Colours, type, components, tables, filters, navigation and statuses.
Feature documentation
The behaviour and states of each feature, for engineering and QA.

Flows in the handoff

  1. Sign-up and log-in
  2. Project register: every project in one list
  3. New project: the building set up floor by floor
  4. Office: project details and estimates
  5. Admin: invitations and user management
  6. Office settings
  7. Site manager: tracking units, tasks and punches
  8. Site manager: activity logs
  9. Installation team: their tasks on site
  10. Customer: following the project
  11. Charts and reports
  12. UI kit: components, tables, filters and statuses
Cabinit screen map for the site manager’s project tracking: columns of tablet screens for summary, units, photos, filters, search, the unit page, tasks, status changes, punch list and logs
Screen map: The site manager’s tracking: summary, units, tasks, punches and logs, every state in its column.
Cabinit UI kit status colours: default, completed and eight numbered status colours with their hex values
UI kit: Ten status colours, for the statuses each project sets up.

Where the design ended up

Cabinit’s whole installation process designed as one tablet-first product, each role with its own menu.

When Cabinit returned, the Directory and project access were added in the same system. Development stayed with the client.

roles in one product
5
first, with a phablet adaptation
Tablet

In the client's words

ANODA organised a complicated installation workflow into screens we could review role by role. Estimates, project progress and punch lists were considered together, which gave us a concrete way to discuss how the proposed product should support work on site.

Yidi Srulowitz cabinit LLC

5.0

Should your customers see progress, but not everything?

In Cabinit the office, the site, the installation teams and the customer work from one project, each with its own part of it. Show us how the roles in your jobs share information today, and we’ll show you the screens each one gets.

Discuss your product Explore more case studies

What we brought to Cabinit

The product

The interface and the work