TIBCO

Enterprise commerce & fulfillment systems

Role
Product designer
Scope
Product configuration, sales orders, fulfillment, onboarding
Scale
1,000+ products · 16+ departments · 2,000+ employees onboarded
Problem
In sales, fulfillment, and onboarding tools, errors entered early weren't visible until they surfaced downstream: in billing, in provisioning, or on a new hire's first day.
Strategy
Catch errors while people still have context and control, not after the system has processed the data. Design around the work people actually do, not around the database, and show the downstream impact of a choice before it's submitted.
What I did
Replaced a 50-field product form with a copy-and-update table built on the team's spreadsheet habits, turned a 100+ field sales order into a guided flow that validates each decision and previews fulfillment impact, and organized onboarding across 16+ departments around dependencies instead of the org chart.
Result
80% faster configuration across 1,000+ products, with support requests down from about 7 a week to near zero. 60% fewer sales-order support tickets. 2,000+ employees from acquisitions onboarded in time for Day 1.
Product configuration · Research changed the direction

I didn't make the 50-field form easier. I replaced the model.

Observation showed 95% of updates changed only two fields. So instead of a form, the team copies existing rows and edits those two values, with validation the spreadsheet never had. 80% faster; support requests dropped from about 7 a week to near zero.

Engineering model

Rejected in testing
50+ fields
Complete product record
Form submission

User model

Shipped
Select existing rows
Copy
Change 2 fields
Submit
Show the reasoning · failed prototype, field research, tradeoffs, the shipped screen

How research changed the direction

  1. Engineering's starting point: a 50+ field intake formCapture every product detail per entry. Logical for data completeness.
  2. First prototype rejected immediatelyI built and tested it with the Fulfillment team: "Too cumbersome." The approach was wrong, not the details, so I stopped iterating on it.
  3. Observed the real workI watched the team use their spreadsheets in context instead of testing more prototypes.
  4. The insight95% of maintenance was product upgrades, which only changed product status and SKU number. The team copied rows and edited two values.
  5. Shipped: copy rows, update two fields, submitThe interaction pattern was one they already knew; only the reliability was new. A full form stayed available for brand-new products.
ApproachData completenessLikely adoptionFits real work
50+ field form (rejected)HighVery lowNo
Copy row + 2 fields (shipped)Enough for 95% of casesHighYes
Full form, new products onlyHigh (5% of cases)High (rare use)Yes
Insight
The 50-field form was solving the data model, not the user's job.
Decision
An editable table built on the team's spreadsheet mental model, with structured validation the spreadsheet never had.
Result
80% faster task completion. Support requests dropped from about 7 a week to near zero, and management gained one live view of the product repository instead of scattered spreadsheets.

The interaction, step by step

  • ① Select rowsA checkbox on each row, plus select-all.
  • ② CopyThe copy action sits right next to the table.
  • ③ New rows appearCopied rows are appended and marked New.
  • ④ Next SKU generatedThe system calculates the next SKU number, so no one does it by hand.
  • ⑤ Update what changedOnly status and SKU are editable.
  • ⑥ SubmitValidated data goes straight to Oracle.
Enterprise Product Master list view at TIBCO
The shipped list view inside TIBCO's existing enterprise UI. Usernames and IDs blurred for confidentiality.
Sales order submission

From 100+ fields to a guided decision

Large orders arrive minutes before quarter close, and an error means revenue isn't recognized. I reorganized the form around the decisions users make and validated each step as they went. Support tickets dropped 60%.

1 · ChooseRelevant fields appear based on earlier selections
2 · ConfigureRelated fields grouped around the user's mental model
3 · ValidateErrors caught immediately, while there's context
4 · Understand impactProgress and downstream feedback
Show the reasoning · the user's pressure, shipped screens

"This is the nature of the business. Huge sales orders come 5 minutes before we close the quarter. I need to submit these last-minute orders fast and without errors or revenue will not be recognized for that quarter!"

— Fulfillment manager
  • Progressive disclosureOnly fields relevant to earlier selections appear, so a 100+ field form never shows all at once.
  • Persistent helpA help panel explains business rules, system restrictions, and downstream dependencies before users hit an error.
  • Visible progressStep indicators ease the anxiety of not knowing how long the form is.
  • Downstream impactReal-time feedback shows how an order will affect fulfillment before it's submitted.
Also at TIBCO
Employee onboarding: designed around dependencies, not departments Centralized onboarding across 16+ departments, integrating PeopleSoft, Active Directory, Oracle, and Salesforce. Reduced error tickets by ~60%, and automated bulk onboarding for 2,000+ employees from acquisitions, with accounts and welcome emails ready for Day 1.
InsideTIBCO knowledge hub
InsideTIBCO knowledge hub: designed around the contributor's mental model Replaced hard-to-edit templates (some requiring HTML) with structured layouts and a rich-text editor. Published content increased ~40% as contributors who had avoided the portal started publishing.
Engineering partnership. Seven years as a TIBCO engineer meant I could design with firsthand knowledge of the APIs, data dependencies, and Oracle integrations underneath, so the interactions matched the underlying system rather than fighting it.
What I'd do differently

I'd observe before prototyping. The spreadsheet encoded 15 years of workflow knowledge that wasn't visible in the requirements, and watching the team first would have surfaced the two-field insight before the 50-field prototype was ever built.

I also assumed approaches that worked for the broader audience would fit this group. I'd invest earlier in understanding each team's unique needs.

All work Next: AiSL