Education technology
EduSetu Tech
A product site aimed at school leadership, where the buyer is an administrator between two other jobs.
- Type
- Education technology
- Scope
- Product site, design and build
- Audience
- School leadership and administrators
- Engagement
- Fixed scope
The brief
Principals evaluate software in the gaps between other duties. The site had to answer what it does, who it is for and what happens next, without technical vocabulary in the way.
Our approach
Pages ordered by the questions buyers actually ask, one enquiry path per screen, and a mobile-first build — most first visits arrive on a phone, on a connection we should not assume much about.
Decisions
The choices that shaped the result
A case study is only useful if it says why. Each of these was a live argument at the time, with a reasonable alternative on the other side.
Order the pages by the buyer's questions, not by our capabilities
The instinct on a product site is to lead with features. A principal evaluating software between two other duties is not asking what it does first — they are asking whether it is for a school like theirs, and what happens if they enquire. So the structure follows that sequence, and the feature detail sits after the qualification, where it is genuinely useful rather than merely present.
Remove the technical vocabulary entirely
The original copy described the platform in the language the team uses internally. That language is precise and it is also a barrier for a reader whose job is running a school. We rewrote against a plain-language rule: if a term needs a sentence of explanation, it is the wrong term for this audience.
One enquiry path per screen
Multiple competing calls to action on a page reliably reduce the number of people who take any of them. Each screen was given a single next step appropriate to how far the reader had got, rather than repeating the same form everywhere.
Mobile-first for real, not as a breakpoint
Most first visits arrive on a phone on a connection we should not assume much about, so the phone layout was designed first and the desktop layout derived from it. Page weight was treated as a budget rather than a post-launch audit, since the visitor who abandons a slow page is not counted anywhere.
What they were left with
A site the team can send to a school unaccompanied, with responsive layout, page weight and crawlable markup handled rather than deferred.
What we would do differently
The content structure took longer to settle than the build did, and that was the correct distribution of effort — but we could have reached it faster by writing the page outline before any design work rather than alongside it.
Visit EduSetu TechAnother engagement
Have a brief of your own?
Send us the problem rather than a feature list. Both engagements above started that way.