Printing — Report Printing Feature

ecoPortal is a corporate incident management platform. Users regularly needed to export and print incident reports — but the platform had no native solution. The workaround was fragmented: manual screenshots, copy-pasting into other software, or printing via browser shortcuts with zero layout control.

What was missing was a controlled-layout print experience. An incident report in ecoPortal spans multiple sections — General data, Investigation, Witnesses, Evidence, Areas — and includes sensitive fields that need to be hideable before printing. Some users print for internal filing; others for external audits. The feature had to handle both without becoming a document editor.

"How do we give users real control over what and how they print, without adding unnecessary complexity to a flow that needs to be fast and reliable?"

The project started with a structured briefing with the product team and stakeholders. Demand came from two directions: support complaints from users and a business-side requirement for audit-ready physical reports.

The engineering team joined early to map technical constraints and define what was feasible within the 5-sprint scope. Initial scope: full incident report printing with configurable layout settings.

Three design questions emerged from the briefing and shaped every decision that followed:

• How do we handle fields the user doesn't want appearing in the printout?
• What level of customization makes sense without turning this into a document editor?
• How do we ensure the print output is faithful to the content without relying on browser behavior?

With the problem framed, I ran an open exploration phase before committing to any flow or interface structure. I reviewed how enterprise systems like Salesforce, ServiceNow, and Jira handle printing and exporting, and studied print layout conventions from legal and corporate documents.

Four hypotheses came out of this phase and held up through the entire project:

1. The user needs a live preview before printing — it can't be a surprise.
2. Configuration options belong in a persistent side panel, not a modal that blocks the content.
3. Redacting a field needs to be explicit, reversible, and visually unambiguous.
4. Empty states need to exist for every edge case: no pages selected, all content redacted, unavailable fields.

I consolidated three flows to be designed: the main flow (section selection → layout config → preview → print), the redaction flow (select sensitive fields → confirm → preview updates), and error flows (empty fields, unavailable sections, permission-locked content).

Before investing in hi-fi, I built lo-fi prototypes to test navigation logic and friction — not visual polish. Five internal users participated: security analysts and compliance managers representing the feature's real audience. Think-aloud protocol with moderation.

Four things were tested: panel placement (side panel vs. modal), the redaction flow, the comprehension of the "stages" concept (selectable report sections for printing), and section selection/deselection behavior.

Main findings:

• The side panel was understood faster — users could see the preview and the options at the same time.
• "Redact" wasn't intuitive without an explicit label; "hide from printout" worked significantly better.
• The Stages component needed clearer visual states — users couldn't immediately tell what was selected.
• Users tried clicking individual fields to remove them — an out-of-scope signal that pointed to a real, latent need.

This was the most valuable step of the project. Issues caught here cost only flow adjustments. The same problems discovered in hi-fi or during implementation would have been far more expensive to fix.

With test findings in hand, I revised the flows before moving to hi-fi. Every structural change made here was anchored in observed behavior, not assumptions.

What changed

Redaction label — "Redact" became "hide from printout" in intermediate flows. After alignment with the product team, it returned to a more technical label in hi-fi, appropriate for the platform's corporate context.

Stages component — Redesigned with three explicit states: checked, unchecked, and indeterminate. The visual hierarchy was reworked so users immediately understood what would or wouldn't be included in the printout.

Side panel confirmed — Validated as the right structure. Settings were reorganized into two logical groups: Page Options (header, page numbering, company logo) and More Options (images at the end, thumbnail sizes).

Unavailable fields mapped as a priority edge case — Fields locked by permission or business rules needed their own visual state. They couldn't simply disappear or appear editable — both would create confusion or errors downstream.

With validated flows, I moved to hi-fi — building on ecoPortal's Design System and specifying every state, variant, and edge case of the feature.

The final structure covers five areas:

Stages — Section selector for the printout. Each report section is individually toggleable, with checked/unchecked/indeterminate states. Users can print only what's relevant to their context.

Page Options — Standard header (SH) toggle, page numbering, and company logo (ON/OFF).

More Options — Header variants, page numbering toggle, images-at-the-end toggle, thumbnail size control, and company logo with live preview.

Security / Redacted Information — "Redacted" badge applied to hidden fields or sections. The preview reflects in real time what will appear in the printout.

Misc — Supporting components: empty state (web and mobile), mailbox field, disabled fields, unavailable fields with specific visual feedback, and React-inside-Angular integration specs for the engineering team.

Key design decisions

The two-panel layout — preview on the left, settings panel on the right — keeps the user in direct contact with the output while they configure. Page Options surface the essentials; More Options collapse by default, reducing cognitive load for users who just want to print quickly. All visual settings are inherited from ecoPortal's token system (Desktop/Mobile, ecoPortal Pro), ensuring consistency across the product.

Handoff wasn't the end of my involvement — it was the start of a new phase. I followed the entire implementation and owned Design QA.

Handoff included complete Figma documentation (spacing specs, color tokens, states, behaviors), interaction specs for the three complex flows (redaction, stage selection, preview updates), and two dedicated walkthrough sessions with the engineering team.

For QA, I reviewed each sprint's partial delivery against the design spec and documented findings with the PO. Main issues caught:

• Settings panel internal spacing off spec
• Redacted state visual feedback differing from design
• Preview behavior on smaller screens needing responsive adjustment
• Stages hover states not implemented

All issues were corrected before go-live. Treating QA as a formal, documented step — not an informal check — raised the engineering team's attention to detail from the start of implementation.

The feature shipped with high fidelity to the design. The 2x weekly cadence kept alignment tight without overhead. The flow-based Figma organization (Stages, Page Options, More Options, Security, Misc as distinct sections) made handoff and QA significantly faster — the engineering team knew exactly where to find each spec.

What I'd do differently:

• Test with external users. The lo-fi sessions used internal participants. A round with real ecoPortal users would likely surface usage patterns that weren't anticipated.
• Add a mobile responsive pass before handoff. The QA adjustments on smaller screens were avoidable.
• Map edge cases earlier. Some scenarios (permission-locked fields, image-heavy reports) surfaced during implementation rather than in the design phase.

Next steps for the product: post-launch usage analysis to understand which settings users actually reach for; a mobile-native version; and unifying printing and PDF export as a single flow.