Sufficiently Advanced Design
2019-03-16_15-28-30--production-detail001.png

Conductor

Conductor

Conductor is an innovative take on manufacturing business software. It was built to manage small-parts aerospace manufacturing through a local supply chain of machine shops.

Project Timeline

2009–2010: Research

Performed competitive analysis, user inteviews, user shadowing, and stakeholder interviews. Business and process analysis. Studied production management.

2010: Synthesis

Extracted design directions from research results with mental models, simple personas, process flow notes, and sketchboards

2010-2015: Design

Scenarios built from mental models and storyboards were built into paper protoypes, task-flow sketchboards, and clickable interaction prototypes

2011–2015: Phase 1

Acted as product owner with development team to build full production version of Conductor

2017–2018: Phase 2

Development continues with emphasis on improvements to production queue, reports, and inventory cleanup

 

Research

The first step was to figure out what exactly the company's needs were, and whether an existing product could meet those needs. Over the course of 2009–2010, I shadowed and interviewed users, collected documents and artefacts, and mapped the business’s processes. My goal was to work out exactly how the business actually ran, and to identify the pain points which caused daily confusion and delays.

Synthesis: Business Analysis

When I began this project, no-one could tell me the story of how the business converted raw material into parts and shipped them to the customer, from start to finish. So we had to fix that.

When are those parts from United coming in?
— Dick, Operations Manager

Synthesis: Mental Models

I broke down the actions people undertook in order to accomplish their jobs, and arranged them in mental model diagrams, which link related actions into a legible framework of “towers”.

Required resources are below each tower, color-coded by type. Relevant information to display is blue, external information sources are green, and required functions or tools are yellow.

Mental Model diagram shows required tools and information

 

Synthesis: Scenarios & Storyboards

I based scenarios on the mental models, and validated them with stakeholders. Analysis of the scenarios and storyboards gave us a starting point to sketch screens, and arrange them into workflows.

Pulling out “functional needs” and defining the functional elements to be designed in order to meet those needs

Sketching storyboards with first pass ideas at the functional elements

 

Design: Sketches

I used rapid 6-up ideation sketching for screens. Get the first 2–3 down on paper, and then there's still 3–4 boxes to be filled. It's a good defense against getting stuck on your first idea.

The scenarios and storyboards were then analyzed to determine what elements needed to be designed. Those were refined with paper sketches. I developed those into paper prototypes, or arranged them in visual workflow diagrams on sketchboards. I used these to walk the developer through the screens and flows of the application design.

 

Design: Prototypes

I used interactive prototypes for user testing, and iterated the designs before submitting for production by a contract developer.

The refined prototypes were checked into a bug tracker, and I used them to validate the build.

Prototype: Order Raw Material (Excerpt)

Prototype: Order Raw Material (Excerpt)

Early prototypes were built using Keynote. For later prototypes, I used Bootstrap.

Bootstrap prototype of a production detail view

 

The process of moving from prototype to production was long and complex, and I'm only going to highlight a few elements.

Each component was user tested, and I acted as both project manager and QA lead.

Build: Part Numbers

I worked with the developer to edit and import the manufacturing operations for hundreds of part numbers.

We have to be able to order material and start production while the BOM is being written.
We also need to keep that from causing an escape [of bad parts].
— Steve, Quality

Traceability and version control of manufacturing operations were critical

Design of the workflow for managing manufacturing process operations required many iterations and multiple interactive prototypes.

Build: Print Design

I designed the layout for PDF print versions of critical production documents such as travelers and purchase orders. All print designs were built on a universal 8-column, 64 point grid with 12 point gutters.

The document numbers on the printouts could be used to instantly look up any document; the QRCodes allowed iPad users to easily perform actions on parts, such as moving their location or beginning a process.

Travelers are the canonical record of everything that has happened to a part, from beginning to end.

Purchase Orders accompany parts to suppliers, and are the way we keep track of production in the supply chain

What is this? When did it arrive? Why has it been just sitting here?
— Everyone

Build: Production Management

Once the necessary conditions were in place and validated, we were able to begin tracking all part movement through Conductor.

We designed a Production Queue to allow management to control and schedule production through our own internal operation centers.

The Production Queue was sketched together with a production manager on a whiteboard. Its initial purpose was to be an “Action This Day” list, but has since migrated to more of a way of managing everything active throughout the business.

I really need to be able to see and control everything that’s coming through our internal bottlenecks
— Pete, Operations Manager

Employees in a production center select their next job from the queue, locate the parts, and start the operation. That job moves to the In Process list at the top of the queue.

When they complete the job, we log the process time for later tuning of lead times and production schedules.

The production queue shows all parts being worked on and the hot and active part numbers being moved through this queue

THe production manager can drag and drop parts to reorder them, add notes, and mouseover to see operation instructions

 

Build: Reports

A primary goal was to eliminate spreadsheets and manual tracking of business functions.

A real surprise was how big and varied real-life production data was. I learned to begin report design with a simple HTML table, and not get too attached to a design until I saw the actual data.

Show me all the material I have on order. And when it’s coming in.
— Jim, Purchasing

Conclusion

Phase 2 of Conductor's development is ongoing; report design and refinement have been handed off to an internal team.

This project required an enormous amouunt of growth and learning. I am still collecting and going through all the material and documentation for the project. Case studies for the various design problems faced and overcome are in progress.