Next
Last

Content Modelling with Lego and Plasticine

 


Transcript:

We need to stop thinking about content as a blob and think about it more like Lego.

This is a standard blob. It's a webpage from a government website, which I've kind of grayed out, but what you can see is that you've got a sidebar nav down here, top level nav across here, sidebar nav here. That's all structured, and defined and everything, but this is just a blob. It's a big long text that extends way below the screen capture that we've got here.

The problem with that is that's it really inconsistent. If a user comes and looks at this particular session, this bit is going to be structured very differently here versus over here.

Often, information architecture—at least as it's done in an old school kind of way—sort of cuts out at a certain point. It'll get to a level of defining a site map. Maybe it might put some specifications around what a page needs to have on it. It doesn't really go into much more detail than that.

What you end up with is this. This is my beautifully crafted clay model of a house. It's got a bit of a window and a nice sun painting on the wall, but this is old school information architecture. It's just defined ‘house’, and kind of stopped there. The problem with that is if we wanted to do anything with the house, or the window, or the sun, we can't really. We'd pull it apart, and it just loses structure, and our hands get really messy. Then, we've got to clean modeling clay out of our fingernails, and it's just really painful.

What we want instead is something like this, which is the far more hi-fi and well structured design for a house. You've got the window, and you've got the sun painting, and you've got the roof, but they're actual discrete elements. The reason this is really cool is that we can actually take it apart and do different things with the elements. Just pull out the window.

We might decide on a website we'd want, you know, a full version of everything. Maybe on the mobile site, you want to display content that's a little bit leaner. You might want to create an entirely new content type that maybe just uses the window element, and mixes it up with a whole bunch of other stuff.

This is useful in two scenarios: One, if we're designing for cross-channel experiences, having the elements all defined means you can do stuff in a CMS. That means that basically you don't have to retype stuff or manually re-enter things. It does all of this for you. Two, it also means that we can actually put more parameters around the content type. We can say, if we're doing a house, then it's going to have a roof that's going to be white, it's going to have a window which is going to have this little flappy bit, and blue, and whatnot. We can create those rules, and we can actually give them to business areas who are writing the content.

This means that we as UX professionals can actually be more useful further along into the production process, and also means that we can do more to make sure that the customer experience is actually more consistent.

If you'd like to know more about this discipline, which is ‘content modeling’, there's a post that I did for UX Mastery which you can read at your leisure. Hit me up if you've got any questions about this stuff. Resources to read, approaches, all that stuff. Otherwise, have a very merry UXmas.

See ya!

Matt Fenwick

Matt Fenwick

Matt Fenwick is a content strategist and founder of True North Content. He works on big, messy content projects for government departments in between juggling tiny humans.

comments powered by Disqus