Case study 03 / Distributed engineering

DDMB

Some engineering teams literally had webcams pointed at physical Kanban boards.

The questionHow do distributed engineering teams maintain a shared visual understanding of work without losing what made their physical boards useful?
Organization
TechnipFMC
Context
Global engineering visual management
Contribution
Research, product design, React contribution, launch and iteration

01 / The situation

Distributed work made a local coordination tool hard to share.

Engineering teams used visual-management boards during daily standups to understand work waiting to begin, work in progress, changing priorities, status, and workload. Different groups developed different approaches: physical whiteboards, Jira, Microsoft tools, and, in some cases, webcams aimed at a board for colleagues elsewhere.

The problem was not simply “we need Kanban software.” It was preserving shared visual understanding across distance without discarding the practices teams depended on.

Evidence placeholderFrom physical board to shared environmentApproved product media needed
01Physical-board / webcam concept02Digital engineering board03Team and global distribution

02 / Discovery and product decision

Custom enough to fit the work. Shared enough to reduce fragmentation.

I participated heavily in interviews, stakeholder conversations, synthesis, personas, journeys, pain-point analysis, desired behavior, MVP scope, and validation with users and leadership.

The product had to work across multiple engineering groups without becoming another generic Jira clone. The team built a browser-based visual-management system around TechnipFMC’s engineering practices and connected it to Oracle Primavera P6.

03 / My role

Designing across users, leadership, and implementation.

My work spanned research and synthesis, personas and journeys, product and interface design, Sketch prototypes, leadership presentations, stakeholder validation, MVP and feature discussions, collaboration with product management and engineering, and relationship-building with engineering managers.

I also contributed to the React front end, supported launch, and stayed involved as real use revealed where the system needed to change.

04 / What we built

Visibility beyond one team’s board.

Distributed teams could access current board information from a browser at any time. Subtasks could relate across boards, helping people answer not only “What is my team doing?” but “How does our work relate to another team’s work?” Scheduling stakeholders gained a clearer view of engineering progress through the P6 relationship.

The system was adopted across engineering organizations in the United States, Brazil, India, Singapore, Scotland, and Norway, at a scale I remember being in the hundreds of users. An exact count is not available.

Evidence placeholderCross-team and scheduling relationshipsApproved product media needed
01Digital board02Cross-board dependency03Oracle Primavera P6 relationship

05 / Learning after launch

A prototype can look resolved and still contain assumptions that only become visible in use.

The initial status system relied heavily on red, yellow, and green. Real-world use exposed that some engineers with color-vision deficiencies could not reliably distinguish the states.

Before

Color carried the meaning.

After×!

Iconography reinforced each state.

We revised the product instead of hiding the mistake. The outcome was a persistent browser-based environment with greater visibility, cross-team awareness, and less fragmentation than participating teams’ previous collection of boards, webcams, and generic tools.

Evidence still needed

TODO: Add approved product media and any verified adoption or stakeholder evidence.