information architecture

Content Objects: My Formula for Information Architecture

When you’re designing a new feature, app, or site, the information architecture can seem overwhelming. This is my technique for structuring anything you want to design, from scratch. I call it:

Content Objects.

 

Content Objects are a fairly easy concept, but they can be a little abstract sometimes.

It might sound technical, but there is no code involved… it’s just a technique that helps me simplify complicated designs in my head.

Like card counting, for UX.

After you have decided what your goals are, break down your general plan into the “building blocks” of content that you need.

If this were a Lego® Church of Christ or Kennedy Space Center — and it’s not, because our job will never be that awesome — you’d be making the first page of instructions that shows you the pieces you will need.

We’re not talking about pages or buttons here, baby… I’m talking about conceptual “things” that can be created, shared, edited, and so on.

****

Let’s look at an example:

Imagine you have been told to redesign Twitter. Big task? Not really. Just deconstruct it into Content Objects:

Twitter has registered users. 

Users make Tweets.

Users can be saved in Lists.

So Users, Tweets, and Lists are the Content Objects.

And that’s pretty much it. Three! Twitter, fundamentally, is built on three Content Objects for typical users. And lists aren’t even a core function (you can use Twitter just fine without them), so it’s actually only two if you just want basic features.

****

Another example:

An online store. Let’s say it's your store, and you don’t save user data when they buy, and you only sell your own products. You might only have one Content Object: the products!

****

Ok, one more example:

Pinterest. A super-popular site with tons of content. But it is really simple from the point of view of Content Objects.

Registered users.

Boards.

Pins.

Comments.

****

ProTip: Every time you add a Content Object, you significantly increase the complexity of your design, so keep it very, very simple.

****

Now at this stage, you might be thinking “Joel, this is stupid. Those sites can do way more than that!” You’re absolutely right, and I am glad we’re on a first-name basis. But I haven’t explained the second half of this technique, so hold your horses, muchacho.

****

Relationships, Types & Actions:

You should have very few Content Objects when you’re done. You need as many as you need, but if you have more than 3 or 4, your idea is getting complicated. Facebook only has about 6 or 7 Content Objects for normal users and Pages, just to give you a reference.

Once you have your Objects, you need to look at how they are related to each other.

Relationships create Types: Look at every combination of the Content Objects on your list and ask yourself what relationships could or should exist between individual Objects (a group of Content Objects is often a Content Object of its own).

For example, what relationship can a User have with another User on Twitter? They can follow. They can be followed. And that’s basically it. So there are three types of users: 1) people who follow a user, 2) people the user follows, and 3) everybody else.

A User and a Tweet is a little more interesting. It could be yours. It could be someone else’s. It could be someone else’s that you shared. It could mention you. It could be an old white man with a young Asian girl as his profile pic who is suddenly complimenting you for no reason and sending you links to his personal site.

Those are all Types of tweets. Can you think of more?

Types create Actions: Some types might exist by default, but usually somebody has to do something to create or change the type of a Content Object. For example, I don’t follow anyone by default, so in order to follow someone, I have to do something. Obviously, I have to click the “follow” button.

Following is an action.

My tweets have different actions (reply, favorite, retweet, etc.) than everyone’s else’s tweets because they are different types of the Tweet Content Object.

For each type, ask yourself how that type happens. Then design a good way to do that action or work with that type (depending on what it is).

****

This Content Object technique packages a lot of complex information into relatively few boxes. 

And those boxes are pretty easy to talk about in a meeting, so it’s useful for more than just you.

It let’s you ask yourself stuff like:

  • Where do I go in the app to find this Content Object?

  • How is this relationship between Content Objects useful?

  • Do users need this Type? How could they use it?

  • What are the priorities of these actions?

And since types and actions are related to a specific Content Object, you will never be confused about which features are needed in which places. They are naturally in “sets” that go together.

And that’s it!

Work through this little step-by-step guide, and you will have planned the information architecture for any app/site, large or small: 

Step 1) What are the main Content Objects?

Step 2) What Relationships can they have with each other?

Step 3) What Types do those relationships create?

Step 4) What Actions do I need to create or work with those types?

****

If this all seems a bit difficult, let me know on Twitter!

J.