- 10 minute read
- Content, Business
- Share on Twitter, LinkedIn
If, like me, you spend more From your days working on content-driven websites, you may feel left out of the party of cool kids. Best practices like Agile, continuous iteration, and user feedback don’t sit as well when you’re serving a lot of information, rather than a great web app.
When I’m talking about a content-driven site, I get I mean any website whose primary goal is to convey information, rather than complete tasks. These are typically marketing-driven websites, but they may offer customer support or have an academic or journalistic role. They allow users to complete a few tasks, like signing up for a newsletter, but that’s only a small part of their purpose.
Unfortunately, the way many of us build websites based on in content is not quite optimal and we have to do something about it.
The Problem With How We Build Content-Driven Websites
These sites often start from the wrong premise. We start by asking ourselves, “What do we mean?” instead of “What does the user want to know?” This mentality has its origin in the creation of content for other channels. Channels where it is necessary to capture the attention of a person and keep it as long as possible, but when designing websites the premise is different. People have chosen to visit the site and, to some extent, have already expressed interest. So the emphasis is on answering your questions to your satisfaction rather than getting your attention.
But that’s not the only problem with how we tend to approach content-driven websites . In many cases, they are still created using a more waterfall-like process than agile.
- We create designs and sign them off.
- We create design templates within a system of content management.
- We add content to the CMS.
Often, layouts are created before we see the content and therefore there is little relationship between both. Content is essentially poured into layout buckets. -c70bdd23d3c0/content-heavy-02-800w-opt.png” alt=”Because we’ve separated content from layout, we’ve reduced the interface to a template that we pour copy into.” />
The most diligent among us refuse to start designing until We may have some real content to work with, but that often causes others to rush to copy to avoid delaying the project.
Of course, then there’s usability testing. It’s often neglected as we keep adding content right up to release day. But even if it does happen, it tends to be towards the end of the project when no one wants the hassle and cost of changing things.
If all of this sounds suspiciously familiar, don’t be discouraged.In recent years I’ve been trying a different approach. erent and, for the most part, it seems to work. It’s an approach that builds design and content together in partnership, while at the same time allowing for regular testing throughout the process.
Starting Content-Driven Website Development
I tend to start content-based website projects pretty much as you would expect. I start by establishing a prioritized list of business goals for the site so we can measure success and be clear about what their role should be. But after that point, things quickly deviate from the standard waterfall process I encounter so often.
Rather than jump right into design and brand messaging discussions, I’d rather focus on better understanding the people who visit the website. It is true that doing user research up front is far from revolutionary. But it’s surprising how little happens in many organizations, even in 2017.
What may be a little more unusual is that my research typically focuses largely on establishing the questions users have when they visit the website. Questions from both first-time visitors and returnees.
Collecting these questions is relatively easy. We start by interviewing users. However, there is a limit to the number of users you can talk to. Another approach is to conduct a survey on your existing website asking users what questions they have Finally, talking to customer service personnel, such as those in call centers, will generate a significant number of questions that they will hear repeatedly.
The final list of questions is likely to be long, but that’s okay. However, some of those questions will be more important than others. We need to identify them to make sure they are easy to find and don’t get lost. get lost in the plethora. less critical queries.
That’s where Gerry McGovern’s main task is Analysis can help. It’s a simple process that polls users to understand which questions or tasks interest them the most. Gerry has written an excellent article in A List Apart covering the process, so I won’t repeat it here.
What the main task analysis will leave you with is a prioritized list of questions users have . That can become the core of the site’s content and help us iterate towards a useful website.
Iterate through content and design fidelity
Before we can To start iterating towards our entire site, we must first need to establish its information architecture. Our questions can be the basis for determining that structure.
We can use the questions as the basis for a card sorting exercise where users organize the top questions into groups that make sense to them. These groupings can help inform us as we develop the information architecture of the site, ensuring that the site reflects the mental model of the users, rather than the organizational structure.
Once we have an initial draft of our information architecture, we can start building our site and testing it, even if we haven’t laid out a design or written copy.
Content-driven websites They are almost always built on a content management system, so while they were investigating user questions, developers could do a ready-to-use installation on a test server somewhere.
Now we can start creating blank pages in this CMS that reflect the information architecture. All the pages need is a method for navigating between pages (navigation links) and bullet points of the questions we anticipate answering on each page.
That immediately gives us something tangible to try. Even without design and content, we can still check the information architecture. Can users find the questions they want answered? Does the structure make sense to them?
With this in place, we can now start increasing loyalty. The designer can start to introduce some basic typography and layout to the critical pages. In the meantime, content writers can start building pages with some preliminary bullet points that answer the questions on the pages or, where appropriate, temporary cross-links to existing site pages that answer the questions.
At this point, we can do more testing. We can see if the visual hierarchy established by the designer allows users to spot essential content. Similarly, we can test the content linked to the old site to see if it answers user questions before we mindlessly start migrating from the old website.
In the next round of iteration, Copywriters can start adding rough copy throughout the site, while designers can start refining the design with improved typography, color, and other styling elements. Again, this can be tested with real users to ensure that the new copy answers questions and that design improvements help rather than distract.
So the process continues, round after round, adding more fidelity to the copy and design, getting the site ever closer to something that is an improvement on the existing one.At this point, we can push it live.But even then, additional rounds of iteration can continue to evolve and improve the performance of essential pages.
Of course, this all sounds good in principle, but it requires a change in thinking.
A Shift in Thinking
It requires different thinking for designers to begin with. Many designers still use Sketch or Photoshop to design high-fidelity mockups. This approach suggests they iterate towards a final layout in the browser.
That said, I don’t think the two approaches should be mutually exclusive. There’s nothing wrong with experimenting with more refined design solutions from the start in Sketch, as long as you understand that these will change based on user feedback. That design can then be slowly deployed and tested on the test server.
Another change in attitude will be around content migration. Usually, we will be supposed to migrate the content from the old website to the new one en masse. The idea of creating all new content may seem insurmountable.
That’s not really what I’m going for. We can migrate a degree of content where that content answers user questions. But this shouldn’t happen en masse or blindly.
In addition, you’ll find that you don’t need to rewrite as much content as you think. You will almost certainly find that a significant amount of the copy you think you need to migrate may be removed because it doesn’t answer a user’s question. The advantage of this is that you have a lot less content left to maintain.
Probably the most significant change in thinking, though, is to show the work in progress. Whether designers or content specialists, many of us still suffer from this desire to make everything perfect before others see it. But this approach puts content and design out in the open and exposes it to criticism. That’s a challenging mindset shift, but an imperative.
You may be thinking that letting stakeholders and customers see work-in-progress is a recipe for disaster, but it’s not. In fact, in my experience, they respond favorably to seeing a site spring up before their eyes. Instead of waiting weeks (or even months!) before seeing something, they’ll start seeing the skeleton of a website within days of launching the project. Psychologically, that makes a big difference.
Also, by seeing the development of the website step by step, they feel more committed to the project and learn about the process behind its development. development. . That makes it less likely that stakeholders will reject the final solution.
Finally, if they do have objections, they are identified earlier in the process when they are easy to fix. Surely this is preferable to waiting until the last minute when things are hard to change.
Take the first step today
I am not suggesting that the evolution of a content-based website on this one is a perfect solution, but I’ve found that iterating towards a final site by systematically increasing design and content fidelity leads to better results and less internal resistance.
Still, don’t take my word for it. try it for yourself. Start small. Jumping into a major redesign of your entire website may be too big a step for everyone involved. You may want to try this approach on a new microsite or on a section of your site that you’re updating.
Or, try implementing only part of the process I’ve outlined. Maybe you just start a project by collecting user questions instead of starting with the messages your organization wants to send. Or maybe you could try a small amount of prototyping instead of producing pixel-perfect layout comps.
My point is that you can choose what works for you and you don’t need to change overnight. tomorrow.What matters is that you start allowing user feedback to influence the design and content of your site.
.