Making construction proposals easier to create and share.

A complex process, repeated for every project.

The brief was to make proposal creation and active project management work in one web platform for mass timber and construction companies. Every unnecessary step in those workflows was a chance to lose time or context.

I knew very little about this field when I joined. We treated that as a useful test: if a newcomer could understand the platform, experienced teams should not have to fight the interface to get their work done.

I spent much of the first week reading proposal documents shared by the CEO, along with online books and resources from established companies in the field. I then made a Data Breakdown document to map the information in those proposals before designing the UI.

Turn 104 pages into reusable building blocks.

The source material ran to 104 pages. My first pass organized it into four major groups and 28 smaller categories. After more discussion, I reduced that structure to common objects such as headings, body text, and images, plus four special objects: testimonials, facilities, team members, and portfolio items.

This content model separated information that could be reused across proposals from details that belonged to one project. It gave the editor a consistent foundation without making every proposal read the same way.

A proposal editor that feels like writing.

The goal was a basic CMS that did not feel like one. Much of the proposal material was boilerplate, so asking teams to assemble it again for every project would waste time. The content model and component-based editor let them write with familiar text and images, then insert structured objects only when needed.

In the original write-up, this approach was described as significantly reducing the time needed to write a proposal. No measured completion times were reported.

Give teams more than a blank canvas.

Reuse helped once a project existed, but creating the first one was still time-consuming. I designed three starting paths: start a new project (from preconfigured sections or a blank canvas), duplicate an existing project, or use an experimental AI flow to parse and restructure an uploaded proposal.

The AI idea was to separate reusable boilerplate from project-specific content so teams would not have to rebuild the common sections by hand. I estimated that boilerplate made up roughly 80% of a proposal and projected a similar reduction in initial setup effort. That was a design estimate, not a measured result.

A project home for external stakeholders.

After the project creation flow, the next stage was the Owner Page: a blog-like page for presenting proposals and ongoing project details to external stakeholders. It extended the same content structure beyond authoring into a shareable project view.

The project workspace also included views and analytics for the team managing that information.

Katch

Exploring availability in Slack and redesigning essential iOS flows for a planned launch.