Why is our website so bad?
And what happened when we stopped making excuses for it
I work for The Prince’s Trust. Prince Charles set up the charity over 40 years ago. I could tell you more, but all you need to know is this: our website is bad. Really bad. It doesn’t fit our users’ needs. It doesn’t fit our business needs. And despite my best efforts, the organisation still views it as a melange of purposeless pages:
“Everyone else has a website. Not sure what we’re doing with it, but I suppose we better have one too…”
A sorry state of affairs. How did we get here?
Excuses
A (paraphrased) straw poll of my colleagues:
“The CMS is too restrictive.”
“We’re just a charity — if we had more money, we’d be up there with Google…”
“I think our website is actually alright, all things considered…”
The list goes on. Sure, some of these points have a semblance of truth, but they’re ultimately excuses.
The root of our less-than-perfect website is the organisation’s wilful refusal to invest in sustainable processes. We bought a new website 5-ish years ago, set up incredibly siloed teams and expected it to run on little strategy or collaboration.
At the start of the year, my department took a collective breath following a restructure. A group of us used this as an opportunity to improve the website and prototype a “new” (for the organisation) way of managing this melange of purposeless pages.
For 3 months we chiselled away and increased conversion by 22%.
How we did it…
Who were we?
A marketing manager to write and review copy, a UX designer to redesign the pages, a product manager (me) to crunch the numbers and A/B test, and a director to drive the initiative forward with senior stakeholders.
We were in separate departments and all had other projects going on. Resource was limited. We had to wear multiple hats. I was coding when I shouldn’t have been. Holidays slowed progress. Website maintenance impacted our results. But we made it work.
The goal
Our goal was simple: increase conversion by reviewing key journeys and making the website easier to navigate.
We already had analytic funnels set up from years ago — implying that the website actually had some goals all along. Wayward design and content decisions in the past meant that our key journeys were lost in the noise.
The first step was to analyse which journeys were ripe for improvement and then produce a roadmap of pages to review. I’ll explore this process in a later post.
Scrum!
The roadmap allowed us to establish a plan of work that fitted nicely into weekly sprints. Scrum rituals were loosely adopted alongside a sense of pragmatism. This was about delivering results — not rigorously following the scrum framework for the sake of looking cool.
What we learned
The power of a shared goal
Despite having to juggle different projects, team members bought into the work because we shared a clear goal. Rather than blithely saying “we’re currently on track to increase conversions by x%”, I framed reporting in a way that was tangible to the team: We’re currently adding 5 extra sign-ups per day… we’re currently adding 6 extra sign-ups per day…
This kept everyone motivated and preserved momentum even when work had to be paused for other projects.
It is better to make a coherent bet, everyone in the same direction, and be wrong (because then you can change course quickly) than to delay or waffle (because you learn nothing and get a suboptimal return at every step of the way).
Geoffrey Moore, Crossing the Chasm
4 weeks into the work, we conducted a roadmap review as a team. I had produced the initial plan myself, but the review allowed us to input observations from early rounds of work and encouraged further buy-in.
Product manager shouldn’t be dictators after all!
We could still do better by…
Surfacing secondary goals to supplement the overall conversion target. The overall conversion goal was still kept as a the main KPI for these pages even when our design decisions were (rightly) not about driving users directly to sign-up.
An imperfect process is still better than no process
We knew it wasn’t going to perfect, but we aimed to keep improving — and not look for excuses to carry on doing the same thing. Adopting a pseudo-scrum model allowed us to build a working rhythm and control the pace of work — which was vital to maintain quality when other projects got in the way. A retro at the end of the project allowed us to reflect on ways to improve the process.
We could still do better by…
Holding more regular retros. As people were often pulled away from end-of-sprint meetings, we settled for one final retro to review all our work. Striking a middle ground by having a retro every couple of sprints would increase productivity whilst allowing us to keep to our other commitments.
Documenting pays dividends
Work was documented in a “gospel” that recorded problem statements, links to deliverables and other notes. The document had a clear structure and when the team or external stakeholders had questions, more-often-than-not they could find the answers there.
We could still do better by…
Using the sprint board as a project space instead of sending resources via email. Emails make things messy and also made it more difficult to document decisions and keep track of work.
Closing thoughts
This tranche of work has ended as other projects kick into gear. We increased conversions, but I also hope we broke down some stubborn silos and demonstrated the value of working in a different way. For modern organisations, this is common sense. For those stuck in the past, it can feel uncomfortable and even disorientating. But doing the same thing over and over again only brings the illusion of stability. Whilst you bury your head in the comfortable, stable sand, the rest of the world moves on. Before long, you’re stranded — and there’s nothing more uncomfortable than that.
This blog is part of a series. Next time… how we combined data and qualitative feedback to inform our decisions.
