I joined the team as the sole designer when the product had two core problems: store coworkers weren't engaging with it, and stakeholders were pushing for ambitious bets without the foundation to support them. My job was to make the situation legible, set strategic direction, and sequence the work.
Vetlanda is IKEA's internal B2B tool for store coworkers to submit proven improvements that optimise franchise-store work processes, drive measurable KPIs, and reduce friction in employee workflows.
The user problem statement
Store employees weren't engaging with the tool. It was at bottom of an already overloaded workday, perceived as another compliance task given by management.
There was no time in the workday to use it, no sense of ownership over the outcomes it produced, and a complex interaction model that made even simple actions feel like work. The result was a product employees tolerated rather than relied on.
The business problem statement
The tool was operating with significant structural debt. Core parts of the workflow still lived in Excel, the UI didn't match IKEA's design system, and the team was mid-way through a backend platform migration that constrained what could ship and when.
At the same time, stakeholders were pushing for ambitious bets without the user data or product foundation needed to make those investments pay off.
My role
I joined a team where stakeholders were asking for AI, gamification, and personalisation on top of a tool with 24 weekly active use and no reliable data on what was working.
My first strategic act was pushing for discovery bi-weekly working sessions with stakeholders, despite the pressure for a visible launch within the quarter. I believed Vetlanda didn’t have an innovation gap but had a foundation gap. Any AI or gamification bet made on the current data would underperform, because the platform wasn't doing its' primary job - helping co-workers find and use the right improvements.
I got alignment by showing the current length of the validation process, the cost and resource implications of the backend migration and design system integration. Based on these insights, I developed hypotheses to improve the underlying operational foundation, particularly the internal validation workflow, and secured commitment to reduce validation cycle time over the following two quarters.
From there I set the design strategy: separate the user problem from the business problem so each could be solved on its own terms, establish the design principles the team would use to evaluate trade-offs, and shape a roadmap that addressed structural debt and design-system coherence before chasing adoption features.
The trade-off I consciously accepted was a quarter without a launchable feature for store coworkers, along with the postponement of AI and gamification initiatives.
In return, we used that time to establish a product roadmap to reduce the likelihood of recurring strategic misalignment and short-term prioritisation conflicts in the future.
End users of the product
Department leads in stores across the world
IKEA stores and franchisees operate across nearly every continent, with more than 50 stores worldwide. Within each store, department leads in varios sections are the primary users. Each store works in a different cultural and operational context, which meant every design decision had to hold up across language, role, and regional store rhythm.
CORE FLOWS OF the PRODUCT
The trade-off: fix the foundation before chasing adoption
A deliberate trade-off: fixing the foundation before chasing adoption
Through discovery workshops with the team and the internal validators responsible for quality-checking improvements, I led the team to a deliberate sequencing call: redesign the internal validation flow first, before touching the more visible coworker adoption problem.
The logic: without a reliable supply of high-quality improvements, there would be nothing worth giving to coworkers and no credible way to tie KPIs to outcomes.
The cost: we deprioritised the coworker-facing redesign for roughly a year. The visible adoption problem was what stakeholders wanted us solving, and choosing the behind-the-scenes problem meant accepting that our progress would be illegible to leadership for two quarters. I made the call because in order to later measure the succes of KPIs, we needed a good collection of high-quality improvements in the pipeline.
From a fragmented Excel sheet to an integrated in-product workflow
Every improvement submitted by a store coworker passes through three roles: Editors (language and coordination), Best Practice Leads (process and business outcomes), and Subject Matter Experts (domain expertise). All three were logging feedback in a single shared Excel sheet that had become unmanageable.
I ran user interviews and shadowing sessions with all three roles using the existing Excel process, surfacing five pain points per group. I then facilitated a workshop with the full team to align on findings, surface technical constraints, and agree on a path forward.
I used an effort/impact matrix to prioritise, but the more important move was naming what we were not going to do.
Adopting a third-party solution for the validation process initially appeared to be a quick win, but it introduced long-term risks around platform consistency and scalability, especially given the planned investments in AI and gamification capabilities.
Since we were already operating within a unified backend ecosystem, I believed it was strategically more sustainable to strengthen the existing platform rather than fragment the experience across external tools. This approach also enabled us to consolidate behavioural and role-based data into a single source of truth, improving both consistency and future product capabilities.
Results of first iterations
Validation time was reduced by 38.4% (6.5 working days), measured against all submissions that were evaluated across the previous two tertials.
The end-to-end process, from product discovery through implementation, took approximately seven months.
While validation time dropped significantly, the research surfaced the remaining bottleneck: communication between editors and submitters, upstream of the validation flow itself. We addressed it by enabling submission assignment and introducing a centralised logbook overview.
A key improvement to the flow was:
‣ Enabling submission validation, ‣ Establishing a logbook overview.
The hidden problem: 70% of submissions were being returned
Data showed that 70% of submitted improvements were returned to the submitter, with most responses taking over a week. The most common reasons for this were incomplete form fields and a lack of clarity about what the form was asking for.
I scoped the next research round around the two highest-leverage steps: the submission form and the first stage of validation, and led scenario-based usability sessions with store coworkers, observing where the flow lost them. The findings gave the team a basis for improvements.
That research surfaced a high-leverage problem that wasn't predicted: the Help Centre lacked useful information, which forced editors to do explanation work that should have happened before submitting a submission.
I noticed it because coworkers in the usability sessions explicitly searched the Help centre, found nothing useful, then submitted incomplete forms. The fix had near-zero implementation cost and a clear path to reducing validation time, so I reprioritised the next sprint around it — deferring the feature change in the submission form that the team had already started scoping. I made the call and explained the decision to leadership. We redesigned the Help centre around a structured sidebar and post-use feedback prompts, which opened a continuous feedback loop with users.
Outcome: a year of shipping features
In one year, we achieved a 181% YoY increase in high-quality submissions, showing a big improvement in speed of the process and adoption compared to the year before.
A redesigned Help centre lowered the time editors needed to revise submissions, a restructured submission flow raised quality, and a streamlined validation process across four roles cut 9.4 working days from cycle time.
Combined with targeted marketing across the store network, the compounding effect produced the 181%.
AI as a copilot — the roadmap bet I shaped, not the feature I shipped
With the foundation in place: a cleaner submission flow, a streamlined validation process, and high-quality submissions coming into the pipeline, I made the case for AI as the next phase of the roadmap, and got it places for the next two tertials.
This is roadmap influence and not shipped work. I'm including it because the strategic move: refusing immediate AI features when it was the loudest stakeholder ask in year one, then advocating for it once the data foundation existed - is the move I most want to be evaluated on. The pain point is concrete: today, coworkers write up their improvement in a PDF, then copy-paste fragments into the submission form. The form is the friction. The proposed copilot does the mechanical work for the user:
‣ Extracts the relevant information directly from uploaded PDFs ‣ Validates KPIs against completeness and quality criteria ‣ Flags gaps and missing fields before submission ‣ Guides users toward the KPI sets the validation process has historically rewarded
‣ Extracts relevant data from the document and organises it into the correct form fields; ‣ Evaluates content for accuracy and consistency, ‣ Suggests writing improvements or clarifications where needed to enhance quality and readability.
Design principle: frictionless entry, intelligent guidance. Strategic logic: the year of validated, high-quality submissions we built up becomes the reference data the AI learns from. That's the move - and it's why I held the line on foundation work in year one.
Implement flow - adoption plan
Submission was no longer the bottleneck. Adoption was.
With high-quality improvements secured, the next priority was to make them easy to adopt and beneficial for employees: turning Vetlanda into a primary tool for shared learning and a lever for business profit.
With high-quality improvements secured, the next priority is to drive impact by making them easy to adopt and beneficial for employees: turning Vetlanda into a primary tool for shared learning and raising business profit.
We ran in-person and remote user testing with stores that had used Vetlanda at least three times. The insight was simple but decisive:
In 84% of the time, store employees want to find ways to improve store performance only within their particular department.
That insight reshaped the experience around personalisation rather than discovery. Three moves: ‣ Onboarding flow for selecting preferred review topics. Surfacing the most relevant improvements based on both search queries and the user's departmental expertise. ‣ User profile. Email notifications, KPI tracking, and review topics. I designed this as more than a personalisation surface: it's the data that the next three features (bookmarking, store groups, store-level KPI calculation) all depend on. I chose to build the core primitive once, even though only one feature needed it initially, so that the next three features wouldn’t require re-onboarding or rework. ‣ Improved search function. Multi-language support, ranked by whether the term appeared in title, subtitle, or body.
The onboarding flow became the turning point in collecting structured information about coworker preferences at scale.
Implement flow - adoption plan
To support wider adoption, we introduced lightweight ways to track how improvements are implemented across stores. By adding a simple prompt "Have you implemented a Good Example?" on the improvement page, we began capturing who implemented each improvement and how often, without increasing user effort.
The trade-off was visible. A partially manual flow looked unfinished compared to a fully automated one, but a fully automated flow would have either delayed shipping by few months or generated meaningless numbers in the interim. I optimised for early signal, not for surface polish, and named that choice explicitly in the rollout review.
I designed this MVP end-to-end as the sole designer. The interesting constraint: KPI evaluation depends on several months of observational data, so the flow couldn't deliver "real" impact numbers for at least two months. I built around that constraint rather than against it, incorporating email-based coordination with coworkers so the process could function and generate early signal while the longer-term data baseline took shape.
By storing feedback on KPI implementations from other stores, we established the data foundation for measuring real business impact — and the substrate for the AI-driven KPI calculation work sequenced for the next phase.
Making impact visible at scale increased confidence and adoption, contributing to a 27% rise in average implementations across the store network in 7 months.
What I'd do differently
I'd push harder for design-system compliance earlier
Stakeholder pressure made the short-term call clear — ship the business priorities — but every component we built outside the system became engineering debt we paid for later. Aligning to the system isn't a cosmetic concern, it's a compounding efficiency lever. I accepted "we'll align it later" too easily in the discovery phase; the cost showed up six months later in implementation of the validation process.
I'd run a dedicated stakeholder discovery in month one.
I diagnosed the user and product problem quickly, but I underestimated how much of my year-one capacity would go to managing the gap between stakeholder expectations and what foundation work could visibly deliver. Treating stakeholder alignment as its own discovery stream — not a side effect of design work — would have bought me more time later to start with introducing AI.
I learned that co-creating a roadmap is itself a design problem.
Organising work into epics and stories in Jira, sequencing what gets visible vs. structural priority, and giving stakeholders a way to see progress on invisible work — these are as interface design problems as much as project management Treating them this way is what made the foundation-first approach work.
But the case study is only part of the picture...
What I've shared here is the product of the work. There were even more decisions taken, more disagreements I had to resolve, the things I chose to deprioritise that shaped the outcome just as much. If that's the conversation you're interested in, get in touch.
