Work

Work

Completed client systems and public research.

Three anonymized consulting engagements and two public notes from BEBEL’s product R&D.

Case studies

Three consulting engagements.

Client names and proprietary details are omitted. The problems, work, and deliverables are described directly.

Data foundationMulti-site operations

Make a changing portfolio behave like one data system.

Problem:
A multi-site operator needed reporting to follow locations through ownership and financing changes without losing the ability to view each location on its own.
Work:
Resolved mapping gaps across source systems, created a parent-group structure, and carried the grouping logic into existing and new dataflows and reports.
Delivered:
One reusable reporting structure for both location-level and portfolio-level views.

Reporting systemsProperty operations

Replace brittle email-fed reporting with a maintainable data path.

Problem:
A weekly performance report depended on emailed exports and connectors that had become difficult to maintain.
Work:
Moved the source path to a database-backed import, automated distribution, configured groups, permissions, and alerts, and documented the datasets, dataflows, and dashboard.
Delivered:
A maintainable reporting workflow with a clearer source path and enough documentation for the client team to operate it.

Operational analyticsWorkload planning

Turn assignment data into a workload view.

Problem:
A customer-relationship platform could not provide the workload and stage views a team needed across people and departments.
Work:
Reviewed and restructured the source datasets, built a separate visualization layer, and validated both the data and reporting format.
Delivered:
An operational view for monitoring assignments, stages, and workload across individuals and departments.

Research

Questions we tested.

Two public notes on incomplete evidence and interface review, with the methods, findings, and limits.

Decision systems: Research note · August 2026

When incomplete data should stop an answer.

A tested refusal rule keeps an assumed denominator from becoming a precise-looking recommendation.

Finding:
When a required denominator was missing, the tested rule refused the comparison instead of inventing a precise result.
Boundary:
This supports one prototype and its tested conditions, not every decision or production use.
Read the research

Interface design: Research note · August 2026

What automation misses in an interface review.

The study compared automated checks with structured human review on the same prototype surfaces.

Finding:
Automated rules and structured review found different failures across the same prototype surfaces.
Boundary:
This was not assistive-technology testing, disabled-user research, or accessibility certification.
Read the research