Content Writing for Website/Blog (100+ New Content Hacks 2019)

100 Tips for Content Writing for a Website 2018

Content writing for a Website

We all know that content is the life and soul of the Internet. It is the reason people visit our sites, and the reason they come back over and over again (or at least we hope they do). In the process of making sites responsive, we tend to simplify the design and remove unnecessary decorative elements, and our layouts tend to become cleaner.

 

Because of this, the content increases in importance as it is propelled to the forefront. Eileen Webb’s words clearly capture the way in which content becomes even more important than it was before when we move toward responsive web design:

 

When you strip the pomp and circumstance out of a beautiful desktop view, you’re usually left with a very straightforward, single-column, a small-screen design that puts content front and center.

 

A lot can be said about the creation and management of content in a responsive website, but most of those things can take an impressive amount of time to be brought to fruition. This blog focuses on how you can improve your existing content and provides 100 Tips for Content Writing for a Website 2018.

 

When you do not have a lot of time on your hands, and when you have to choose very carefully what you focus that time on. I assume that you do not have enough time and resources to work on a complete overhaul of your content strategy and content management system. 

 

This blog provides some exercises and tools that can bring your website closer to giving your visitors, users, and readers a great reading experience when they access your website from any platform and any screen size.

 

Designing with Real Content

Designing with Real Content

When working on a responsive redesign, you will hopefully be testing your website with real prototypes as soon as possible and, as much as possible, on real devices and emulators.

 

It is important to understand that the best way to test the prototypes you will create throughout this responsive project is by using real content, or at least content that is very close to the final content.

 

If getting hold of the final content before you start prototyping is not an option, you can design your responsive website using example content: content that captures the key message and expected the length of each piece of text, but that is still likely to be changed later.

 

This way, your designs, and prototypes will be similar to the final content, even if you know they will suffer various rounds of changes when stakeholders provide feedback at different stages (probably later in the process than you would hope).

 

And there are always last-minute changes that come up when you look at the final prototype that you have to account for anyway. By using example content, you will not be tempted to quickly remove a couple of words of your “Lorem Ipsum” text block to fit your designs better (not that we have ever done that, of course).

 

By looking at text and images that are close to the final thing, you may see ways to improve the flow or length of your copy to make for a better reading experience. In some cases, for instance, you may notice that it would be fine to explain certain aspects of your product in more words, without the pages becoming too long.

 

And, more often than not, you can locate areas that need improvement because they are too lengthy, are too repetitive, and/or provide too little useful information for your users.

 

The way you go about collecting or creating example content can vary. In some cases, content production, user experience, and visual design are worked on by completely separate teams that do not even share an office.

 

If this is your situation, then, assuming that you are planning on repurposing your existing content, you may want to carve out some time to suggest improvements or small tweaks to the content.

 

You will have to handle this exercise carefully because you do not want to imply that other people have done their jobs badly. Let people focus on the new, responsive paradigm and on how your existing content can be greatly improved for it if you apply a few small changes.

 

And make sure you tell everyone involved that this exercise will be part of the plan from the outset— few situations are more aggravating than showing up at a meeting to see someone present an “improved” version of your own work, without you knowing what is coming.

 

If you are closer to the people who are creating content, or if that is already part of your or your team’s role, suggesting example content will come more easily. But you should still inform the broader team and stakeholders that they should expect some changes.

 

Regardless of who is creating the content, if it is not you or your team, and you are handed wireframes that only show dummy text, politely ask for an example or draft content, and explain how using it will improve your prototypes and designs.

 

Focus on Accessibility

Focus on Accessibility

A common reason for this fear is the misconception that making a website accessible means extra work that takes time and does not bring visible results. Another reason is the absence of a vision of how focusing on accessibility can deliver an improved user experience for everyone and higher profits for the company.

 

On top of these reasons is a lack of understanding of exactly what can be done to makes our sites more accessible. 

This kind of thinking leads to teams who only think of improving their site’s accessibility on an ad hoc basis or toward the end of a project, when all or most of the content, design, and development decisions have already been made and implemented.

 

Accessibility should not be something you add to your website at the end of the project. Rather, it should be a part of the way you create your content, design your website, and build it. It should permeate the entire process from the start, and content strategy and content creation are not an exception.

 

In some jurisdictions, making sure a website is accessible is written in the law. But even in those cases, accessibility considerations have a tendency to be relegated to the final stages of the process.

 

Good Accessibility Helps Everyone

Good Accessibility Helps Everyone

Considering users who have accessibility issues does not simply mean catering to users with permanent or long-term physical impairments, such as visually impaired and colorblind users, or people with reduced mobility.

 

Accessibility issues do not just translate into the user’s physical or mental disability; they can relate to a temporary factor in the user’s circumstances. Consider the following scenarios, where the user’s context means they are having a harder time than usual accessing content or completing a task:

 

  • Someone in a hotel on a business trip trying to do some work on a very slow Wi-Fi connection
  • Someone holding a baby with one arm and trying to reply to an e-mail with the other

 

  • Someone whose first language is Greek, who is trying to read a website in English
  • Someone in a wheelchair who is trying to fill out a form, only to discover halfway through that they need a document that is on the first floor of their house, but they are home alone

 

  • Someone with dyslexia trying to find something on a website where the navigation is inconsistent across different pages

 

Obviously, this is just a tiny fraction of the kinds of situations that can cause any typically “able-bodied” user to have an accessibility issue.

 

What You Can Do

It is very unlikely that you will have time to go through all of your content and correct any accessibility mistakes that may have slipped through. But you could perhaps begin by selecting some of your key pages or passages and improving the accessibility of your text.

 

Here are a few things that can get you started:

Avoid long sentences and paragraphs

  • Avoid long sentences and paragraphs, because some people have difficulty focusing on an idea for too long.
  • Break up long blocks of text into smaller chunks by using headings and bulleted lists.

 

  • Avoid complicated words that are not necessary.
  • Make things easy to understand for people for whom your language is not their first language.

 

  • Consider including a table of contents at the start of a long page.
  • Use the active voice instead of passive voice if possible, and avoid double negatives.

 

  • Provide text alternatives for media formats such as video and audio.
  • Make sure images and other graphics have alt text or a detailed caption.

 

  • Provide a glossary for technical terms or abbreviations.
  • As much as possible, keep your site’s navigation and key interactions in the same location throughout.

 

The list could go on—you can find more design- and development-specific accessibility points in the final two blogs of this blog. If you do not have enough time to edit existing content, you may want to consider proposing a plan to review sections in the future, as they go through updates as part of the normal maintenance cycle.

 

Good accessibility should be the responsibility of everyone on the team, and it should happen instinctively as part of the design process, but we all know that this is easier said than done.

 

Ideally, someone on your team (and people on other teams that are involved in the production of any type of content for your website) should be nominated to be accessibility champion or accessibility advocate.

 

Focusing the team on accessibility throughout every stage of your projects should be part of their job description. It may be easier to start this on your own team, where you have more power to influence the process;

 

But hopefully, as other teams see how you put this into practice, it will be easier to establish accessibility advocates throughout the organization.

 

Accessibility and Usability

Accessibility and Usability

I think it is worth clarifying that accessibility and usability are not the same thing. To make a long story short, usability relates to how easy your website is to use, and accessibility relates to how easy it is for users to “perceive, understand, navigate, and interact with” your site’s content. 

 

When I speak about improving a site’s usability, I mean you should make sure users know what to do to accomplish their tasks and do not feel lost on the website. They probably should not have to read long, complicated instructions, and they should be able to undo or correct their errors easily.

 

When we say a website must be accessible, we mean any user, using any type of device or any type of technology, and with any type of physical or mental disability, should be able to access the website and its content. These two concepts work together to create an ideal user experience. You should give thought to both and actively improve your website with both in mind.

 

Reviewing Your Existing Content

The first unavoidable step when improving your content is to carefully catalog and examine it. Yes, I am referring to doing a content inventory, followed by a content audit.

 

Before you can make any decisions regarding your content, you need to know exactly what you have to deal with: how much content your website holds, and the state of each piece of content.

 

Content Inventories and Content Audits

content_inventory

Some people use the terms content audit and content inventory interchangeably. But if you want to differentiate the two, you can say that a content inventory does not necessarily imply an evaluation of the content—just the inventory itself—whereas a content audit does.

 

A content inventory assesses the content in a quantitative manner, and a content audit measures it in a qualitative manner. You can audit the content after you do the inventory; but they can both be done in the same document and even at the same time, so you do not have to physically separate them in two documents.

 

A content inventory and a content audit are useful tools to start estimating how much time you will have to spend working on the website to make it responsive. These estimations likely will not be accurate at first.

 

But creating these documents is a good way to get a bird’s-eye view of your content and the effort involved early in the project, which may help you plan later stages.

 

The content audit can become a document that is used throughout the responsive redesign to understand the complexity and amount of work ahead, even in projects where the content will not be rewritten or tackled in the initial phases.

 

Many people find this type of exercise tedious because it involves long spreadsheets and mechanical work—it does not have the glamour of designing and building cool-looking responsive prototypes.

 

But I find it exhilarating because the product of a content audit can (and should) provide an important overview of all the parts of your site—even the ones that tend to be forgotten. Now, open a new spreadsheet, and let’s get cracking!

 

Doing a Content Inventory

Doing a Content Inventory

You may already have created a content inventory for your website at some point. If you did, you may want to start from there rather than from a blank file. But you still need to go through all the content of your website, page by page or screen by screen, because it is very likely that your content inventory is not up to date.

 

Make sure you take your time and do not rush through the inventory. This is an invaluable time that you will spend learning about and understanding your content. You may want to put on your headphones, get some music rolling, and become completely immersed in your content.

 

The information you include in your content inventory should be adapted to what you want to know about your content, and you can change this as you go along and as your project evolves. You can begin with the following column headings:

 

Title: The title of the page

Location: The page’s section in the IA. For example, “Products ➤ Blinds & Curtains ➤ Roman Blinds.

URL: If there is a clickable link that takes you to the section, it should be listed here.

Copy: A brief description of the main content.

 

Images:

images

Include all the images used in the section. You can also specify types of images and call out any image that may pose a problem in a responsive redesign.

 

You may have something like this: “5 product photographs, 1 diagram—will need to be redone in HTML & CSS.” Also note whether there is alt text or a caption for each image, or whether this needs to be created.

 

Other media:

Just as for images, list media assets such as videos and audio, and highlight any potential risks and any assets that will have to be re-created. If you prefer, you can have a different column for each type of asset.

 

Owner: Who owns the content, and whose responsibility it is to edit it.

Author:The author may be different from the owner, so it may be a good idea to list them separately.

Last update: If you can find out, indicate the date when the page was last updated.

Notes: Any other remarks you would like to add.

 

In a more thorough content inventory, you should also include things like e-mail newsletters, printed materials, and anything else that holds your content. Because you are creating the inventory to aid you in a responsive retrofit project, you may have to leave those types of content for a later stage; but keep them in mind for the future.

 

There is no fixed way to perform a content inventory, so you should feel free to change the process to whatever suits the needs of your website. You may want to include more information or structure your document in a different way.

 

And remember that your content inventory can be edited as you go along; it is a living document that will be useful for your team as a guide to the work that will be done during your responsive retrofitting project.

 

Doing a Content Audit

content-audit

The main goal of a content audit is to evaluate your existing content. You can do the audit at the same time you catalog your content, or as a separate step. An easy way to start evaluating your content is by using the ROT method, a common content strategy exercise. ROT stands for redundant, outdated, and trivial.

 

The goal of this exercise is to identify content that falls into any of these categories.

Here are a few examples of ROT content:

  • Broken links and missing pages
  • Content that is repeated on different pages or in different sections on the same page
  • Events that are in the past but are presented as being in the future
  • Inaccurate contact details
  • Old features portrayed as new features
  • Pages that no one ever visits

 

As you identify and record your site’s ROT content, you can also make a note about the effort needed to improve it. In certain cases, it will be easy to fix the problem, such as incorrect contact information or broken links.

 

In other cases, a longer, more complex process for updating or curtailing the content may have to be set in motion—and perhaps may be out of scope for your responsive retrofitting project.

 

You can also do a more in-depth analysis of your content that registers in more detail what the state of each piece of content is and the risks associated with it that are relevant to making your website responsive.

 

Taking your content inventory as the starting point, create a spreadsheet that includes information such as the following:

  • Summary of the content
  • Type of content
  • Risks it may bring to a responsive website (for example, it is too long, it is a complicated table, it is in a format that is not readable on smartphones, and so on)

 

  • Does it need editing? If so, should it be edited before the responsive project is launched? At which stage?
  • Estimate of how long, or how much effort, it may take to be improved (or taken care of in some other way). You can separate quick fixes from more complex ones in different columns for easier scanning.

 

Some of these questions may be hard to answer at first—that is why you should take your time with your content to truly understand its ins and outs.

 

Just like the content inventory, the content audit is a living document that you can keep adding to. And much like the content inventory, the content audit should be relevant to the needs of your particular project.

 

Bear in mind that this audit does not just relate to copy. You should make sure you include other types of content in your document, such as images, PDFs, videos, audio clips, and so on.

 

There is no right way of going about your content audit. Starting with the ROT methodology is a quick way of getting stuck in the audit, but you can assess your content in other ways.

 

Remember that you should take advantage of the time you are going to spend with your content.

 

Take it all in, read it carefully, and take thorough notes. You may not be able to act on many of your findings, but the audit will be an invaluable document that you can use to make the case for and plan further improvements to your content.

 

Quick Content Inventories and Content Audits

Content Inventories and Content Audits

If you simply do not have time to do an exhaustive, full inventory of your existing content (and you really must have an excellent excuse not to), you may want to consider listing portions of your website, instead. These can be

  • Sections
  • Modules
  • Screens
  • Passages
  • Anything else that works for your website

 

It may be tempting to employ some sort of automated script that collects your inventory data for you, but it is important that you get your hands dirty and immerse yourself in your content, learning it inside and out.

 

So, yes, you also need a spreadsheet for this type of inventory—trust me, you will not be able to avoid working with spreadsheets when dealing with content! (p. 100) suggests a way in which you can do a speedier content audit if time is lacking.

 

In this case, you audit only a subset of your full content inventory. Karen lists three ways in which you can determine what content to audit:

 

  • The breadth of content: Can you focus on only one section?
  • The depth of content: Do you need to audit all levels of your website, or only down to a certain level?
  • Content types: Can you analyze the different content types instead of every unique page?

 

Even this simpler type of content inventory and content audit will provide you with documents that you can use to estimate the amount of effort needed to bring your content to a good state and, later, to check things off as you work through them.

 

Ongoing Maintenance

One of the biggest issues to overcome when working on a responsive retrofit project is maintaining an existing, evergreen website while developing a new website.

 

Avoid Duplicated Work

Avoid Duplicated Work

In order to keep duplication of work at arm’s length or reduce it to a minimum, you should plan what types of changes and updates you will be carrying out and when during the time you are maintaining two code bases. The amount of duplicated work that you will perform will be closely linked to the following:

 

  • Whether you are developing a new content management system.
  • The type of website you run. E-commerce sites and publishers are unlikely to be able to stop updates to the website.
  • The type of roll-out strategy you will set in place.

 

If you decide to stop or cut back in any way on the number of website updates your team will work on, make sure every relevant person and the team is aware of your plans.

 

You do not want people to be caught off guard when you tell them you are not going to work on an update that may not seem important to you, but that they have been working on and planning for a long time.

 

Good, up-front communication is paramount in order for a project of the scale of a responsive retrofit to work, not just when it concerns content, but with regard to every aspect of the project.

 

Phasing Content Updates

Phasing Content Updates

A relatively straightforward way to balance ongoing maintenance on the old website with content changes for the new responsive website is to plan content updates based on existing deadlines for other projects.

 

Let’s imagine you are working on your responsive project over six months and that you know that in month 2, one of the sections of your website (let’s call it to section A) will be updated (independently of your responsive project) to reflect changes in the organization.

 

And in month 8 (two months after your responsive project has been made live), another section of your website (let’s call this one section B) will undergo content updates to reflect a seasonal campaign.

 

With this information, you can prioritize content updates to section A. You can make the decision to, alongside the content updates related to the scheduled campaigns.

 

Also improve the content so that it is user-friendly for any kind of device, big or small, improving not only copy but images and other media formats.

 

And you can decide that you will not make any changes to section B as part of the responsive project, leaving those to be made as part of the seasonal campaign updates. Neat, huh?

 

As I mentioned earlier (and as is worth remembering), you need to make sure all the different people involved in content creation and in updating your website are aligned and working toward the same goals and the same deadlines.

 

By prioritizing content updates of sections that are already scheduled to be changed or improved, and working on those sections as part of, or in parallel to, the responsive retrofit project, you can more easily deprioritize the rest of your website.

 

If a section is undergoing updates for a specific go-live date, it should be safe to assume that people are hoping that section will see increased traffic soon after release, so it makes sense to improve these sections first.

 

Updating and Simplifying Existing Content

Simplifying Existing Content

Once you have made the decision to update certain content, you need to know exactly what you are going to do to it: what changes can be made that will benefit your readers but that are also possible given your limited time and resources.

 

The types of updates and improvements you can make to your content are wide-ranging, from quick, less contentious ones to more involved ones that may imply a shift in your content strategy. I cover both types here, but my main focus (and this blogs, too) is on quick wins.

 

The way you approach updating your content will be closely linked to the roll-out strategy you will be following. If you are going to launch your new responsive website section by section, it makes sense to have the copy updates follow the same schedule and the same priority.

 

If you are going to release everything at once, you may want to focus on smaller improvements across the website and larger improvements only to key pages or key user journeys.

 

Quick Wins

You may be feeling overwhelmed by the number of things you want to improve in your website’s content. Fear not. The trick is to start small and persevere. There are some things you can do to begin editing large amounts of copy and other types of content without requiring a huge amount of time or many people.

 

If you conducted a content audit, you have highlighted some of the smaller, achievable tasks that you can perform on your content and that will instantly improve it without stopping the rest of the project from moving forward.

 

Some of the most common things you should be able to do easily are as follows:

  • Correcting typos
  • Correcting inaccurate facts and details
  • Fixing broken links
  • Removing redundant sentences
  • Removing unnecessary adverbs and adjectives
  • Making sure the <title> tag of the page matches its content

 

  • Correcting inaccurate link descriptions (does it say Download but not start a file download?)
  • Correctly labeling links that do not lead to other pages but rather start downloads, such as PDFs, videos, or ZIP files

 

  • Improving link descriptions (“Read the full Acme Corp case study” instead of “Read more”)

 

If you want to go a little deeper and can spend a bit more time crafting your content, try to follow some of the following best practices:

  • Keep the message clear and focused on each page and section of the website.
  • Avoid repetition.
  • Be consistent with call-to-action links, headings, and so on.
  • Link to the same content using the same label across your website.

 

Not many projects have the luxury of infinite time and resources, but in the case of a quick responsive retrofit, that is especially true. This type of task—something that takes little effort or that is not contentious—should be the one that you and your team focus on delivering, at least in the initial release of your updated responsive website.

 

It is a little like doing the dishes and making the bed. These chores are quick and easy to do, but if you do all the other time-consuming spring cleaning tasks without them, your house will still look untidy.

 

Shorter Is Not Better

content_writing

Rewriting content so that it is more user-friendly for someone who is reading it on a small screen does not necessarily mean you need to make the content shorter.

 

Only you will know whether your website’s content is in need of a trim. You would not cut down a long-form investigative journalistic piece because it is too long to be read on an iPhone. You also would not cut down bits of a user manual because it is too long.

 

Each piece of content needs to be evaluated not only in the context of the entire website but also on its own merits. Your website may contain short blog posts and long articles, or it may contain product information pages with lots of images, bulleted lists, and user manuals.

 

If your only goal is to make your content shorter, you run the risk of removing important information that helps explain your product or that makes the story you are telling easier to understand and engage with.

 

To be able to make this type of decision, it is also important to have concrete findings from testing. Your users know best. More often than not, the people who are building a website and creating and maintaining its content are not the website’s target users.

 

Just because you would like your pages to be snappier and have less jargon does not mean that’s what your users expect or need.

 

You can improve existing content, while keeping its length, by making sure you capture the reader’s attention immediately:

  • Make sure your titles and headings include the words that your visitors are looking for and expect.
  • Start with the main idea of the page, section, or paragraph, and only go into more detail further down the page.
  • When possible, break up content into bullet lists.

 

  • Be consistent when referring to key elements in your content. If you say “You should buy our personal insurance” in the beginning, do not say “Read more about our personal protection” later—readers will wonder whether those are the same thing.

 

You may be thinking that these tips are not easy to pull off on a large website without investing a lot of time—which I know you do not have.

 

Just like many suggestions in this blog, these may have to be planned for future projects or later stages of the responsive retrofit project. It is good to have an idea of what can be accomplished if you have a little more time to spend.

 

As you go through your content audit and content inventory, you can note improvements that can be done to each piece of content but that will not necessarily be done straight away.

 

Less Content May Be Better Content

In which room do you think it will be easier to find something: a room where the surfaces are clear and the shelves and cupboards contain things that are well organized and that you can easily glance at? Or a room that has piles and piles of stuff all over the surfaces and the floor, and where the shelves and cupboards are overflowing with even more things?

 

That was an easy question. But for some reason, this idea is harder to grasp when it comes to your site’s content. Make your users’ life easier by giving them less stuff to sift through to get to what they’re looking for.

 

One solution you may want to consider when trying to reduce the amount of content on your website is the creation of an archive or a resource center, where dated content can be moved. This is exactly what we did with Ubuntu Insights.

 

CASE STUDY: UBUNTU INSIGHTS

CASE STUDY

When working on the responsive redesign of ubuntu.com, the large number of various types of dated content was an obstacle to simplifying user journeys, pages, and the site’s IA and navigation.

 

The website included not only product pages, download pages, and contact forms, but also lots of news articles, press releases, events, webinars, case studies, tutorials, and other help pages.

 

The solution the web team proposed to this problem was the creation of a separate website that served as a repository of the dated content that was bloating the marketing website.

 

By moving this content to a resource center, the main website could be simplified, and it would also become easier to inject product description pages with fresh, new content on a regular basis; this content would come directly from the new resources website.

 

This had an immense impact on the IA of the website because it massively cut down the number of pages that lived under the main site’s umbrella. It also made it easier to populate ubuntu.com with fresh information in a more regular, structured way.

 

And it made it simpler for content creators to, well, create content, because the new website’s admin panel was more user-friendly. We ended up with fewer pages and, in many instances, shorter ones, too.

 

The creation of a new project and another website to maintain is, of course, not an option for many teams. But thinking about your content and structuring it into different categories that can be cross-pollinated throughout your pages may be useful when trying to simplify long, convoluted passages.

 

DO NOT BREAK THE WEB

DO NOT BREAK THE WEB

If you do move and/or remove pages or sections from your website, make sure those URLs do not become broken. You do not want people to arrive at your website and immediately be faced with an error or a dreaded 404 page.

 

You should make sure the old URL redirects automatically to the new location, if you moved content around, or to a page where the user can find similar information if you deleted the page.

 

An alternative to deleting an out-of-date page is to include a message at the top of the page that clearly explains that the content is now out of date.

 

Whichever path you choose to take, avoid at all costs creating broken links. Reduce Cognitive Load Without Restricting Access to Content

 

The nature of working on a responsive redesign of your website implies that you will not be separating desktop users from mobile users with a View Full website or View Desktop website link.

 

This pattern indicates to the user that the website they are looking at is in some way incomplete, missing some of the information or features of the “full website.”

 

I do not think this is what you set out to accomplish when you and your team decided to embark on your responsive retrofit. You want to make sure your content is accessible from any device, whatever its screen size or capabilities.

 

This may happen in different ways between devices; but whatever you do, be careful not to remove the ability for users to access content when they view your website on a small-screen device.

 

It is risky to assume which content people will not want to see in certain situations. No amount of data that you can gather to understand how people are using your website will cover all user scenarios. You can have a simplified and more linearized layout for small screens, but that does not mean less content overall.

 

There are design patterns you can use to make small-screen layouts less complex without removing access to content. Running the risk of entering design turf, it is worth noting three common patterns that can be used to reduce the cognitive load on small screens.

 

Show and Hide Content with an Accordion

Show and Hide Content with an Accordion

The first of those patterns is the accordion. An accordion can be useful when the content it holds is optional for the user or secondary to the main content, such as when you need to show full technical specifications on a product page.

 

In theory, an accordion is composed of at least two sections that can be closed, where only the titles or headings of those sections are showing. If a user wants to see the content on one of the sections, the user clicks its heading, and the section opens. 

 

The classic pattern also dictates that when one section of the accordion is open, all other sections are closed. But if you do not want to be too strict, you can give users the ability to open more than one section at once.

 

Accordions are commonly used for frequently asked questions, even in large-screen designs, because they let users skim through the questions without having to scroll past answers they are not interested in.

 

Before you use an accordion or any other pattern that hides content, think carefully about whether it would be easier for the user to scan the content if you left it visible at all times instead.

 

Divide Content With Tabs

Divide Content With Tabs

Tab headers are usually laid out horizontally (especially on small screens) but can also be laid out vertically. The content of one of the tabs is in full view, and when a user clicks one of the headers, the content below that tab comes to the foreground; the other tabs are hidden behind it.

 

Unlike accordions, tabs more commonly exist in the same format (as tabs) in large-screen designs; but they can also appear only on smaller screens when showing all the content at once would make the design too crowded.

 

It is worth noting that, in some cases, tabs in a wide layout are converted into an accordion in a narrow layout. Tabs are popular on product pages to divide different types of content, such as product details, technical details, customer reviews, and so on.

 

Remember that, although simplification is the operative word when responsively redesigning a large-screen design, you do not have to simplify at the expense of the content available to your users.

 

You may want to reduce the cognitive load of your pages on small screens, but be careful not to do it by making your mobile view less useful.

 

Expand Content with reading More

Expand Content with Read More

Finally, the third design pattern to consider, and perhaps the most common of the three, is Read More. This pattern is mostly used to cut off a block of text that may be too long to display on a small screen and that the user may not necessarily want to read in full.

 

A typical place where the pattern is used is in lists of comments or reviews, which can be very long.

 

When a comment is longer than a certain number of words or lines, the text is cut off at that point; if the user is interested in reading the rest of the comment, they can tap the Read More link, and the text block expands to show the entire content.

 

In some cases, the Read More link is replaced with a Read Less link that returns the text block to its original state.

 

When using this pattern, be sure the Read More link is not just hiding a couple of words, but rather a substantial amount of content. Otherwise, the user will feel as though the link is adding an unnecessary obstacle between them and your content.

 

Have a Plan

The good content strategy is not defined quickly in a couple of hours or a day or two. It involves a substantial amount of time dedicated to research and analysis, and it requires the ability to guide what can sometimes be a considerable number of people to unify toward a common goal in the way they create, edit, and publish content.

 

WHAT IS CONTENT STRATEGY?

content_strategy

The discipline of content strategy covers the planning, creation, and maintenance of any of type of content, be it text, audio, video, or other formats. The strategy should be developed according to the business and user goals of the particular product or company.

 

It relates not only to the actual management of time and resources but also, and probably most importantly, to the definition of the actual approach to and objectives for the content.

 

Content strategy does not have to be done or implemented by someone who holds the Content Strategist job title—and in many cases it is not. It can be part of the responsibilities of roles as wide as copywriters, user experience designers, project managers, and product designers, to name a few.

 

It is unlikely that you will be able to completely rethink (or even create) your content strategy within the scope of this project. If there is currently more than one instance of your site—such as different desktop and mobile versions—you may even have different teams working separately on the production and maintenance of your content.

 

The transition to responsive may have a large impact on your content strategy and the way you produce and maintain your content. It may involve phasing out one or more sites to create a unified website where all your content lives.

 

If different sites currently hold different versions of the same content, at some point you will want to define what stays and what goes. And that exercise will also involve defining new processes, and perhaps new teams and new roles. This is not an easy job.

 

You do not want to embark on this mission lightly, and you should not make assumptions about what a perfect content strategy looks like for your company without considering all aspects of the editorial process. Erin Kissane agrees: Content recommendations made without consideration of available resources are unlikely to result in success. 

 

The definition of a sound content strategy for a substantially sized website is a topic that can fill a very thick blog. But the goal of this blog is to give you a jumpstart on your long-overdue responsive retrofitted website while assuming you do not have a lot of time and resources to design and implement massive changes.

 

If budget allows, you may want to consider hiring a consulting content strategist to help you define the best approach for the future, or to at least get you started.

 

Defining a Style

content_style

It may come as a surprise to you, but many large, sprawling websites do not have a copy style guide or a voice and tone style guide. Having a style guide is not something that only newspapers should worry about. A style guide provides writing consistency across different authors without removing their ability to write in their own voice.

 

In many cases, the move to a responsive website is an opportunity to introduce new habits and processes within your team and the larger organization that focus on best practices not only in terms of user experience design but also in terms of copywriting and coding.

 

The creation and adoption of a style guide for your website if you did not have one before may sound like too much effort to put in on something that is not completely related to your goal, which is to have a beautiful, usable, responsive website. But as much as you want visual consistency through a design pattern library, that consistency should start in your actual content.

 

If you cannot spend a lot of time creating your own style guide from scratch, you may want to use MailChimp’s Content Style Guide as a starting point.

style

MailChimp’s style guide is released under a Creative Commons license and is publicly available on GitHub. Although a lot of its content probably will not be appropriate for your specific needs, it provides a structure and can give you lots of ideas about what to include in your own guide.

 

Another option, if you do not have a lot of time to spare, is to look into existing style guides, such as The Chicago Manual of Style, the Guardian and Observer Style Guide, and the New Oxford Style Manual.

 

Many organizations follow existing authoritative style manuals from publishers or schools because these manuals tend to be thorough and prescriptive and there is little else to add to them.

 

But do not let an existing style guide overrule what your particular case needs. You can use it as a starting point, but you will probably have to adopt some rules for your circumstances.

 

At the very least, if your content creators are writing in English, you should define which dialect your company should follow. Just by saying you are writing in British English, a lot of rules will be defined, not only in terms of spelling but also in terms of punctuation. You should also consider things like capitalization. Should titles and headings be sentence case or title case?

 

Should conjunctions and articles be capitalized in title-case headings? Are you going to capitalize job titles? What about your product names?

 

If you have to use technical terms, you may want to start a glossary for your authors to use as a reference, which can be expanded. A glossary can also be used to clarify the spelling of words and terms that can have variations, like e-mail or email.

 

Just like a design pattern library, a writing style guide should not become stale. You can start by defining a few things and expand the manual as questions arise and clarification and guidance are needed.

 

Even if you have a thorough style guide that covers most eventualities, your company may create a new product or service that needs to be added to the style guide, so be sure to keep it up to date.

 

Most important, though, your guide should be easily accessible and shareable among everyone who needs to use it and consult it.

 

It probably will not be possible to update all of your content to match the style guide rules if you did not have one in place before, but you can make the decision that any new content, or any pages or sections that are updated in the future, should also be updated to follow the agreed style.

 

Improving Your Content Management System

Content Management System

Every responsive retrofit project is different, and priorities vary immensely. However, completely updating your CMS is probably a stretch too far if you are trying to cut down the scope of your project as much as possible.

 

Depending on how or even whether your content strategy and organizational structure will change when moving to responsive, you may have to create a CMS from scratch or change functionality extensively in your existing one.

 

The following suggestions are likely to be out of scope for your responsive retrofit project, but they are worth considering if you can squeeze them in. They are not dramatic but rather add small improvements that can change for the better the way your content is produced.

 

Remove Inline Styles

Remove Inline Styles

Some CMSs allow authors to include inline styles (HTML and CSS) in the main content area. We have all heard horror stories of content authors and website owners who have singlehandedly defaced a beautiful website by formatting text as they please (think of a bold, italic, red, justified, Comic Sans text block inside three nested tables).

 

Switching off this ability in your CMS may not be too complicated, and if so, it is something worth doing.

 

If the damage can be done by adding inline styles to a large screen design, imagine what can happen when your website is being viewed across a wide range of devices and screen sizes! 

 

Even if adding this constraint to your CMS is not an option, you may want to consider going through your CMS entries and delete inline styles that are already there. They have a tendency to break responsive design layouts particularly badly.

 

Remove Styling Options

Remove Styling Options

Following from the previous point, some CMSs that use What You See Is What You Get (WYSIWYG) text entry to make it easy for authors to format and style text have the ability to turn off some of those very same styling options at the flick of a switch. If this is your case, you may want to consider doing this and limiting the number of control authors has over layout.

 

Remember: the author’s job is to create and edit good content. If they get stuck on perfecting the layout of the content, making it look just right on their own screen, they may well be counteracting the work that has gone into making the website responsive in the first place.

 

Fonts, Colors, and the Invisible UI

Fonts, Colors, and the Invisible UI

There is a saying, “The best UI is no UI.” That seems to be increasingly true as we passively observe the trends in technology.

 

As we continually try to find ways to lower the barriers of friction for our user’s adoption of our products, we begin to see more and more of our available UI options disappearing. In the coming years, will there be any space left for design?

 

Designers are now embracing the need to become minimalists when they’re tasked to design digital products — boiling functionality down to its essence. What is the bare minimum you need to have a usable product? Font and color play a more important role now than ever if you’re lucky enough to still get a choice in the matter.

 

Defining Visual Hierarchy

Defining Visual Hierarchy

Before doing any design whatsoever, the first thing you need to think about is how you want to prioritize the visual hierarchy. What elements of visual design will you use to cue your users as to what’s most important? The elements we will be focusing on for the purposes of this blog are size, color, and order.

 

Size — The bigger something is, the more important it is.

 

Color — Creating primary, secondary, tertiary colors, and fixing them on a scale of importance: that is, always using a primary color on the most important elements.

 

Natural Order — Whatever you place first in the natural flow of the document is the most important. Natural flow is subjective based on design. It could be top-down, left-right, outside-inside, etc.

 

Of course, you are not limited to these options. These are mainly considered in designing for the Web. Depending on what you’re designing for, you may have access to even more properties. To see a little bit more about how we can leverage the possibilities, let’s take a look at the design of an individual tweet on Twitter.

 

By looking at all of the individual elements in this single tweet, what would you think is the most important part of the design? There are actually several different ways to look at it. A common ordering of importance based on an observed visual hierarchy may go as follows:

analysis

  • The 140-character Tweet
  • The User (name + avatar)
  • Actions to take on the tweet
  • Data about when the tweet was made

 

Based on this analysis one might assume the designer thought about establishing the visual hierarchy in the original order I set forth:

  • Size
  • Color
  • Natural Order

 

There is no right or wrong way to establish visual hierarchy. Aesthetically, I wouldn’t qualify these designs as the best in the world. The design is ultimately up to you and your users. 

 

The point is that setting up a rule for visual hierarchy and sticking to it consistently throughout your design is a very valuable thing to think about before beginning. We will heavily leverage visual hierarchy to create a design that’s purely based on font and color.

 

Establishing a Font System

Establishing Font System

Let’s get started defining a font system for our framework. This section will not be about where to use serif or sans-serif fonts, nor will it be about pairing typefaces. We want to build a robust system that’s focused on function.

 

With a good enough font system in place, we could theoretically swap font-faces at any point in the process without requiring a major design overhaul. It could be as easy as simply changing a variable. That’s the type of system we want to create for our designs.

 

You might find yourself in one of two situations with respect to fonts.

\1.\ You are designing something brand new. You have a clean slate with respect to choosing fonts.

 

\2.\ You are designing an interface for a brand that already has well-defined brand guidelines. You need to establish a system that accommodates set font guidelines.

 

Regardless of which situation you’re in, you should always be wary of the limitations of the Web and always communicate them clearly with brand stakeholders.

 

Custom Fonts and System Fonts

Custom Fonts and System Fonts

Of course, we need to play by the rules of the medium we are designing in, the Web, so we do have a few limitations. When it comes to fonts, rendering typefaces to display to users is a major limitation.

 

A matter of milliseconds could be the deciding factor in whether or not a user stays or bounces from your website. You can have a beautiful design, but if the user isn’t willing to wait to see it, then what’s the point? We need to be careful in how we choose our fonts. When do we need to use completely custom fonts versus generic system fonts?

 

We all know the advantage of using custom fonts is that it gives our sites a unique identity. You want to be able to separate yourself, identity-wise, from the rest of the noise of the Internet.

 

The downfall of that is that in order for the user to see such custom fonts, they need to download that extra data in order to see it. That means longer load times since font files are typically not small by web file size standards.

 

System Fonts, on the other hand, are generic fonts that are already installed on most computers by default and don’t need to be downloaded to be seen. You can save a lot of time by using common system fonts such as Helvetica, Arial, Georgia, and Times New Roman.

 

The reliance on system fonts is becoming even more and more important with the rise of content distribution platforms where you may have extremely limited control over your design.

 

Examples of content distribution platforms are facebook Instant Articles, Apple News, Google AMP, and Snapchat Discover.

 

If you plan on distributing your product through these channels, utilizing system fonts become of utmost importance in order to maintain the visual consistency of your brand. You don’t want your users to have different visual experiences of your designs within each of these different channels, in addition to your own website.

 

Imagine a user reading a piece of your content on facebook Instant Articles, then clicking on a link within that article that directs them to a web view of your website. Will there be consistency in the experience? What if you need to spin up a Google AMP version of your content so you can land higher on Google Search results?

 

Wouldn’t you want the AMP version of your content to have the same look and feel like the content on your own website? Ideally, we would want to maintain visual continuity wherever our user is experiencing our products.

 

Think About Function Before Form

Think About Function Before Form

When defining what fonts we want to use where we want to always make sure we are defining them based on function over form. What does that mean?

 

It is a common practice in web development to name fonts under a system in the following way:

  • $serif_font: Georgia, serif;
  • $sans-serif_font: Arial, sans-serif;

 

This is also a different method with essentially the same fundamental flaw:

  • $primary_font: 'Helvetica Neue', sans-serif;
  • $secondary_font: Garamond, serif;

 

What’s the flaw? These naming techniques define fonts based on form first over function, because the fonts are established on the basis of what the typeface is versus what its function is.

 

Why is this a problem? The typeface is what may be variable as time goes on due to branding changes or other reasons. This defeats the purpose of declaring them as variables to begin with.

 

So what might stay constant? Defining fonts by their function. In our system, we want to think about what types of information we will be commonly communicating with our users, and defining our font system based off of that.

 

  • $title_font: 'Helvetica Neue', sans-serif;
  • $subtitle_font: Garamond, serif;
  • $body_font: Georgia, serif;

 

Establishing a Color System

Establishing a Color System

Creating a color system is a less complicated, more subjective process — but should still be carefully thought out. As a point of emphasis when it comes to usability, you should try not to lean on color too much as an element that defines actions.

 

Accessibility is the main point of concern. About 4.5% of the world population has some form of color blindness, so we should be extra careful not to bias against or exclude those potential users of our products. For this reason, it is always very useful to think about using tints and taking advantage of contrast first, then applying color afterward as an accent.

 

I almost always recommend looking at color in user interfaces as optional. After all, your content should be the element of providing color, and you wouldn’t want unexpected combinations of color creating unpleasant visual dissonance. This is also a reason to leverage some neutral colors in your palette.

 

When setting colors for your interface, another important thing to always keep in mind is common color associations.

 

An example of this in UX design is applying color to positive and negative actions, such as saving and deleting. It would be counterintuitive to use a shade of green as a button color for deleting data or canceling an action.

 

Similarly, it may not be the best idea to apply a shade of red for actions like saving progress or submitting data. These types of choices can cause confusion for your users.

 

For each color, also make sure to consider a corresponding foreground color. There may be instances where your color may be applied as a background where you want to text or other elements to sit on top of.

 

As far as naming goes, it would be beneficial to abstract the names of the colors we would like to use and define them by their roles versus outright calling them by their color name. Consider utilizing a naming system like the following:

  • Primary
  • Secondary
  • Background
  •  UI

 

Many people define their colors in their code by their names: $DarkBlue = #0a62e5

 

I advise against this because you may very well in the future need to update your colors. If you no longer wish to use Dark Blue, then you not only have to update the Hex value, but you also need to refactor every spot where your $DarkBlue variable is declared.

 

This sort of defeats the purpose of even using a variable for your colors. Having an abstract color naming system is more scalable to maintain and easy to pivot in case of brand updates.

 

Let’s Design an Example

color-based site design

Now that we have a very basic foundation of visual hierarchy, font, and color, let’s try to go through an example of building a pure text- and color-based website design.

 

In this example, let’s build ourselves a simple Nameplate website. A Nameplate website is essentially just a website that identifies who you are and has some very basic information about you. It’s basically like a business card on the Web.

 

There are some services that easily allow you to create a Nameplate website without any coding knowledge whatsoever. The most popular example is about.me (https://about.me/).

 

Let’s design our own highly functional Nameplate website from scratch using what we’ve learned in this blog.

 

The first thing we want to do is decide how we want our visual hierarchy to be defined. In this example, let’s go with the following rule of law:

 

  • Size - The biggest things will always be the most important.
  •  Color - Color will be a secondary way to command attention.

 

Natural Order - From top to bottom in the document, although not as important as size. For example, a colored element lower in the document might be more important than something small in the beginning.

 

For fonts, let’s start off by using system fonts, then later enhance our design by converting them to custom fonts. Let’s think about what information we may want to include in our Nameplate website, and define our fonts accordingly. Here is some information we might want to include in our design:

  • Your name
  • Your current title
  • Short description about yourself
  •  Links to your social networks and email address

 

Considering that, here’s how we might want to define our font system:

  • Title Font
  • Subtitle Font
  •  Description Font
  • Link Font

 

Choosing this font system doesn’t necessarily mean we need to choose four different fonts. Depending on your knowledge of font pairing, typography, and personal style (the subjective aspects), you may choose fewer font families but use them multiple times across your font system.

 

Wearables and Conversational UI

Wearables and Conversational UI

With the advent of smartwatches, the rise of conversational UI’s, and even the early signs of experimentation in the space of Augmented Reality, we can already start to see the landscape of where our digital products may need to migrate in the coming years. What will be our options for interfacing with users in the next generation of digital platforms?

 

In the space of smartwatches, the majority of the interface is just font and color. There, of course, is a very limited real estate to incorporate graphical elements. Even still, any graphical opportunities would have to recede to the text, which will be the main communicator in the interface.

 

Conversational UI is even tougher. These interfaces often live totally within the environment of another application. From SMS to Facebook Messenger, and WhatsApp, you don’t even have an option to design the text.

 

Take it even further by considering Conversational UI’s like Amazon Echo and the impending Google Home. In these cases, there is no text. You have but just a voice.

 

Voice and Tone is often an overlooked aspect of UI design. It also is just the beginning of how we really start considerately designing for what I refer to as the Invisible UI.

 

Add Structure to Your Content

Add Structure to Your Content

Are your content authors faced with an input field for the title and then a large text-input field where they can put everything else? Karen McGrane calls this big input field the “giant blob” in her blog Content Strategy for Mobile. Think about how you can start breaking this big blob apart and dividing your content into smaller chunks.

 

Let’s take a look at a common content type, an event, to show how breaking the content into its constituent parts can be achieved.

 

If authors decide themselves wherein the blob to include information such as location, start and end dates, venue, and pricing information, even if they try to be consistent, there is always room for error, and your event’s metadata will be buried deep within a block of text.

 

Consider dividing this information into separate entry fields. In this case, you could have the following:

  • Event name
  • Venue
  • Location (city, country, state)
  • Start date
  • End date
  • Price, if not free
  • Whether it is free (this could be a checkbox that translates into a neat little label in the layout)

 

You should also consider adding better labels to your CMS that explain clearly what each piece of content will be used for and that include examples of what good content looks like for that particular section. This will help authors know what is expected without having to guess, and it aids consistency across your site’s content.

 

Another Option: Doing Nothing

Ideally, as part of a responsive retrofitting project, you will have enough time and resources to make key changes to your content and your content strategy so that they are brought into a more responsive world.

 

But in certain cases, you will have to consider the option of not updating the existing content for the initial release of your retrofitted responsive website.

 

Making updates to the content will likely involve several people who may not be at your disposal throughout the weeks and months during which you and your team work on the responsive project.

 

For some projects, updating the content to improve the reading experience across all screen sizes and to make the content more adaptable to any platform are the prime actions that need to be accomplished with a responsive retrofit.

 

In other cases, updating the content is not the highest priority, and other things, like improving navigation, are more pressing.

 

I am not trying to diminish the importance of content over things like visual design or front-end code. If you already have in place an effective content strategy and your website are populated with considerate, useful, up-to-date content that is accessible to everyone, fixing your content may not be your top priority for this project.

 

Starting from scratch and trying to come up with new solutions will not be the most effective use of time for a team that is already thinly spread across other projects. What I want to accomplish in this section is just to remind you that there is the option of leaving content updates for later.

 

Also remember that, even if you have no time or resources to work on updating your content in the first stages, you will still be looking at and analyzing your entire website as you work through the project.

 

You will surely come across content that you want to improve, so make sure you flag anything that you want to do in the future that relates to improving your content. And by all means, go ahead and fix that typo you find on your home page.

 

Summary

summary

In this blog we learned how to begin a design from scratch, only relying on the most basic visual devices of visual hierarchy, fonts, and colors. These basic elements are often the very first things you should be thinking about when you approach starting a new design from scratch.

 

In addition to that, if you are trying to take an existing design and establish a design framework from it, you’ll most certainly want to tackle defining visual hierarchy rules, establishing a font and color system first.

 

Technically once you’ve established these basic principles, you need to have the utmost minimum knowledge required to start creating logical designs. There are actually plenty of sites out there made with typography alone. Being able to perfect this is true minimalism at its finest.

 

As we progress through the next few blogs we will be adding additional layers of complexity to how we start grouping and clustering these visual elements.

 

As the content of subjects that we need to design for becomes more elaborate, such as in applications or very large databases, the design framework we are establishing will also need to be more accommodating.

Recommend