Fragmented tools
People moved between tools without a clear view of the whole journey.
← All projects
CCEE · Enterprise workflows
Procurement: review the journey before migrating
A focused UX engagement to simplify forms, understand the purchasing journey and prioritize changes within a fixed implementation deadline.
↳
A form review became a journey review
At CCEE, the business area responsible for procurement asked me to audit existing forms and content ahead of a new system rollout. The deadline was already set. With the team, I examined what could be simplified and migrated within the software’s predefined workflows.
The work combined an audit, workshops with project managers and business-area managers, form adjustments and a review in the configured system. Broader process changes were prioritized in an evolution roadmap.
Read the context and decisions ↓
Later representation based on the project account, not the original workshop artifact. Tracking spans the process; the stages are a simplified reading of the journey.
01
A process shaped by an earlier way of working
Procurement covered office supplies, equipment, outsourced staff and consulting services. Forms differed by purpose, with a simpler path for office materials. The new system would support requests, managerial approvals and the procurement team’s records of tendering and purchasing.
The existing process was spread across tools and retained requirements from the company’s earlier in-person operation. Understanding what had to happen, where a request stood and who needed to act was difficult.
02
Choose a method that fits the time available
I initially wanted to conduct interviews. With approximately one month and an approaching launch, I chose workshops to bring the managers’ perspectives together. I planned and facilitated the sessions with support from the responsible business area.
Participants mapped the user journey and concentrated on pains and opportunities. Their exchanges exposed differences in how the same process was understood and followed. I then analyzed the inputs with the team to distinguish useful, feasible changes.
The workshops provided a shared view quickly; they did not replace individual interviews or observation of day-to-day work.
03
What the workshops revealed
Unclear requirements
Form fields and terminology needed explanation and context.
Status and ownership
The current status, pending action and responsible person were not sufficiently visible.
Uneven records and too many alerts
Updates varied between requests, while notification volume made it harder to follow what mattered.
04
Separate launch needs from process evolution
The software offered predefined journeys and information architecture. Customization was limited, mainly to branding and additional form fields. Most opportunities identified in the workshops concerned the business process itself.
Simplify what people must understand and enter
- Review form stages, fields and terminology.
- Add detail and context where necessary.
- Adjust cost-center information within the supplied workflow.
Give broader changes an explicit next step
With the team, I prioritized useful and feasible changes and organized a roadmap. We presented it to the managers; many process changes remained planned for after the system rollout.
05
Review behavior in the configured system
After the adjustments were applied, I reviewed the forms in the new system to verify field behavior, rules and conditional actions. This checked how the definitions worked within the platform’s constraints.
One continuity question remained
Requesting and tracking were separated into two modules. I raised the question of how someone would find and follow a request after submitting it. This was a risk identified in the review, not an observed usability failure.
06
Deliverables and the boundary of the evidence
- Audit of existing forms, content and workflows.
- Facilitated workshops, a shared journey and a synthesis of pains and opportunities.
- Simplified forms and functional review in the configured system.
- Prioritized evolution plan presented to participating managers.
My involvement ended with the plan presentation and the review of the new system. I did not track post-launch support volume, satisfaction or implementation of the full roadmap.
The key lesson was to distinguish friction in the business process from the limits of the tool, then make that distinction actionable within the launch deadline.