Case 01 / Concrete operations software

The concrete lifecycle across web and mobile.

At NEXPLORE Technology, part of the HOCHTIEF Group, I led UX for BCQD. I translated construction-site research, business rules and data constraints into coherent workflows released in Germany and the US.

Conceptual construction workflow connecting site, office and shared product modules — BCQD systemConceptual visualization, not production UI

RoleUX/UI Designer

ProductBCQD

SurfacesWeb + mobile

MarketsGermany + US

01 / Product context

Digitizing the concrete lifecycle

BCQD digitized an existing concrete workflow across order creation, delivery, quality checks, testing and documentation. Construction teams, site users and concrete suppliers needed shared information, while web planning and mobile work on site required different interaction priorities within one coherent product model.

Workflow surface

Order to documentation

The product connected ordering, delivery status, verification, quality control, testing and the records required after a pour.

Physical operations

Site and office

Mobile use on construction sites and web-based planning needed one coherent product model with different interaction priorities.

Domain constraint

Specialist accuracy

Vocabulary, ordering logic and operational reality could not be simplified away. They had to become understandable product behavior.

Cross-market delivery

Germany and the US

The interaction model supported releases in two markets while contributing to a globally aligned UX working method inside Nexplore.

Public context: Nexplore describes its HOCHTIEF Group relationship and lists both HOCHTIEF and Turner among the companies it works with. The signed project evidence documents BCQD releases in Germany and the US, so this case uses the verified markets rather than assigning the product to one specific subsidiary.

02 / Operating system

Actors, rules, data and handoffs

I treated the product as a connected operating system, not a set of isolated screens. User evidence had to be reconciled with specialist process knowledge, data mappings, technical feasibility and different interaction contexts across web and mobile.

Primary users

Construction-site users

Real operating behavior and usability analysis anchored the product model.

Domain input

Operational experts

Specialist knowledge supplied the rules, vocabulary and process reality behind the interface.

Product translation

Business + process design

Business processes were made explicit before being translated into requirements and interaction flows.

Feasibility

Architecture + engineering

Technical feasibility, data mappings and implementation constraints shaped the chosen direction.

01Observe work on site

02Model business processes

03Connect user and data flows

04Prototype web and mobile behavior

05Align feasibility and delivery

This is an anonymized reconstruction based on documented project responsibilities. It does not reproduce confidential production screens or client data.

Explore process and systems depthOwnership, system decisions and implementation bridge

03 / Independent ownership

Carrying UX from research into delivery decisions

Within my UX remit, I worked independently while keeping the product deeply cross-functional. I built the necessary domain knowledge, selected the right artifact for each decision and brought users, process design, business analysis, architecture, operations and engineering into the decision at the right moment.

When the process needed clarity

I made actors, operational goals, rules and constraints explicit before defining interface behavior.

When the domain was unfamiliar

I learned from construction-site users and operational experts, then analyzed, categorized and prioritized the findings.

When teams needed alignment

I translated business processes into user flows, data mappings, wireframes, mockups and interactive prototypes that made tradeoffs discussable.

When feasibility shaped UX

I worked with software architecture and engineering so the proposed behavior respected implementation constraints and the product vision.

When the product needed to scale

I connected local product decisions to the global design system and transferred the working approach to related products.

Independent does not mean isolated

Own the next decision, bring in the right evidence and leave the team with a buildable model.

The employment evidence explicitly confirms self-directed work, initiative, rapid understanding of complex processes and attention to technical feasibility.

04 / Systems decision

Standardize behavior before visual polish

Observed

Business processes were complex, domain-specific and spread across web, mobile and a wider product landscape.

Product question

How can teams create consistency without forcing every product and operating context into the same screen structure?

Decision

Translate the process into shared user flows, data mappings and interaction behavior, then express the proven patterns through the design system.

Tradeoff

Preserve domain and product-specific rules while standardizing the parts users should be able to predict across applications.

System implication

The working method and interaction language could transfer from the concrete-ordering product to further Nexplore products such as Minerva.

Artifacts as decision tools

Requirements → user flows → wireframes → mockups → interactive prototypes → reusable patterns

Each artifact reduced a different uncertainty: process fit, information order, interaction behavior, user comprehension, technical feasibility and cross-product consistency.

05 / Design + technology

Bridging craft, system and implementation

The role extended beyond handing over static screens. I connected interaction decisions with existing frameworks, platform conventions, data relationships and a changing technical foundation.

Mobile foundation

Apple HIG

Created the initial mobile design around native interaction expectations and the realities of use on site.

Web foundation

Ant Design

Applied and extended component behavior while keeping the specialist workflow understandable.

Technical change

Angular to React

Supported redesign work during the frontend transition instead of treating migration as an engineering-only concern.

Implementation bridge

Mappings and code

Worked close to data mappings and code so business processes, interface behavior and feasibility remained aligned.

06 / Outcome

Delivery and what the evidence supports

From construction-site research to web and mobile releases in Germany and the US.

The available employment evidence credits a material contribution to both releases and to a standardized, globally aligned service-design way of working. It also documents transfer of the approach to Minerva. I do not attach an invented adoption, revenue or efficiency metric to that work.

Product definition

From process to product

Research, domain learning and business-process translation produced a product model teams could design and build.

What scaled

Product behavior

Shared process and interaction logic supported web, mobile, the global design system and related products.

What shipped

Cross-market releases

The work materially contributed to concrete-ordering releases in Germany and the United States.

Measurement integrity

No invented KPI

Market releases and system transfer are documented. Adoption, revenue and efficiency were not attributed to me in the available evidence.