Internal Tools for High-Volume Print Operations
Designing internal tools to make fragmented machine and production data understandable and actionable across Amazon Books print-on-demand operations.
I worked as the primary product designer on an internal-tools project for Amazon Books print-on-demand centers, where individual facilities were capable of producing up to approximately 50,000 books per day.
Running these facilities required information spread across roughly five internal web applications. Experienced managers knew where to look, which values mattered, and what combinations of data indicated problems. Floor workers generally did not have that same accumulated knowledge.
I designed a new tool that brought this information together and translated machine and production data into actionable information, making more operational tasks understandable to more people without requiring them to memorize what values across multiple systems meant.
The project explored both an incrementally buildable dashboard and a more forward-looking interface that could proactively surface relevant information and tasks. The latter also became part of ongoing research with floor workers.
I was effectively the primary product designer for this project while temporarily replacing another designer who was on leave.
- Reviewing existing research into print-on-demand operations
- Working with a third-party researcher to identify research questions and plan additional studies
- Understanding workflows across approximately five existing internal applications
- Identifying which information experienced managers used to recognize production problems
- Designing ways to translate raw machine values into understandable alerts and actions
- Exploring progressive disclosure for users who needed access to underlying machine data
- Designing a consolidated operational dashboard
- Designing a more proactive, forward-looking interface for contextual information and task support
- Creating prototypes for continued research with print-floor workers
- Working across distributed ownership of product, design, development, content, and operational decisions
- Contributing to additional design tickets and smaller projects across the team
Amazon Books print-on-demand was already a mature, high-volume operation, with individual facilities capable of producing approximately 50,000 books each day. But the software supporting that work had developed piecemeal over time rather than as a unified operational experience.
Information required to keep production moving was spread across roughly five internal web applications. An experienced manager might know to open several tools, navigate to particular screens, scroll to specific values, interpret those values in combination, and then tell a floor worker what action needed to be taken.
The underlying data might indicate that a paper roll was nearly depleted, ink needed attention, material needed replacement, or a book had stopped progressing through production. The applications exposed the data, but much of its operational meaning existed as knowledge accumulated by experienced employees.
That created both an interface problem and a knowledge problem. Floor workers generally could not act on the same information without first knowing where to find it and what particular values meant.
My project was an opportunity to begin replacing that piecemeal experience with a more intentional operational tool: bringing relevant information together, translating machine data into understandable conditions and actions, and exploring how the system could proactively surface what workers needed to know.
The larger question became: How much of the expertise required to interpret these systems could the product itself provide?
I reviewed research that had already been conducted and worked with a third-party researcher to determine what else we needed to learn and how subsequent research should be structured. I also examined how operational information was distributed across the existing applications and how experienced employees moved among them to understand what was happening on the print floor. The problem was not simply that information existed in different places. The meaning of that information often depended on knowledge employees had accumulated through experience.
A central design opportunity was to move from displaying machine values to explaining what those values meant. For example, rather than requiring someone to find and interpret the current state of a paper roll, the system could identify that it was approximately 90% depleted and surface a warning. When the roll was exhausted, that could become a more urgent error with a clear indication of what required attention. The same principle could apply to ink, other consumable materials, stalled books, bins, and other production conditions. This allowed the interface to shift from "Here is the data" to "Here is what is happening, how urgent it is, and where attention is needed."
Simplifying information could not mean hiding it permanently. Experienced users might still want the actual machine values, and those values could be important when investigating why an alert appeared too early, too late, or incorrectly. I explored progressive disclosure so the interface could lead with understandable status and action while still allowing users to inspect the underlying data when greater detail was useful. This created a path for both less experienced workers and people with deeper operational knowledge to use the same system.
One design direction was a dashboard that brought useful information from the existing applications into a single operational view. This approach was deliberately modular. Individual pieces could be developed independently, allowing the team to start with whichever information research showed to be most useful rather than requiring the entire new system to be built at once. The dashboard could therefore provide immediate value while expanding progressively over time.
I also designed a more forward-looking prototype that explored how the system could use Amazon's technical capabilities to become more proactive. Instead of requiring workers to continually search for information, the interface could surface the information or task most relevant at a particular moment. The goal was to explore a shift from software that primarily reported production status toward software that could help direct attention and support the next useful action. This prototype was also used in research to ask floor workers whether this kind of experience would be useful to have available during their work.
Rather than treating the prototypes only as proposed solutions, we also used them to help answer questions. I worked with the third-party researcher on study planning, and the forward-looking prototype became a way to make a potential future experience concrete enough for floor workers to react to. A third phase of research began after my time on the project ended, so I did not see the eventual research findings or subsequent product decisions.
Another challenge across this project and my other work with the team was determining who owned particular decisions. Design, development, content, operational knowledge, and approval could belong to different people, and even relatively small projects could require identifying and coordinating several owners before work could move forward. On one smaller project, I was temporarily identified as the owner myself, which shifted how I approached the work. I became responsible for making sure decisions and changes were reviewed rather than simply completing an assigned design task. Although that ownership later changed when another team member returned from leave, the experience gave me useful perspective on the difference between contributing design work and being accountable for the larger outcome.
The existing tools exposed data that experienced managers knew how to interpret. I designed around the idea that the product should communicate the operational meaning of that data directly, reducing dependence on accumulated institutional knowledge.
Alerts and plain-language status could help more workers understand what required attention, while progressive disclosure preserved access to raw values for experienced users and troubleshooting.
The dashboard concept brought fragmented information together through modular pieces that could be developed incrementally. The team could prioritize the most valuable information first and expand the experience over time.
The second prototype went beyond consolidation and explored how the system could surface relevant tasks and information proactively. Keeping this as a forward-looking concept allowed us to investigate a more ambitious direction through research without making the near-term dashboard dependent on it.
The forward-looking prototype was intentionally useful as a research artifact. It gave floor workers something concrete to respond to and helped the team investigate whether a more proactive operational interface would actually be valuable.
I produced two complementary product directions for the print-on-demand operation: a modular dashboard that could consolidate information from existing systems and be implemented incrementally, and a forward-looking prototype exploring proactive task and information delivery.
The work also helped frame subsequent research. The more exploratory prototype was used to gather feedback from floor workers, and an additional research phase began after I left the project.
At the scale of Amazon Books print-on-demand operations, improvements to material usage, production time, stalled books, or unnecessary reprints could potentially have meaningful operational effects. However, I was no longer on the project when later research and implementation decisions occurred, so I do not have evidence showing which concepts were implemented or quantitative results from the work.
One challenge was that ownership was distributed across the organization. As I worked through individual parts of the experience, the team and I often also needed to determine who owned the underlying process, data, decision, content, development work, or approval.
That discovery was necessary, but it reduced the time available for design and made concepts harder to evaluate against clearly established measures of success.
If I approached a similar project today, I would map key stakeholders and decision owners earlier and work with the team to establish success criteria before moving deeply into design exploration. This would create clearer constraints for the work and make it easier to evaluate whether a proposed design was improving the operational experience.
The project also reinforced the value of designing around meaning rather than data alone. An interface can technically provide all of the necessary information while still requiring years of experience to understand it. Translating that information into understandable conditions and actions can make the same system useful to a much broader group of people.