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.
For me, that meant leading our delivery team while partnering with the incoming Infor leadership. The user challenge remained: clarify the relationship between Solutions, Products, and Industries, and make content easier to find.
A shared plan
Make the work—and the decisions—visible
I led planning and delivery coordination for our team, using a shared roadmap to connect research, design activities, dependencies, and milestones. During the leadership transition, that plan gave our team and Infor’s new stakeholders a common reference for reviewing priorities and 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
Clarity matters more than another layer of process
Leading through a transition made the relationship between people, decisions, and design especially clear. I needed to give our team direction, work with new internal partners, and stay close enough to the design to make the conversations concrete.
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 is the work I enjoy: bringing clarity to complex efforts, helping people collaborate, and keeping the experience we are building in view.
