Priority lists are a great tool to start architecting services before form comes into play. They help postpone judgements about shape or layout and concentrate on user needs, business goals and messages instead.
And they are great for introducing the Containerist model.
Let’s imagine you want to buy a bag. This bag:
In order to make up your mind, what information would you most certainly need, in order to make your decision to actually buy the bag? What information can’t you do without? Probably, it would be something like:
1. **Bag’s name and picture**
The reason is simple. If you don’t know what you buy, you won’t buy it. Well, you might not buy it if it does not suit your wallet. Ah, how much is it? And can I buy it?
1. Bag’s name and picture 2. **Price / Buy**
For most of us, just a picture and name of the bag is not enough. If you are not certain about some criteria of the bag, you will want to find out. That means, you would need:
1. Bag’s name and picture 2. Price / Buy 3. **Description**
All of a sudden, you might find these priorities:
1. **Watches** 2. Bag’s name and picture 3. Price / Buy 4. Description
How come? The bag manufacturer not only sells bags. They also do watches. In fact, the watches sales guy is well respected with the company’s C-level and insists on offering his watches at all product touch points. The question is: will it help you to buy the bag? If the first thing you notice is watches, will you continue your journey? My assumption is, watches are not your first priority, but rathier (if at all):
1. Bag’s name and picture 2. Price / Buy 3. Description 4. **Watches**
I guess, you get the idea. So here we are. Our list could be longer, but the foundation is set.
1. Bag’s name and picture 2. Price / Buy 3. Description 4. Other bags 5. Watches 6. About the company
To achieve a priority list with all stake holders is often hard and tricky. Politics kick in. They cannot be disguised as opinion about form. There is no “Well, I’ll sneak my stuff next to Prio 1.” These lists tend to have no side doors. Stakeholders often describe the process of making such lists as brutal and hurting.
But if you achieve to agree on a priority list, the further steps are a walk in the park. The notable aspect: A priority list is one-dimensional. One item is always higher or lower prioritised than another one. It reads from top to bottom.
If we take such a priority list as a basis for a web page, we’ve got something handy at hand: a web page is read (and thus constructed) from top to bottom. And a priority list is read from top to bottom. Thus, we can take the list’s items and lay them out on a vertically oriented page from top to bottom.
We can take each list item and turn it into a box, a container. There is no need yet to decide how the container has to look like, what details would be shown, and in which way. But in the first container, you will get name and picture of the bag. And the sixth container would tell you about the company.
On such a page, there are no two containers next to each other, since the priority list does not have two items on the same height. That means, that a container claims 100% of the page’s width (although, it dos not have to visually ”fill” all of it).
Each container has to have one type of content and one goal. If we start mixing bags and watches into one container, the container approach’s advantages would be nullified.
After the priority list is set, we define the content and form of each container. Always, each container has a group of stake holders, who have to come to an agreement. This involves a lot of painful politics as well. But these politics are then encapsulated. If there is trouble to decide on the contents of one container, we don’t question the whole site or page. We sort it out separately. This means smaller stake holder groups and hence less friction.
In this example, I have just told you about the Containerist paradigm:
A Containerist web page is a stack of autonomous containers.
This sounds straight forward. Yet, it has quite some implications. In fact, if you want to unleash the full potential of web containerisation, there are principles to follow.
Through starting with priority lists and then turning them into containers, you will have a common language. It enables you to work with managers, sales people, marketers, ux designers, content strategists, visual designers and developers.
Maybe I promise too much? To be continued.
(cc-by-sa) since 2005 by Konstantin Weiss.