Construction Tech Platform

One construction platform for five roles who each see the project differently.

Customers, architects and builders each look at a different part of the same house. As the only designer on a 7-person team, I turned the wireframes and specs I received into the final UI and flows, and checked them against the rules of the service, so all five roles work from one project record.

Live since Sept 2025 · Tokyo area

Partial NDA: the client, the product's name and real project details are withheld. The screens are the real designs, in Japanese, with the brand mark and place names replaced. Some screens carry a tag. Rebuilt: the admin shipped from wireframes, so its screens are rebuilt in the product's final UI kit. Recreated: the final file wasn't archived, so the screen is recreated in the same kit. Added: the confirmation dialog on Disagree was added for this case.

How did I help: Design & system work
PropTech · Web
Role: Sole UX/UI designer
Team: 7-person project team: 1 designer, 3 devs, 2 QC, 1 PM
Timeline: 13 months
Platform: Web (responsive, shipped as an app)

AI summary

Who's reading? I'll show what matters to you.

One construction platform where customers, a director, real estate companies, architects and builders work from one project record.
As the only designer on a 7-person team, I turned wireframes and specs into the final UI and checked them against the rules of the service.
Live since Sept 2025 in the Tokyo area. Partial NDA: real designs in Japanese, with names replaced.

View CV

The tour: The wireframes had gaps → What kept five roles on one system → Validate with people on site

Ask about this case

Three real screens of the platform, in Japanese: the customer's project details with the 13-step flow down the left, the customer's project list with each project's director, engineer, architect and builders, and the architect's project details

No layers of middlemen.
One platform, one director.

Five roles, two portals

Custom homes usually pass through layers of middlemen: owners pay more, while architects and craftsmen work to tight deadlines for little. The platform connects them directly, with a director and an engineer in between, and every role sees the same project steps.

Director / Engineerディレクター・エンジニア

Partner portalAll 13 steps

The director runs the project through all 13 steps, from proposing architects to assigning the builders, and completes it once every member is done; the engineer supervises the site.

Large home builders and materials suppliers also work with the company, but outside the platform, so they have no role here.

The director runs all 13 steps.
Everyone else joins when needed.

The wireframes had gaps.
I closed them.

Approach

I worked from wireframes and specs handed to me. Where a wireframe disagreed with the rules of the service, I redesigned the final UI to follow the rules.

01Check the wireframesRead each wireframe against the written spec and flagged where the two disagreed or stopped short.
02Design the final UITurned the customer and partner wireframes into finished screens, one flow per role, on the component set I extended.
03Map where roles meetChecked the rules where one role's action changes what another can do, like a disagreement that stops every later step.
04Hand off directly to devs and QCAs the only designer, I handed off straight to the 3 devs and 2 QC, so questions came straight to me.

Sitemap from the Japanese team

When one role's action changes what another can do.

Edge cases

Four rules from the spec. Two live in the internal admin.

The customer's rough estimate, in Japanese, recreated for this case in the final UI kit, with Agree and Disagree buttons and the spec note in red, with the callout: disagree means no contract, and every later step stops. The animation taps Disagree and a confirmation dialog, added for this case, asks the customer to confirm, saying the contract won't go ahead and later steps stop.

01 / 04 · Customer portal · Recreated

When the customer disagrees

Disagreeing with the rough estimate means no contract, and every later step stops, so the customer confirms it first.

01 / 04 · Customer portal · Recreated
When the customer disagrees. Disagreeing with the rough estimate means no contract, and every later step stops, so the customer confirms it first.
The spec: the red note on the screen is its own.
01 / 04 · Customer portal · Recreated
When the customer disagrees. Disagreeing with the rough estimate means no contract, and every later step stops, so the customer confirms it first.
Decided by
The spec: the red note on the screen is its own.
My part
I designed the final screen from the wireframe. Its file wasn't archived, so it is recreated here, and the confirmation dialog was added for this case.
02 / 04 · Partner portal · Director · Recreated
Finishing a project. The director's Complete button stays disabled until every member's status is Done.
The spec: the note above the button is its own.
03 / 04 · Admin portal · Rebuilt
When a director reaches their limit. The admin sets how many projects a director can take at once. At the limit, the director shows as Full. Directors can change their own limit, but not below the admin's value.
The spec. The admin was built last, straight from its wireframes.
03 / 04 · Admin portal · Rebuilt
When a director reaches their limit. The admin sets how many projects a director can take at once. At the limit, the director shows as Full. Directors can change their own limit, but not below the admin's value.
Decided by
The spec. The admin was built last, straight from its wireframes.
My part
None on the shipped admin; I didn't design it. I rebuilt these screens in the final UI kit for this case, to show the rule.
04 / 04 · Admin portal · Rebuilt
Sending an application back. The admin reviews each architect's application. Sending it back needs a reason: the dialog won't go through with the field empty.
The spec. The admin was built last, straight from its wireframes.

What kept five roles on one system.

The customer's project list, in Japanese: each project with its photo, title, dates and its director, engineer, architect and builders. The animation then shows the architect's project details.

01 / 05 · Role-based dashboards

A starting screen for each role

Each role needs a different starting point in the same projects.

01 / 05 · Role-based dashboards
A starting screen for each role.
Each role needs a different starting point in the same projects.
01 / 05 · Role-based dashboards
A starting screen for each role.
Problem
Each role needs a different starting point in the same projects.
Decided by
The spec: each role gets its own dashboard.
My part
I designed the screens each role starts from, like the customer's project list and the architect's project details.
Outcome
The customer starts from their project list, the architect from the details of the project they work on.
02 / 05 · Shared project data
One project page for everyone.
Each role works on a different part of the same project.
02 / 05 · Shared project data
One project page for everyone.
Problem
Each role works on a different part of the same project.
Decided by
The spec: one project record that every role works from.
My part
I designed the project page, with the step rail, the members, the contract files and the progress posts in one place.
Outcome
The customer sees where the project stands, who is on it and what was posted, on the same record the partners update.
03 / 05 · Component system
A reusable UI system.
Five roles meant the same parts drawn many times.
04 / 05 · Partner portal
A join request partners can answer.
I named the director as the sender, put Decline next to Join, and designed the dialog after joining that says chat is now open.
05 / 05 · Customer portal
Room for every builder.
I changed it to a member grid that holds every builder, because from step 9 a project can have several.

The builder posts it.
The director and the customer see it.

One update, three roles

When a partner posts an update, the customer sees it in their portal right away.

Animated: the builder's (Meister) progress update form, with a title, text and a photo; the director and engineer then see the post under Progress in their portal. On desktop, the customer's My page shows the bell in the header and the message list, then the customer sees the post under Progress. Real screens in Japanese; the builder's and director's are recreated for this case in the final UI kit.

The same portal on a phone.

Four phone screens of the customer portal's mobile app, in Japanese: My page with the project notices; the project details with the step badge 12/13 着工後 (after construction starts), the 13-step bar, the members, the contract files and the progress posts; a progress post open in a dialog with its photo, date, title and text; and the project chat with read receipts and a photo message.

Inside the product.

The customer's free consultation form, in Japanese. The animation runs from the top page to the form and down to its send button, then to the messages on My page.

01 / 06 · Customer portal

Ask for a free consultation

The customer sends the free consultation form; updates then come in as messages on their My page.

01 / 06 · Customer portal
Ask for a free consultation. The customer sends the free consultation form; updates then come in as messages on their My page.
The consultation form and the customer's My page.
02 / 06 · Customer portal
Follow the build. On the project page, the customer opens a progress post to read it.
The project page and the dialog that opens each progress post.
03 / 06 · Admin portal · Rebuilt
Vet a new architect. The admin opens an architect's application, reads it through and approves it after a confirmation.
The admin isn't my design; these screens are rebuilt in the final UI kit for this case.
04 / 06 · Partner portal · Architect
Join a project. At step 4, the director sends the request to join to the architects proposed to the customer. One tap on Join confirms it, and the customer is told who is in charge.
The request on the architect's project page, and the dialog that confirms they joined.
05 / 06 · Customer portal
Talk in the project. Each project has its own chats, one tab away from its details.
The chat tab: the project's chats on the left, the open conversation on the right.
06 / 06 · Customer portal · Mobile app
Follow a project on the phone. From My page, the customer opens a status notice, scrolls the project down to its progress posts and opens one.
I designed the responsive web that ships as the app, so the phone UI is the web UI at phone size.

What I'd do differently

Validate with people on site, and measure the change.

The team was my only feedback loop. It caught plenty of logic gaps, but edge cases were checked against what the team believed users did, not what they really did. Next time I'd test with people on site and measure the change after launch.

Lessons

Different views, same projectThe hard part was agreeing what is shared and what stays role-specific.
Five roles, five starting pointsEach role needed its own entry point into the same data.
Fix contrast in the paletteThe error red in the original palette didn't pass contrast. On the screens rebuilt for this case I used a darker red (#C4472F); next time I'd fix it in the palette itself.

Many roles, one product?