Designing the Design Organization

Overview

Ticket Log by Edenred operated several fleet-management and payment products built by different teams, using different technologies and different ways of working.

Design was usually involved late in the process, after Product and Engineering had already defined the problem and selected a solution. Designers were expected to create interfaces without enough context, research, or influence over the final product.

I was promoted to Head of Product Design to create a formal design function and establish a better way for Design, Product, Engineering, Business, Support, Legal, Compliance, clients, and users to work together.

This case was not about redesigning one feature. It was about redesigning the service used to identify, design, build, validate, and improve every product experience.

My Role

As Head of Product Design, I led the definition and adoption of a new Product Design operating model.

The goal was to give designers clearer guidance and a stronger role in understanding user needs, defining problems, shaping solutions, validating implementation, and measuring results.

I remained directly involved in research, workshops, workflow design, documentation, accessibility, prototyping, testing, and delivery. I also supported hiring, onboarding, mentoring, workload planning, team development, and the early stages of the Design System.

Beyond creating a process, I helped change how the company understood Design and established a longer-term vision for more consistent, accessible, scalable, and future-ready product delivery.

The Challenge

The company initially had three Product Designers working independently across different products.

There was no shared design process, central source of truth, structured design backlog, consolidated UI library, or clear definition of Design responsibilities.

The existing workflow usually followed this sequence:

1. Business or Customer Support raised a request.
2. Product discussed possible solutions with Engineering.
3. The main decisions and delivery dates were defined.
4. Design received a request to create the screens.

Design was treated as a production step rather than a partner in identifying the right problem and defining the right solution.

This created several problems:

• Designers had limited context and little influence over decisions.
• Research and testing were often skipped because deadlines had already been defined.
• Designers worked independently and had few opportunities to exchange knowledge.
• Similar products had inconsistent interfaces and user experiences.
• Accessibility requirements were not consistently considered.
• Developers recreated similar components across products.
• Prototypes and final implementations often did not match.
• Rework increased development time and cost.
• Roles and responsibilities were unclear.
• Product decisions were based more on internal assumptions than user evidence.
• Designers had little visibility into the impact of their work.

The products also presented user-facing problems, including complex payment journeys, fragmented login experiences, inconsistent data fields, different interaction patterns across platforms, and accessibility barriers affecting internal and external users.

These barriers were especially important in operational and Customer Support systems, where several employees with disabilities used the products daily.

Understanding the Service

I treated the design process itself as a service.

The people using or participating in this service included:

• Product Designers
• Product Managers and Product Owners
• Engineers working across several product teams
• Business specialists
• Customer Support teams
• Legal and Compliance
• Executives
• International brand stakeholders
• Clients and other external stakeholders
• Truck drivers
• Fleet managers
• Business owners
• Employees with disabilities using internal systems

To understand the current state, I interviewed designers and Product stakeholders, spoke with Engineering and Support teams, reviewed customer-support tickets, examined analytics and data consistency, observed existing workflows, and gathered feedback from users in different roles.

Customer Support was especially valuable because it provided direct evidence of recurring user problems. Its employees also helped identify accessibility barriers and operational issues that were not always visible to the product teams.

This research helped us understand both the user-facing experience and the internal teams, processes, systems, and decisions behind each interaction.

The Service Design Approach

I mapped how product work entered the organization, how decisions were made, when Design became involved, how information moved between teams, and where context was lost.

The new approach moved Design closer to the beginning of the service.

Instead of receiving a request for a completed solution, designers became involved when a demand first entered Product. They could help define the problem, identify affected users, select the appropriate research methods, shape the solution, review the implementation, and measure the results after release.

We created a flexible process based on the size, urgency, risk, and expected impact of each initiative. Not every project required the same amount of research or documentation.

Depending on the work, the process could include:

• Problem framing and initial discovery
• Stakeholder mapping
• User and stakeholder research
• Current-state journey mapping
• Process mapping and service blueprinting
• Co-design workshops
• Future-state journeys and user flows
• Prototyping
• Usability testing
• Accessibility review
• Delivery planning
• Measurement plans, analytics, and behaviour tracking

We documented this approach in a Product Design Playbook.

The playbook explained how the team worked, when each method should be used, which stakeholders should participate, and how the process should adapt to different types of work.

It also became an onboarding resource, helping new designers understand the team structure, responsibilities, standards, tools, and delivery expectations.

The New Design Operating Model

For each significant initiative, we defined accountable representatives from:

• Product
• Design
• Engineering
• Business
• Legal or Compliance, when required
• External stakeholders, such as clients or users, when relevant

Designers were no longer treated as subordinate to Product Owners within the workflow.

Product, Design, and Engineering became partners with different responsibilities. Designers were expected to present their own work, explain the evidence behind their decisions, and defend usability and accessibility needs.

External stakeholders could also participate throughout the process. In some projects, clients joined the initial conversations, reviewed early prototypes, participated in testing, and received access to completed features before publication so they could validate the experience.

Each epic was reviewed by the relevant functions. Its stories and tasks could include design, engineering, research, accessibility, content, compliance, testing, and final validation.

This created better alignment and traceability from the original problem through implementation and release.

Connected Workflows and Documentation

We introduced a dedicated Design Kanban in Azure DevOps and connected it with the existing Product, Business, and Engineering workflows.

The structure included:

• A Design Kanban for Product Designers
• Product Kanbans for Product Managers and Product Owners
• Separate Engineering Kanbans for different technical teams
• Higher-level Product and Business views for broader planning

These Kanbans communicated with each other so work could move between teams while preserving its context, ownership, and history.

We also introduced automations that assigned or transferred tasks based on workflow stages, responsibilities, and predefined rules.

Product requests included structured fields so designers received enough context before starting the work. We improved the naming and organization of epics, user stories, tasks, requirements, and acceptance criteria.

This made information easier to understand, search, measure, reuse, and automate. It also created a stronger foundation for future AI-assisted workflows.

The goal was not documentation for its own sake. We tested and adjusted the process as teams began using it.

For example, we initially tried to document too much design detail inside Azure DevOps. This created additional work without enough value, so detailed visual documentation remained in Figma while Azure DevOps contained the information required for planning, ownership, delivery, and traceability.

The operating model was treated like a product: it was tested, reviewed, and continuously improved.

Accessibility and Inclusion

Accessibility became part of the process rather than a final review.

Design requirements included accessibility expectations, and designers could explain why keyboard support, semantic structure, screen-reader compatibility, focus management, contrast, and other requirements were necessary.

Some developers initially questioned the value of these requirements. I addressed this through workshops, practical examples, closer collaboration, and clearer documentation.

Employees with disabilities, especially those working in Customer Support, were included in conversations about internal tools and operational workflows.

I also treated clear and consistent documentation as a form of organizational accessibility. Standard language and predictable task structures made information easier for everyone to understand and reduced dependence on individual writing styles.

Building Capability and Changing Culture

The transformation required more than creating a workflow. It required changing how the organization understood Design.

I presented the proposed structure, resource needs, priorities, Design System direction, and short-, medium-, and long-term goals to senior leaders and C-level stakeholders.

The short-term focus was solving immediate communication and delivery problems.

The medium-term focus included:

• Revisiting existing features
• Reducing design-related defects
• Improving usability and accessibility
• Introducing stronger research and measurement practices
• Expanding the Design team
• Adding UX Writing capability

The longer-term direction included:

• A scalable Design System
• Stronger governance
• Better use of automation
• More consistent international adoption
• Better preparation for AI-assisted workflows

The team grew from three Product Designers to approximately twelve people:

• 10 Product Designers
• 2 UX Writers

The UX Writers were introduced later to revisit existing features, improve terminology and content, and support medium-term product improvements.

I supported hiring, onboarding, mentoring, workload planning, identification of individual strengths, and the development of potential design leads.

Regular workshops created a space for designers to exchange knowledge. These sessions were also opened to developers and other stakeholders, helping Product Design practices spread beyond the Design team.

Creating the Design System Foundation

As the process became more structured, Engineering began to see clearer evidence behind design decisions and more opportunities to reuse components.

This created the foundation for a shared UI kit and later a formal Design System.

The team began consolidating:

• Shared components
• Interaction patterns
• Visual standards
• Accessibility requirements
• Data-field conventions
• Design tokens
• Documentation
• Design-to-code practices

We also introduced Storybook as a component playground.

Before this, designers could define component behaviour in Figma but would often see the real interaction only after development was completed.

Storybook allowed designers and engineers to review components earlier, test states and behaviours, discuss implementation details, and identify differences before the components were used across products.

This reduced uncertainty and created a stronger connection between the Figma libraries and the implemented components.

Challenges

The main challenge was not creating the process. It was maintaining adoption.

Product Managers and Product Owners had to change a familiar workflow and involve Design earlier. Designers also had to accept greater responsibility for presenting evidence, explaining decisions, and participating throughout delivery.

Engineering teams used different technologies and had different levels of support for accessibility, component reuse, and modern front-end standards.

The transformation required continuous facilitation, conflict resolution, clarification of responsibilities, workshops, and adjustments based on feedback.

Instead of treating the first workflow as final, we monitored its use and removed steps that created effort without enough value.

Outcomes

The transformation changed both how products were designed and how teams worked together.

What I Learned

The most important lesson was that a design process cannot simply be imposed.

It must fit the organization, the size and risk of the work, the delivery environment, and the people expected to use it.

A successful design function needs enough structure to create clarity, traceability, accessibility, and quality, but it must remain flexible enough to support fast delivery.

This transformation worked because the process itself was treated as a service that could be researched, mapped, prototyped, tested, measured, and continuously improved.