My first six months of UX in an enterprise — from sailboat to ocean liner

Dean Wilson
John Lewis Design
Published in
3 min readJul 9, 2024

I came to John Lewis having never worked in a big company. In 10 years of doing this UX gig, I’ve only ever worked with small teams, and always a UX team of one.

A picture of the author presenting designs to an audience
Flying solo

Here, at what I’m told is the 4th largest e-commerce site in the UK, everything is big. The legacy, the user base, the number of teams, the range of skills… all big.

And I’m here for big. I came here to work with other UX and UI designers in an industry I’ve never touched, working on a scale that scares me a little.

It’s been overwhelming. Here’s three things I learned that helped me find my feet.

Lesson #1: Don’t try to know everything that’s going on

It took me three months just to understand the difference between being knowing what is going on across teams, and being aware of what is going on.

In a place this size, you can’t afford to know everything. In a small business or organisation you might manage it, but it’s not feasible here. Awareness however, is super valuable. Workshops, demonstrations, showcases and update sessions will allow you to connect the dots between what you’re doing and the work others are doing, revealing where your designs and plans will be affected or impacted by what’s happening in that space over there.

Staying aware also keeps your perspective in check that you’re all working towards the same goal, something easily lost with team-specific OKRs.

Lesson #2: Get used to needing people

It may seem a touch banal (and perhaps even bleeding obvious), but what I’ve learned is that a bigger organisation brings with it an even greater reliance on other people. You ignore those team structure charts at your peril, because it’s not enough to have a good idea attached to a valuable opportunity in your crosshairs. You need to know who can help you establish the value of your designs, who will be impacted by your designs, who can help your experiment along, and who can help you implement your work.

Then you need to talk to said people. This means having a sharp rhetoric (often in unison with a persuasive slide deck) and getting savvy on their context. What are they doing, what are their OKRs, what’s in their interest? Why is your work worthy of their resource?

I realise now that this kind of pitching and negotiating between teams is a requirement within an enterprise environment. Fortunately I’m surrounded by some of the kindest, brightest people I’ve ever had the pleasure of working with. You know how they say never be the smartest person in the room? Well that’s not a problem for me here. What’s more, 99% of people leave their egos at the door and will pull out all of the stops to help get the work done to a high quality. That’s a rare thing in my experience.

Lesson #3: Size does matter, and it changes the playing field

In my previous roles I would work with developers and product owners to create entire apps and websites, end-to-end. At John Lewis, there are entire teams focussed on a single function or a single page type, like my team who look after promotions for instance. At first it didn’t make sense to me. “It’s a retail shopping service”, I thought. “How complicated can it be to justify these individual teams?” I found the answer to that question in my first month, after meeting with a Solutions Architect to discuss promotion code problems. When he explained to me the technical complexities of the legacy system we’re building on, it was like a magician performing a card trick to a spaniel.

I then learned of other challenges, like the regulations we must meet across channels, the cost of change, the diverse needs of a massive audience, and the large scale data considerations, among others. We have many teams covering many areas because — while the focus area of each team is narrow — those areas run very, very deep.

For these reasons, if someone talks about getting a quick win or grabbing some low hanging fruit, tongue is quite firmly in cheek. So yes, implementation is slow, but the work certainly isn’t. And when designs are built and shipped, even small changes can have a big impact.

--

--