Alloy Specialties is a manufacturer of precision-machined engine parts for military and commercial turbine engines. They act as the control center for a loose federation of manufacturers, who have little to no IT infrastructure or MRP capacity.

How might we better track and control the manufacturing process so that we see reduced confusion and errors?

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.

“Swim Lane” diagram, showing the complex process required for aerospace manufacturing

For this project, I emphasized roles, rather than personas, as we had many roles, and very few users per role.

Necessary Condition Logic diagram; primary goals are listed at top, and the necessary elements to achieve those goals are below, shown in relation to each other.

Analysis of the issues impeding the company’s ability to scale to meet increased demand.

“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

Mental Model: Begin Production

Shows the process of ordering raw material and beginning manufacture

Mental Model: Shipping

In-process shot of meeting with production and shipping personnel

Process notes on inventory movement, taken while shadowing operations staff

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.

Production storyboard: defining how and why the production report view would be used (part 1)

Production storyboard: defining how and why the production report view would be used (part 2)

Development sketch for a production overview page, based on storyboards. Purpose: Allow production management to discover, select, and focus on parts which need attention, during morning meetings.

Detail view for WIP inventory on a part. Purpose: Show where everything is in production, relative to lead time and due dates.

Alternate sketch for detail view: a more conventional table.

Sketch for report showing current work-in-process (WIP) inventory at suppliers. Purpose: improve visibility and control of supply chain, and maintain our own due dates

Broad ideation sketching for production workflow display & editing

Rapid storyboarding on index cards: for very simple interactions, sketched thumbnail details of each stage of the story. Purpose: communicate a scenario very early in the process in order to get stakeholder feedback.

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.

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.