Dream a schema:
making content mistake-proof

Summary

When I’m reading documentation for internal systems, I need to know that I can rely on the information I’m given. Our existing support content is structured, but it’s not immune to human error, and is sometimes not expressed optimally.

In this blog I’ll explore the subject of optimising imagery for the website. The Content Design team holds the information that the web editor community needs to perform its tasks, and it’s important to know the best ways of presenting it.

Choosing an approach

In the past, our support content for optimising imagery has been rendered using headings, paragraphs, and bullet points (our bread and butter). This method is descriptive, and it’s structured, but it’s hard to apply consistency, and can leave a lot of room for interpretation.

A table would be an improvement, but they introduce their own problems:

• Large tables are harder for users to query
• Tables require more effort to build and maintain
• There’s no enforcement rules, so it’s possible to conflate values
• It’s possible to create contradictions (an image described as “portrait” when the numbers say it’s “landscape”).

So, while a table can offer structured content, it’s still not the right tool for the job.

In this case, this information is best arranged as a data set, and for that, we need a schema. More on that later.

Everyday tasks and job stories

The guidance for optimising imagery is for university staff, specifically web editors.  So rather than identifying a user need, I’ve framed it as a job story:

“When I need to add an image to a webpage,
I want to reliable guidance on image dimensions,
so I can publish content to an appropriate standard”.

That’s the editor’s job in a sentence, and it’s validated by real-life support requests.

If our guidance isn’t reliable, or if it’s open to misinterpretation, then we risk publishing sub-optimal imagery/content, and leaving web editors stranded.

User needs

By contrast, a user need doesn’t offer the same level of situational detail:

“As a web editor, I need guidance on image usage, so I can publish pages correctly”.

This is OK, but it’s missing the when, the what, and the why.

What do users need to know about images?

There are some foundational truths when describing the essence of an image:

• They’re two-dimensional.
• They’re expressed as width and height (X and Y).

By international convention (including ISO and W3C standards), image dimensions are always notated as width × height. Keeping that order consistent avoids confusion between landscape and portrait formats.

It reminds me of drawing graphs in maths at school, and labelling the axes…

All you need to know is the width and height of an image, and the rest follows.

When you know the width and height, you can calculate other useful information from there: aspect ratio, orientation, resolution… This is all useful to a web editor when tasked with adding an image to a web page.

Advanced metadata

If you’ve ever looked at an image’s file properties in Windows, you’ll know images carry an extensive amount of metadata. From width and height; to the camera model; the GPS location where the picture was taken…

This is all useful if you’re a photographer, or involved with digital asset management, but a lot of this is redundant for content editors who just need to get an image on to a page.

Designing a schema

A schema is a structured way of saying:

• These are the fields,
• This is the type of information they hold,
• This is how they relate to each other.

I could use a schema to explain how to optimise imagery with sub-headings, paragraphs, and bullet lists.

I could also use a schema to explain it with a table.

But since this is for web editors, I’ve chosen to build a simple SharePoint list and manage entries as records. That way, I can use metadata to add an extra dimension, and make the information sortable, consistent, and easier to apply.

Mistake proofing

When standardising information within a SharePoint list library (database) I like to think of the principle of poka-yoke, or “mistake-proofing”.

Poka-yoke is a manufacturing concept, and it literally translates to “avoid inadvertent errors”. It’s about designing processes so that human error is prevented or immediately detected. A classic example is a three-pin plug: it can only fit into the socket one way, so you can’t insert it incorrectly.

For me, this principle transfers naturally into content design. Whenever users are asked to read, understand, or complete a task (filling in a form, data entry) there’s always a risk of error. If we remove the possibility of error in the first place, the process becomes more reliable and the output more consistent. It’s why I prefer calculated fields over manual entry, and clear constraints on what can and can’t be added.

Consumers of this support content (editors, visitors, colleagues) should have less chance of getting things wrong.

This is the schema I made for this exercise:

Using the Orientation column as an example, instead of asking someone to manually choose “portrait”, “landscape” or “square”, SharePoint calculates it from the specified width and height.

That’s mistake-proofing. It’s not possible to declare a 1200×800 image as “portrait”.

Building the list library

We have a working schema, now it’s time to use it to make some content.

After starting up a new list library in SharePoint, and building the columns, it was a case of filling in each field by allocating the data to its respective field. In short, data entry 😂

The result is a complete and consistent dataset, with a wide scope for expansion.

Conclusions

This hasn’t been a 100% automated solution, but it’s a solid re-iteration of our existing support content, rooted in fundamentals that apply to many other content design challenges.

The important part is that our editors now have clearer guardrails, and fewer chances to get things wrong. It’s now possible to quickly reference specific image use cases without the need to scan through sub-headings, or resort to the almighty Ctrl+F.

Why not calculate the aspect ratio?

You might be asking why I’ve not extended the calculation to the aspect ratio field… Without delving further into managed metadata, lookup columns, term store updates, Power Automate, or numerous helper columns, there’s no native calculation that will achieve this.

The straightforward approach is to use a simple aspect ratio calculator to convert image resolutions. Some of the optimal image sizes are oddly specific (a lead-in image being 166:55 = 996×330 px), so any new records will need some manual input.

When optimising an image during the editing process, web editors have to know how to set the proper aspect ratio crop (or resize) in Photoshop.

Why format matters as much as content

Don’t just think about the information you need to convey; think about the form it takes. The right format is just as important as the right content.

By opting for the right tools, and understanding how to apply rules and standards, we can support users, minimise errors, and make support content usable at scale.

To me, this is what content design is about.