Are you an engineer who is involved in content platform projects where the people responsible for the content are never consulted during the design phase of a project? Is your time spent making sure the back-end system maps directly to the front-end mockups? Are projects constantly delayed because the content is not ready for launch?
Or maybe you are a content manager who is on the receiving end of a content management system (CMS) that didn’t take content management into account. And now you have to make the content fit into wrong-sized containers and rush to get images created because they are required and everyone is waiting for you to finish.
If you recognize either (or both) of these scenarios, poor editorial experiences are one thing holding you back.
At Sanity's December 2021 Open House, Delightful Editorial Experiences, we introduced four principles of an effective editorial experience to help teams avoid these problems by doing the right thing in the right way.
Watch the session, or scroll down to get the details.
We have distilled our experiences into 4 principles that will make it easier for you and your whole team work toward a better experience for your end-users.
This first one is kind of a mind hack. Beginning conversations with what the end result should be is a good way of thinking when collaborating, especially when a group of people from different disciplines come together. You can even use this one inside your own head!
When we ask for a change, we often try to be helpful and specific. It is polite to talk about solutions, not problems. For the other party, it feels very good to deliver whatever someone asked for. This dynamic often leads to solutions that do not serve the intended purpose.
Here's an example of starting with a solution:
What if someone had provided feedback about shorter titles not filling the space allotted? The team could have worked through a sustainable solution before updating the CMS. Instead of putting the burden on the content manager to make a visual design decision every time, perhaps the developers could have automated the whole thing. The template could have been coded to use a larger font when the titles are particularly short in certain layouts. A one-time fix that wouldn't take any more time to accomplish initially and save hours of time and frustration for content managers later.
The lesson: all participants in the conversation need to understand why something is a problem. Strive to communicate in terms of intentions and goals. When you feel your teammates are jumping to solutions, help bring the conversation back to figuring out what you are actually trying to achieve.
Ideally these goals and intentions are clear, shared, and documented. It may require more work and planning up front, but it saves time and frustration down the line.
Whatever you are making, your product is trying to achieve something, whether it is to get people to change their minds, to buy something, to inform, or to entertain. You want your content team to work on what matters towards meeting that goal. Achieving that end goal starts with being deliberate when deciding what content matters.
There is no one size fits all. There is only the intersection between what your audience needs, what your content team can maintain, and what your engineering and design teams can support. You have to decide what that is for your organization or for a particular circumstance.
If the content manager cannot maintain the content that worked for the design mock-ups or what is required in the CMS to get a campaign launched, then nothing else matters.
It does not matter how delightful you think your tool is if it makes the content manager do a lot of meaningless busywork to get content published.
Sometimes what matters is a function of effort and utility. Simen once worked on a project where the team wanted to portray the international profile of a company by showing the employees as a cloud of shapes labeled with their nationalities. Initially, the CMS had a data model listing employees and their nationalities. Maintaining that turned out to be a lot of work, and it did not matter that much. They were about to cut the whole feature to avoid the content busywork.
Then they discovered the HR department had an API that included employees and their nationalities. So they could automate the whole thing and sync that bit of content into the dataset with a serverless function. Instead of eliminating the feature along with the busywork for the content manager, they got to keep the feature without extra work for the content manager!
It is easy to let the presentation drive the content specification. But the presentation must support the content, not the other way around. This can be a difficult change, especially for very visually oriented teams and stakeholders who just want to know what the website will look like.
If you are living by these principles, you know what your intentions are (principle 1) and you decided what content matters (principle 2). Now your presentations should be supporting that content.
We see a lot of cases where a team has gotten carried away with their sketches and add content elements to their content models to support the idea coming from the visual design. Often these are things that do not matter, create friction, and slow down content teams.
In the visual design phase, a page looks so nice with a huge hero image and the byline of the author with the nice photo and the bio blurb. So you add those elements to the content model in order to support the design.
And now you have created a requirement that the content team must have a hero image as well as an author with a smashing photo and a bio blurb in order to publish a story.
This will create a lot of friction and slow down the content team as they procure illustrations, commission photographers, and decide on bios in order to get a story out.
Sometimes is worth the extra work, but that decision needs to be made deliberately. In this case, you could make the page template tolerant to whatever content is available and limit required elements. It could mean adapting to a story without a hero image and having several variations of the byline to support everything from no author, just a name, a name, and a bio, as well the full blast with photo, name, and bio.
Be careful about holding the content team back. The presentation should support the content that matters and respond to the content in sensible ways to help the result always look good, no matter what content is available.
This principle kind of sums up the whole thing, but it still bears calling out. Your content managers may be heroes who are willing to crawl through glass to get the content to their audience. But you are paying for it with a less effective, less inspired, and less adventurous content team. However powerful your presentation is, your end result will never be better than its content.
Consider how the editorial experience can allow the content managers to focus their energy towards what really connects with the audience. Every layer in the products we make matters, but content is foundational. When you make it easy for the content managers to work with the content they have instead of fighting the tool, it allows the presentation layer to convey the message meaningfully.
This is about going a little bit above and beyond, deploying a bit of empathy to really boost the content team. Oh, and do not just imagine how they work, talk to them!
Following these principles might seem simple, but it is not easy. You can only do better if you know what needs to change. We set up a short assessment for you to see how you are doing on these four principles. Take it now, see where you are, make a plan for improvement, and come back again in 3-6 months to see how much better you are doing.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。