What is content modeling?
Apart from being unique with the API-first approach, Contentful is different than other CMS in that users don’t have a predefined content structure to work with. WordPress, for instance, is optimized for blogs and simple websites. You have title, body, categories and alike. The structure can be customized with custom fields and some people are making a good use of them.
In Contentful, however, you don’t have predefined structure. The purpose of content modeling is to let you define your own structure and optimize it for a specific use case. Our CMS has been used on websites, mobile applications, watch apps, big touch panels; it is used for recipes, news, e-commerce sites, bank software, in healthcare and more.
This means that defining a content structure sets the stage for everything that you do later on: content production, content management or delivery. The choices made in the beginning can have a big impact later.
Challenge
We are in B2B world, dominated by enterprises. Most people think it's a very boring world. Let me try to reassure you – it is anything but boring. We are exposed to our user through research and usability testing; we're constantly improving our design process and trying new methods and tools; people outside design are involved in design process; and we are solving real problems that people face everyday.
We are performing research and continuous basis and it uncovered several problems we wanted to tackle:
- People sometimes struggled with understanding which field type to use for a specific purpose (we had symbol field type that was hard to understand and people often made bad choices)
- Interface for defining the content type was overwhelming and interactions were designed is such way that it is easy to make an error
- It wasn’t obvious which settings are applied to a field
- It was very hard to apply validations to a field
On top of this we wanted to solve one more problem: to allow content modelers to define the ways in which writers can produce the text. Would it be single or multi line field? Rich text or markdown?
[image of an old interface]
Convergence
We started with several collaborative brainstorming sessions in which we explored many alternatives. The important aspect of these sessions was that we tried to include as many different profiles as possible. Engineers, product managers, C-level managers and designers all took part in the sessions. In this phase it was important to generate as many ideas as possible. We focused on quantity, not quality.
After each session we did concept critique so that the task for the next session was to improve based on the critique. This way we filtered out bad ideas and build on top of each other ideas to come up with something better.
So, we have content model that consists of content types that consist of fields that have settings, rules and appearances. when you set up your content model, writers can produce a content based on the structure and rules you have provided. Sounds simple. But not easy.
Designing this hierarchy, relationship between objects and how everything affects content delivery and production is a large and complex problem space.
One direction that we took was to visualize the hierarchy and elements, and design entire content modeling on this one screen. It was too complex, even though the database diagram like visualisation provides a good overview of your content model. We discarded this idea at the time, however, we still keep it in the archive since we think it might find its place sometime in the future.
I mentioned that the goal of the project was not only to improve content modeling but to allow content modelers to design how the content will be produced. The sketch above shows the content type editor (i.e. this is where you define content structure) on the left and form designer on the right (i.e. this is where you define how the form for producing the content will look like and behave). This idea got refined further.
The sketch above is one from the series of ideas we had around interface that combines contenet structure and appearance. While this particular direction was discared due to complexity, it helped us come up with better ideas on how to handle complex field settings.
Ideas that came later in the brainstorming process was to reorganize field types, provide better guidance on when to use each field and design better flow for manipulating fields. The sketch above shows the idea that we continued exploring with prototyping and pretty much ended up with.
A small note on sketching
Since many people don't want to participate in brainsorming sessions with the excuse that they are not artists and don't know how to sketch, it is worth mentioning that, as quality of these sketches suggest, the purpose of sketching is not to create beautiful deliverables and show your artistic skills. Sketch is just a tool that you use for externalizing your ideas and solving problems. Just like you use hammer, even though you are not skilled construction worker. Sketch can be as rough and ugly as ours are. The second sketch for example? Just semi-straight lines and boxes-wannabes. You can do it.
Divergence
What do you do with hundreds of ideas? You filter them rigorously, keep the ones worth exploring further and build on top of them. Then you filter again and again.
We first filter out ideas with design critique where we gather the entire team and discuss how each idea accomplishes the goals we have set. Another tool we like to use is role playing, where two members engane in a conversation between "user" and "an interface". This quickly shows us whether the conversation makes sense at all.
This way we filtered out ideas that didnt work well so we were left with just handful of ideas. Then we fired up Sketch App and made a bit more hi-fi prototypes, uploaded them on InVisoinApp and tested with users until we decided on one idea that worked the best.
Let me quickly show you a couple of variations of the prototypes that haven't performed well.
Image above shows content type editor with a switcher at the center of the screen. The ide behind the swither was to be able to quickly swithc between definition of fields and appearance of fields. Almost nobody understood the element. Most people expected to turn some form designer on and off and they didn't actually know what to expect.
We removed the switcher and added appearance option to ech field which was much more clear for users.
This idea failed. We wanted to try combining field definition with appearance into a single interface. On top of that we added the list of content types that users would add through the same interface. All this made things very complext and reduced the time needed to create a content model.
Final design
This worked! The screenshot is taked from the latest prototype we tested before going into implementation.
During the implementation phase we worked tightly with development team to help them with edge cases and things that were vaguely specified and, of course, to make sure the design is implemented properly.
Lessons we learned, as a team
- Our prototypes weren’t the best for the job. Since this part of the app is interaction-heavy, HTML/CSS/JS prototype would fit much better than static, mockup-based. We spend a lot of time refining things in Sketch after each round of testing.
- Copywriter was involved late in the process and that introduced unnecessary changes to the design. This should be obvious, but always design with the real content.
- We focused on happy paths only and didn't cover all the edge cases. Developers, on the other hand, think in edge cases. This produced a friction during implementation.
- Even though engineers were involved in the process, we could have involved them more. It would have been better buy-in for ideas and it would have provided better sense of ownership.
- Instead of focusing on outcomes, we focused our attention too much on deliverables: what format do we need, how detailed deliverables shoudl be, etc.
Also, we are hiring
Part of the problem is that we have too few resources in the design team. If you are interested in helping us out, we are hiring developers, prototypers (UX developers) and designers. Check out our carreers page for more.
