top of page

Construction diary

The construction diary is a digital tool that helps solar project teams to document their daily work activities, incidents, and progress directly from the field, while improving data quality for controlling, legal, and client reporting.

iPhone 16 Pro BTB cover_edited.jpg

Mockup created with mrmmock.com

My Role

My team consist of:

  • 1 product owner

  • 2 developers

  • 1 product designer (myself)

 

I took over the project from an external team who had defined the initial problem, user flow, and early UI designs. Building on their foundation, my responsibilities included:

  • Improving the existing concept through expert walkthroughs, user feedback, and information architecture refinement

  • Designing a web platform for internal stakeholders to access and review diary entries

  • Supporting developers with continuous UX reviews and validations

  • Conducting onboarding for the beta phase
The Challenge

Construction workers on solar project sites (electricians, solar fitters, team leads, and site managers) are required to regularly log their work activities, team members present, weather conditions, and any incidents as part of a construction diary (Bautagebuch), a standard construction documentation requirement.

​

The existing solution required workers to log into Asana (a project management platform used internally to organise tasks and workflows) on a laptop, navigate to their specific project, and open a generic online form for documentation. Completing the form from the construction site was not possible. The form was shared across all teams AC and DC electrical teams forcing everyone through the same mandatory fields regardless of their role. Workers were spending 30+ minutes entering information that often didn't reflect their actual situation.


The core challenge was making this as effortless as possible for teams working under time pressure and in demanding site conditions, while ensuring the data collected remained structured, complete, and compliant for controlling, legal, and client reporting. Speed for the worker and completeness for the business were often in direct tension.

Design Process

01

​

Discovery

​​​

02

​

Definition

​​​

03

​

Design & Iteration​​

04

​

Delivery & Validation​​

01 Discovery Evaluating what has been done so far

The external team had already made significant progress, delivering a mobile app concept with role-adapted forms tailored to different user groups. Building on this foundation, I conducted expert walkthroughs of the user flow and gathered feedback from users, stakeholders, project managers, and the legal team to identify friction points and gaps in the concept.

02 Definition Uncovering the real problems

The walkthroughs and feedback revealed a clear pattern: the form had been designed around what data needed to be collected, not around how and when workers actually needed to record it. The specific findings were:

BTB Insights.png

Insights gathered from review and feedback

03 Design & Iteration Designing targeted improvements

Based on the findings, I redesigned the flow working backwards from the minimum inputs genuinely required per entry type and role.

Screen Variants Old Concept_edited.png

Previous user flow with many categories & poor usability with error scenarios

Screen Variants New Concept_edited.jpg

New and improved user flow, IA and error handling

Here are three key improvements and decisions that illustrate how I shaped the product.

Reducing Overhead in Documentation

The initial concept included seven categories with three mandatory fields. In urgent situations such as incidents or accidents, users had to complete mandatory fields covering weather, persons present, and general work activity before they could document the actual event. This created unnecessary overhead and slowed down critical reporting.


I proposed a flow that allows users to log incidents immediately, and secondary data such as materials and equipment captured afterwards. This reduced friction without compromising the completeness of the record.

Category page previous version (left) vs. new version (right)

Defining a Single Source of Truth for Weather Data

Because each log entry required its own weather input, multiple entries on the same day could show different conditions with no clear indication of which was correct. During a developer progress presentation, stakeholders raised this as a data consistency concern.


I proposed a single global weather entry per day, still editable by any user if conditions changed throughout the day. This balanced consistency with the practical reality of variable site conditions.

Day Screen (filled) weather.png

Weather section previous version (left) vs. new version (right)

Giving Internal Stakeholders Control Over Diary Data

While validating the export concept with project managers, it became clear that two related needs had not been addressed. First, photo inclusion in exports needed more control. A construction diary can hold hundreds of images, and some are intended for internal use only. Second, stakeholders had no centralised place to access and review diary entries across teams, relying instead on manual navigation through individual forms.


For the export, I proposed two concepts and reviewed both with the legal team. The preferred solution was a select-to-include toggle for photos at the point of export, with a separate download option for individual images to share with clients directly. This ensured no photos could be shared without a deliberate action from the user.


For the overview, I gathered the minimum required features directly from the PMs and designed a web platform integrated into the existing app. The platform gives project managers, engineers, planners, and AC/DC execution teams a structured overview of all diary entries, with photos, log details, and field data accessible in one place.

Shot Desktop.png

Flexible export function and web overview for stakeholders

These decisions reflect a fraction of the UX work done throughout the iterative development process, with continuous feedback loops between the product team, developers, and stakeholders.

04 Delivery & Validation Delivering the solution

The redesigned construction diary delivers:

  • A mobile-first experience embedded in an existing app, no laptop or Asana access required.

  • A streamlined entry flow with fewer steps to reach the core data logging function.

  • Role-adapted forms that display only the fields relevant to each team.

  • Smarter information architecture that prioritises urgent tasks and groups related inputs logically.

  • Draft saving so users can complete entries across multiple sessions without losing progress.

  • A single daily weather record as the consistent source of truth, editable throughout the day.

  • Controlled photo export with deliberate opt-in, plus individual image downloads for client sharing.

  • A web platform giving project managers, engineers, planners, and execution teams a centralised overview of all diary entries.

 

Once the MVP was complete, I onboarded three project teams, including project managers, electricians, engineers, site managers, and solar fitter leads, for the beta phase. The construction diary was actively used in the field, and follow-up interviews were conducted to gather structured feedback on the experience.

Shot BTB 8 mobile screen mockup.png

Construction diary mobile app screens

Outcome

  • Construction site teams from Beta Testing replaced a 30+ minute laptop-based process with a 5-10 minutes mobile entry directly on site.

  • Feedback from all three testing teams confirmed the app was significantly faster and easier to use than the previous solution.

  • Internal stakeholders accessed the centralised diary entries through the web platform for the available projects.

bottom of page