Learning to keep up with rapid prototyping — the ‘Sketchy Content Model’

Rapid prototyping

Testing a new approach of working is always a great experience. You learn lots of new things and, if you are lucky and you work on two projects that are taking a similar approach, you can test your assumptions simultaneously with both teams.

White October has experience of this from when we successfully implemented design in sprint into our standard process. You can read more about design in sprint in this blog post.

Rapid prototyping, however required an entirely different approach to design and development. For those unfamiliar with rapid prototyping, a rapid prototype is a lightweight first version of the product that can be tested with real users to gain more confidence in the product before the full build. So essentially it is a faster and lighter version of MVP (minimal viable product).

Issue and our approach

Not everyone has had experience with this kind of approach, so I knew it will be challenging for everybody, not just for design. The most relevant question for me was how to produce high quality UX fast enough to ensure I wasn’t the cause of any blocks for the rest of the team.

A question around content models had been raised during a previous userflow review, and we know how useful the content model approach can be, however this needed a markedly different approach; something that can be done fairly easily and would be clearly understandable by all the members of our project team, including the product owner.

“Sketchy Content Model”

Initial tests on a few pages worked perfectly! So what is it? The Sketchy Content Model is ultimately a simple page sketch, of a final layout version, reviewed by the team and signed off by the product owner. Once this has been approved, we are able to quickly turn it into a content model by defining all components on the relevant page and breaking those components down into more details. To make it easier to understand here is a specific example:

One of our common components was labeled as a hero area. Fairly obvious. This component contains various details and is related to a specific set of pages only, in our case it is pack hero area. Details included in this component are:

• Background image
• Pack title
• Pack location
• Pack subtitle

The nice thing about this approach is that you don’t need to spend massive amount of time labeling things right. This is because the team, which consists of designer, backend developer and frontend developer, could quickly go through the sketch, clarify any outstanding questions and make sure the labels are consistent throughout the whole system. This saved plenty of time and ensured we were all on the same page.

Don’t take my word for it! Here is what the rest of the team have to say about the approach:

I’m a backend developer, so when I’m creating a page of an app, my main question is “where is this data coming from and how is to calculated?” The content model sketches are fantastic for me: They show me the overall layout of a page at a glance and — crucially for my role — where all the bits of information are coming from. For example, what’s hardcoded, what’s coming from a particular field on a model, what’s a calulation and so. I find them something I can work from very easily, building up the skeleton of a page and ensuring it has all the data it needs, ready for a frontend developer to actually make it visually appealing!

Sam, Backend developer at White October

Content model sketches are incredibly useful because we can see the entire page at a glance, which lets us know not only which components we’ll need to add, but also how they’re likely to interact. This speeds up development since we can quickly identify any components that we haven’t yet built, as well as any changes that might need making to components that we’ve already got in “the library”. One of the best things is also that it helps with team cohesion — I know what our designer intends for that entire page, as well as how our back-end dev is going to build the page’s skeleton. That means I can style up the required design more quickly, and build a more robust, responsive page with just the features it needs. We’re all literally on the same page!

Gareth, Frontend developer at White October

How it helped our process and project

The obvious benefits of taking this approach, and presenting content models in this way are speed (for designers and developers), very easy to create and visually accessible for everyone to read.

As a designer, I’ve also learned way more about how the back end works for this kind of project than using the traditional way of creating a spreadsheet-based content model. Taking this approach means that every single time I create new page, we sit down as a team review it which means I am able to produce the necessary design elements of the approaching sprint in advance. For the project team, this makes it easier to plan the next sprint even if I’m not around.

Always knowing what was happening with the development was massively valuable for me as I had another project running in parallel, that is taking the same approach, knowing that I won’t need to spend lots of time trying to get up to speed made context switching between projects a swifter experience…

What is your experience with content models? Did you find your best way how to create a content model?