Aimee Learn page
Live
·
Web, not conversation
·
SEO & iteration ongoing
Showcasing what Aimee does
Everything else in this case study happens once a customer is already in a conversation. This one is the opposite problem: Aimee is effectively invisible until you’re talking to it, which makes it hard to know what it can actually do for you, or whether it’s worth starting.
The brief was a web page rather than a journey. Somewhere to shed a bit of light on Aimee, show what’s possible, and give new customers a reason to try it. The tension is that a page explaining capability wants to list everything, and a page that lists everything is one nobody finishes reading.
ee.co.uk/aimee
Desktop · full capability page
Mobile
Making the page effective on both desktop and mobile was important, i needed to make sure there were components that paried well with both view models
View the live page ↗
A design system built for conversation
Loop, our design system, is built for the app & the assistant: components that assume a message thread, a turn structure, a narrow column. However, our website doesn't use the same design system so learning the new system was a whole task in itself.
That meant learning a new set of constraints from scratch: how EE web pages are actually built, which web patterns customers already expect, and where the design system could stretch to cover a surface it was never designed for versus where it needed something new. Genuinely unfamiliar ground, and probably the most I’ve learned on a single piece here.
01
Treat a low bar as an opportunity
Competitor analysis turned up something useful: equivalent pages across the market were basic, and none of them showed much design ambition. This gave me the opportunity to create something that stood out, so thats what I aimed to do.
02
Hierarchy over completeness
The hardest discipline on a capability page is leaving things out. I built the page around a clear content hierarchy so it stays focused and readable rather than becoming an exhaustive feature list nobody scrolls to the end of. Taking it through design crits regularly was what sharpened this most, several rounds of feedback from the wider team pushed the structure, visuals and flow well past where I’d have gotten to on my own.
03
Hold the line after handoff
When the build came back it didn’t meet the visual standard the design set. I wasn't satisified with this and rasied it. I walked through the specific gaps rather than describing it vaguely as “off,” and made the case for fixing them. That produced multiple rounds of quality updates, and opened up ongoing work on more complex changes the developers had considered finished. Design quality isn’t decided at handoff; it’s decided by what you’re willing to go back and argue for.
The page is live and still progressing, the version in the frames above has already been overtaken by content and SEO work since. It’s a page that keeps earning its place rather than one that shipped and stopped.
Next is making it something you can interact with rather than only read: a test chat window so people can try Aimee directly on the page, and video to show the assistant working rather than describing it.
Get in touch
© Harry Thorpe · 2026
DesignED with FRAMER