Leading the redesign of infor.com
Leading a multidisciplinary team through a website redesign and a major change in internal leadership.
The starting point
The question sounded simple: how should people find the right Infor product? Answering it meant connecting how visitors thought with how the business described its offering—and what the technology could support.
I led a team of UX and UI designers, researchers, and business analysts. My role combined design direction, program leadership, and hands-on UX work—connecting the team’s expertise with the decisions needed to move the redesign forward.
January–October 2024 · Working with design, engineering, and business stakeholders.
My contribution
I led
A team of UX and UI designers, researchers, and business analysts. I guided design direction, work planning, reviews, and delivery coordination, supported by shared DesignOps practices.
I partnered
With Infor’s incoming internal program leadership, business stakeholders, and engineering on priorities, requirements, and technical feasibility.
I worked hands-on
On navigation recommendations, information architecture, mobile-first prototypes, and stakeholder presentations.
The challenge
A redesign through organizational change
During the project, Infor’s previous internal design team was laid off and its design organization was dissolved. A new internal team took over leadership of the program. Alongside the redesign, we had to navigate a change in stakeholders and rebuild shared understanding of the work.
I had to steady our delivery team while building trust with Infor’s incoming leadership. I made the work, open questions, and decision owners visible so the transition did not erase the context behind design recommendations. The user challenge remained: help visitors understand the relationship between Solutions, Products, and Industries.
A shared plan
Make the work—and the decisions—visible
I led planning and delivery coordination for our multidisciplinary team. The shared roadmap connected research, design activities, dependencies, and milestones; during the leadership transition, it gave new stakeholders a concrete place to challenge priorities and agree next steps.

Make the open decisions explicit
When presenting the proposed sitemap, I called out two unresolved questions: how the business would define its solutions and products, and whether the proposed structure was technically feasible. The recommendation gave stakeholders something concrete to respond to; checkpoints kept the next steps visible.
I led the design recommendation and the discussion around it. Business definitions and technical feasibility required partnership with Infor stakeholders and engineering.
How we worked
Build a rhythm the team can use
I established shared tracking and review routines for the team. Airtable brought tasks, milestones, dependencies, and risks into one view, giving our conversations a concrete starting point: what was moving and what needed attention.

Retrospectives created space to revisit blockers and adjust how we worked. Alongside delivery, design-system documentation and navigation governance provided guidance for maintaining consistency as the site evolved.
Design informed the plan
Connect the plan to visitor needs
I led the design direction with input from our researchers, designers, and business analysts. Journey mapping and research grounded the navigation work in visitor needs; the IA plan called for building on existing strategy and artifacts to avoid duplicating effort.

Two ways into the same offering
The card-sorting synthesis led to a navigation hypothesis: some visitors start with their industry; others start with a solution or product. I presented recommendations for both paths, with clearer links between them. We treated the sitemap as a proposal to refine and test, rather than a finished answer.


Make the direction tangible
Alongside leading the team, I developed mobile-first prototypes and contributed to reusable patterns. UX and UI design, research, and business analysis remained a team effort. I used reviews to connect those contributions, while testing and engineering input informed refinements.


What we built
A shared view of delivery
The roadmap, task tracking, and review routines brought milestones, dependencies, and open questions into the team’s planning.
Foundations for future work
Navigation governance and design-system documentation provided guidance for ongoing content and design changes.
A recommendation the team could evaluate
The proposed navigation connected research findings with business and technical questions. The sitemap, testing artifacts, and prototypes made that direction tangible for cross-functional review.
How I would measure progress
I would establish a baseline for these measures, then agree targets with the team. Together, they would connect the quality of the experience with the decisions needed to move delivery forward.
Task success
Visitors who find the right product or complete a key journey without help. Shows whether the navigation supports real needs.
Time to complete
Median time for the same priority tasks before and after a change. Helps focus effort on the biggest points of friction.
Decision turnaround
Time from a design decision being raised to an agreed next step. Makes delivery delays visible to program leadership.
What I carry forward
Lead with clarity and care
The redesign taught me that leading through change means protecting both the team and the reasoning behind its work. I gave our designers, researchers, and analysts a steady rhythm, helped new internal leaders see the open decisions, and stayed close enough to the UX to move those conversations forward.
Next time, I would agree on ownership and success measures earlier: what would show that decisions were moving, the process was helping the team, and navigation was easier to use. I would also bring localization into initial planning.
That balance still shapes how I lead: make roles and trade-offs clear, support the people doing the work, and choose the lightest process that fits the situation.
