100+ New Content Writing Tips for Blog (2019)

 Content Writing Tips for Blog

100+ New Content Writing Tips for Blog in 2019

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). 


This blog explains how to write effective content for your blog or website that rank higher in Google. And also explores 100+ New SEO friendly Content Writing Tips for Blog for 2019.


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 n a responsive website, but most of those things can take an impressive amount of time to be brought to fruition. 


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. 


Designing with Real Content

 Content Writing

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.




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.


[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


Doing a 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.


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


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.




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.




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.


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.




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


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.


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 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.


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:




Establishing a 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 about 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 to 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.




In this blog we learned how to begin 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.