Iterating on a prototype with structured content in Sanity
Or, that time I danced in the office
Previously I wrote about using Trello to bootstrap a content model and then building a prototype in Sanity. Here’s what happened next:
We tested our concept with our target audience
To recap: we had already done a lot of the heavy lifting. We had:
- A model of how the content should be structured (initially in my head, but then formalised as a set of schema definitions in Sanity)
- A model of how the content should be presented (some sketches on a whiteboard, nothing fancy)
- A basic but functioning UI allowing users to navigate through real —though nowhere near finished—content (a React front end we figured out via a combination of our Sanity content model and those whiteboard sketches)
- The ability to modify content on the fly when it turned out to be unhelpfully phrased for our earlier test participants — so we could iterate on wording for those who came later (real-time editing in Sanity Studio, because the content saves in the cloud even if you just edit and publish locally👌).
We also had our test participants complete a card-sort on our content categories, because you want to know that your content is actually grouped the way real users think about it. (We used Optimal Sort, and it was very easy. Although beware of using the preview link as your actual link, or your sort results will not be saved. I know this now. I got properly kerfloofed by banner blindness, and overlooked the warning message.)
We got feedback
Boy, did we. Per my original post:
The investment of time was relatively small, for large potential gains. With a functioning prototype containing real content, you get user feedback on the content itself, the content model, and the presentation layer – long before anything real is put in production. This gives you a chance to iterate based on reality, at low cost.
Discussing our content, content model and front end with potential users taught us that:
- Our basic approach to the content model was broadly right, but needed some adjustment.
- We were going to have to improve the actual content in ways we maybe hadn’t thought about yet.
- The interaction and content design wasn’t right — though to be fair, we knew that going in 😁. But we got some ideas for how to fix it, based on observing what people didn’t understand.
- Users didn’t always have mental models of the terminology we used. I would usually be the first to argue for words that users understand. But these were technical terms that some users knew, and precision was important in this context. So instead, we decided to show users some teaser content on the front page, as a way of surfacing synonyms and “might be confused with”s, to help them choose the right way to go. And right there, we resolved one of our questions about what content to show at what point in the user journey.
- Most users were in broad agreement about how to group the different content 🎉
- The thing we were testing was in fact something that people would use. (One user even asked us when the service would be available! 👏)
Super-important: the client was with us for most of the testing. This is always important, but especially on a relatively small budget. We saved so much time and effort on documenting the results and negotiating changes to our existing model, because the client was there and could see for themselves.
So then what?
Originally I had thought that we would maybe make some recommendations based on testing, like a list of suggested improvements to the prototype, as part of our delivery (on top of the actual content). A guide to how the client could go further with the project after our delivery.
But … naaah.
We iterated.
We had a day together with Heidi, our content expert. We discussed what we’d learned from testing, and what we needed to change: the content model, the actual content, and the interaction design.
Then we had a day when I rewrote the content model in Sanity, collaborating with Tommy while he updated the front end in React. Our colleage Victoria joined us, and on literally her second day on the project, fixed our biggest interaction design conundrum. What a 🌟!
I also snuck in some changes to the way content was structured in Sanity, to facilitate the editorial workflow.
Two days. TWO! DAYS!
… is what it took to go from our uncertain first prototype with its speculative content model, to something that:
- has a content model that makes sense to users
- has a front end consistent with what we know users need
- has an editing workflow that makes sense
- lets us write and update content, publish it, and see it pop out on the web (in our prototype. This isn’t in production quite yet!)
- can be viewed and used by the client whenever
Imagine if we had just documented the usability testing and proposed changes for the client. We would still have needed that one day’s discussion, and then another day for documentation (a testing report, plus sketches for the content and interaction redesign). But we wouldn’t have had anything more to show for our efforts. For about the same amount of time, we got everything.
I’m blown away.
I thought we were going fast before. But when you have someone rejigging the content model, in conversation with someone else who is rewriting the front end, things just fly.
What we made, tested, and refined was just light years better — and faster — than using a dumb prototype composed of interlinked mockups with speculative content. I can’t even.
It’s difficult to imagine doing this any other way
In one iteration, I’ve gone from “would definitely do this again” to “why would you do anything else?” Work up a plausible content model, build a front-end based on what you know, and test it with real users. Adapt your content model and your front end based on your findings. Design content-first, use a simple, powerful tool like Sanity, and remember to fasten your seatbelt. ❤️
