Tuesday, March 27, 2012

Beyond ROT: Creating useful and meaningful content audits


I've been thinking about content audits a lot lately because, well, that's the stage I'm at in my current project. There's been quite a few discussions and write-ups about audits but I've found that, for the most part, they have a pretty limited perspective. The fact is that a content audit can provide a huge amount of insight into content strengths and weaknesses in the early stages of a project, and help to inform all content strategy and information architecture activities moving forward.

A content audit is simply a snapshot of the current state of content, on a page-by-page basis, before a web redesign or content migration takes place. Perhaps the most discussed way of auditing a website's content is to determine the page count and the ROT: content that is redundant, out-dated, or trivial. While this is essential information, there is so much more information you can gather. And since you're looking at every page anyway, you might as well capture the information that will really help to bring value to your client and the project.

Here are some other content characteristics that you may want to capture, and why they're useful.

Page layout

This shows how the content is laid out on a page. Simply capture a screenshot for each page that uses a distinct layout and give it a name of some sort. I typically use a combination of acronyms and numbers. For example, two different landing page layouts might be LP-1 and LP-2. The purpose of this is to help clients see the inconsistencies in how similar types of information are being presented. It's also extremely helpful when you're doing a content migration where you need to understand how the content works within existing templates and the implications that has on the migration. Finally, it can raise big red flags for content processes if you find that content developers are creating multiple layouts on the fly from a single template.

Content type

Here, you make note of the basic type of content, leaving topic or departmental focus aside. For example, some types of content include forms, contact info, product details, articles, landing pages, FAQs, document archives, profiles, events, etc. You'll develop your list based on your specific project requirements. Together with page layout, this really helps to highlight inconsistencies in how information is being presented. It also helps to raise awareness of pages that are trying to do too many things at once. When you complete your initial audit and sort it by content type, you can quickly scan through your URLs to identify even more redundancy and get a better understanding of the opportunities for content re-use.

Audience

Make a note of who the content speaks to on each page. If it's not obvious after a quick scan of the page content, simply put "unknown". This is a good way to find out if the target audience will be able to immediately identify that this content is relevant to them. If your client has developed customer personas you can use these as a starting place, but remember that the purpose of an audit is to create a snapshot of the current state of content, which may or may not fit well with tools that have been built to guide future changes.

Quality

This is your subjective expert opinion as to the quality of the content on the page. I'll typically use ratings such as excellent, good, satisfactory, or poor, and associate them with qualifying best-practice statements as shown below. If you prefer, you could use grade-scores and use any qualifying statements that make sense to your project. Here's some that are pretty typical for me:

  • Excellent = Content and writing style reinforces brand and provides a surprisingly good customer experience. 
  • Good = Content is reasonably on-brand and supports users in understanding and acting on content. 
  • Satisfactory = Users can get the answers they're looking for, though it may take some effort and the content may not reflect the brand. 
  • Poor = Content does not meet user or business needs. 

Quality Characteristics

This is where you list out the specific weaknesses in the page content. It's important to work with a limited set of characteristics, and to define them precisely. You'll develop your best-practice characteristics based on your project needs and area of expertise, and then indicate where these best-practices are not being met. Some that I frequently use include:
  • User-focused
  • Brand voice
  • Consistency 
  • Context
  • Focused message
  • Out of date
  • Plain language
  • Business relevance
  • Substance
  • Typography, or information design
  • Volume appropriate
  • Writing mechanics
This is an important tool to highlight writing and process weaknesses and can really help your client to begin to understand the skills and resources required to create high-quality writing. It also helps to focus writer's workshops or training on areas that are particularly relevant or high priority.

These are only a few of the things you can look for in an audit. Some other common factors to consider include SEO criteria, content format (video, audio, html, pdf, etc), metadata used, or topics and subtopics. The trick is to find the right combination of criteria for your project, resources, and timeline.

Once you've captured the data, be sure to leave some time to analyse it. It's usually very interesting to determine which areas of the site, or which content types, have higher or lower quality content. Or how many different layouts are being used for similar content types? Which sections of the site are the most out of date, and which  are the most user focused? Which formats are being used for which topics? This really begins to surface inconsistencies and problem areas. These findings give you a strong understanding of the current state of the content and provide key insights when creating the gap analysis that will be the foundation for further content strategy work.

While I'm not going to talk about how to create an audit spreadsheet here, I definitely want to mention one tool that I discovered recently (thanks to Jason Armstrong at the +autonomous agency!) that has really helped to speed things up. If you use Google Chrome, you can go to the Chrome Web Store and download "Pasty". It's a free multi-URL opener that allows you to copy rows of URLs from your spread sheet, click the "Pasty" button, and open new tabs for each URL. You can easily open 50-100 pages with one click, and get through them pretty quickly.

What other content audit criteria or tips have you found to be very valuable? Please share them in the comments below!

Monday, February 27, 2012

The 4 focuses of content strategy

There are so many ways to slice and dice content strategy. Each slice has only limited value. The real benefits come from understanding each area of content strategy well enough to integrate them into a complete strategy.

Here are some of the different approaches that I take to content strategy, and how I integrate them.

Front-end content strategy: This is what your audience sees and experiences. It includes:

  • User experience content strategy
  • Marketing and editorial content strategy
Back-end content strategy: This is how to make the content work well. It includes:
  • "Intelligent" content 
  • Content governance and operations
Let's look at these four areas more closely.

User-experience content strategy focuses on: 
  • User needs and motivations 
  • Content flows and linkages
  • User reactions and interactions with content
  • Content types and formats
  • Comments & other user-generated content
  • Labeling
  • Content findability
  • Content usability
  • Content usefulness
  • Content relevance
  • Content consistency
Marketing and editorial content strategy focuses on: 
  • Marketing objectives
  • Content marketing
  • Brand guidelines
  • Messaging
  • Tone and voice
  • Writing style and quality
Intelligent content strategy focuses on: 
  • Content re-use
  • Content modelling
  • Multi-channel publishing
  • Component-based content
  • Dynamic content
  • Customized content
  • Content requirements for using within a specific technology
Content governance and operations strategy focuses on: 
  • Corporate content policies
  • Content development processes and workflows
  • Content publishing processes and workflows
  • Ownership and responsibilities
  • Team building and training
  • Organization-wide education and change management
  • Content support tools
So, why are we focusing on all of these different aspects of content strategy? So that we know exactly what we need to integrate, and combine with business objectives, to create a holistic approach to content. 

An integrated approach to content strategy across all project phases ensures that content is effective and processes are efficient. It provides a basis for measuring web content success and effectiveness over time, from both a business and user perspective.

Once you understand the different focuses of content strategy, you can be sure that they're each represented in your activities and deliverables. I'll talk more about this in my next post.

Monday, February 6, 2012

How Taxonomy and Metadata Leads to Findability


Kathy's note: This is the ninth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
________________________________________________________________
Taxonomy and metadata are becoming much more popular these days. Companies need to keep track of their information, but can’t use traditional classification systems, such as Dewey Decimal or Library of Congress Subject Headgings. In the last 10 years, faceted taxonomies have taken on new importance on the web; XML has upgraded the visibility of metadata.
Having the skills to create taxonomies and metadata will serve you well. Most people don’t have the instinctual skills to create information organization structures that are useful or the practical knowledge and experience to be confident in the structures they create. Understanding how taxonomies and metadata feed into user interfaces allows you to recommend good designs that improve findability.

Technical writers, content strategists, other writers, business analysts, requirements analysts, information scientists, information architects, information designers, etc., are trained to organize knowledge and are perfectly positioned to help people build new, non-traditional knowledge structures.

Practical Observations
As an information architect, I work with companies who are struggling with information organization. They recognize the need to put their information into a content management system (CMS) to ensure digital information or digital surrogates for physical objects can be found. As a consultant, companies hire me to help build metadata and taxonomy structures.

Not only am I hired for a third-party, outside view, but also because these skills have not been kept in-house. Historically, companies have seen information structures grow organically according to idiosyncratic tastes. Employees create structures that are useful to themselves, but they don’t have an understanding or the research to make a structure that fits for a larger population. These structures are not ecumenical or scalable.

I’ve also observed that people who do have a naturally good grasp on information organization rarely have confidence in their ideas. I've been thinking lately about how people in North America may often be taught how to use classification structures, the prime example being the Dewey Decimal Classification while in grade school, but aren’t taught about the fundamentals of information organization. We know how to use the system, but we don’t know why the system is structured and organized the way it is.

Just like different library classification systems, each CMS needs a different information organization system because it is based on the company’s domain and the users in that company. The technology the company is using is different too, so the way the taxonomy and metadata are implemented can vary. We can create taxonomies, but companies need to be educated on how to use a taxonomy and metadata, how to build a user interface that allows employees to find information, and how to manage the taxonomy and metadata over time.

How You Can Learn About Taxonomies and Metadata and Findability
Last year I wrote a paper about faceted classification and rounded up a bunch of resources. There are a lot of them out there, but here are a few of the freely available ones:

A useful how-to article:
How to make a faceted classification and put it on the web: http://www.miskatonic.org/library/facet-web-howto.html

Interesting background on the Art and Architecture Thesaurus:
Getty Trust “About the AAT” from http://www.getty.edu/research/conducting_research/vocabularies/aat/about.html

For an example of a thesaurus: Getty Trust Art & architecture thesaurus online
http://www.getty.edu/research/conducting_research/vocabularies/aat/

One of my favourites:
National Information Standards Organization. (2005). ANSI/NISO Z39.19: Guidelines for the construction, format, and management of monolingual thesauri http://www.niso.org/kst/reports/standards/

A useful explanation of how to make a faceted classification:
A simplified model for facet analysis: Ranganathan 101 http://iainstitute.org/en/learn/research/a_simplified_model_for_facet_analysis.php

W3C. SKOS.
http://www.w3.org/2004/02/skos/

Findability

While we can create taxonomy structures and tag digital content with metadata, all this classification doesn’t help if users can’t find the information. Findability is part of the taxonomy and metadata arena where we will be able to use our understanding of information seeking and retrieval. Morville defines “findability” as,

“a. The quality of being locatable or navigable, b. The degree to which a particular object is easy to discover or locate. c. The degree to which a system or environment supports navigation and retrieval” (Ambient Findability, 2005, p. 4)"
To increase findability, we can advise on and design interfaces for digital environments. Lately I've started realizing how important it is to recognize that users of these interfaces will not be familiar with or understand Boolean searching and will most likely be more familiar with full text search (or Google or Bing). While Google and Bing might be easy to use, Boolean searching can be more powerful.

It is extremely important to bridge the gap between a single search box and complex search parameters to allow inexperienced users to find precise, appropriate information. We can also design and manage metadata and taxonomies to ensure users can continue to find information and that systems support navigation and retrieval.

___________________________________________________________________


About the Author 
 

Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis,    she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.
Read all posts by Theresa.

Saturday, January 21, 2012

Designing content modules

In my last post, I talked about the "why" and "how" of using content modules to improve efficiency and user experience. In this post, I'll talk about some of the specific considerations in designing content modules. 

Content Module Categories

It's important to think about content modules as a whole, and not to use them for a bunch of one-off messages. Think about the type of information that you want to convey through content modules, and then categorize them. For example, in a recent project that I worked on with Theresa Putkey for Rocky View County in Alberta we decided to use these categories:

  • Alerts
  • Events/Meetings
  • Profiles
  • News
  • Related Topics
  • Contact
  • Application CTA
  • Survey
  • Interesting Facts

Categorizing content modules is extremely important for a number of reasons. Categories are a cornerstone of developing an effective taxonomy, which is they only way to automate updates of contextually relevant content. They're also important to ensure that similar types of information are presented consistently.

Content Module Types

Once you've got your key categories, you can break them down further into content types. These represent the different common types of information that you'll present in each category. You really need to have a strong understanding of your content at this point. Using the examples from the Rocky View County project, here are two of their categories broken down into standard content types:

  • Alerts:
    • Fire bans
    • Weather warnings
    • Road closures
  • Events/Meetings:
    • Basic statistics and link
    • Statistics with brief description and link
    • List of upcoming events/meetings and links

Defining content modules to this level helps to keep them focused and consistent and prevents a reactive approach to using them to publish any small bits of content that don't fit anywhere else. It also really helps writers to have a template to follow so they can quickly and easily write content that works for each type of content module.

Content Module Priorities

Depending on your website, you may want to assign each category of module with a different priority so that your CMS can pull one type of content module in preference to another. In the examples listed above, the Alert modules were the only content module given a priority one. This meant that in the spots that we wanted Alerts to appear, they would take precedence over any other content modules if they were available. If there were not, then that spot would be filled by a priority two module that met other specifications required of that spot.

Content Module Design

Once you know the type of content you'll be working with in each module, you need to define design requirements. Content modules should be designed to stand out on the page, but not compete against each other for user attention. “Alert” modules should be the most prominent element on any page. Strong CTA's should also be very prominent and obvious. All content modules should follow a consistent visual schema, with each type of content module having its own consistent structure and design. 

Some of the design decisions you'll need to consider and standardize include:
  • Visual design
  • Size and dimensions
  • Text and font size
  • Headings and phrasing
  • Information design
  • Number of characters or words per text element
  • Use of photos and/or graphics

Visual design aside, the best way to figure out these design issues is to draft some copy for a number of each type of module and get a sense of the "norm".  Then you can develop sample copy for each content module that can be used to inform the visual design and content guidelines. That way you can be sure that the design requirements actually support the content and not the other way around.

Below are two examples of different types of content modules in the Events category:

Looking at these examples, you can see how a visual designer could get a good understanding of the type and scope of content that he's designing for, and how you could easily create templates and guidelines to help writers develop consistent content across similar content modules. 

Be sure to include content modules in your writer's style guide, and include specifications for each content module type. For example, one type of content module may consist of a heading, brief description, and a descriptive link to the main topic page. You can also specify if there are any constraints such as character limitations, phrasing preferences, or tone of voice variations. 

What other ideas do you have for working with content modules? I'd love to hear other stories about what has worked well for you, or what challenges you've encountered. 

And I extend a huge "Thank You" to the Rocky View team for allowing us to reference their project work and examples in this post. 

Monday, January 9, 2012

Using Content Modules to Improve Efficiency and User Experience

What Are Content Modules?

Content modules are small chunks of content that can be placed on standard web pages, typically in the right side-bar area or at the bottom of the page. Each module contains content that can be automatically (or manually) updated or changed based on certain criteria. Some types of pages, such as a home or landing pages, can be built almost entirely by using content modules as building blocks.

Why Use Content Modules? 

The number one reason to use content modules is to provide consistent, up-to-date, relevant information across a website without having to manually update each and every page. If you build a home or landing page by using content module building blocks, the primary page content can be automatically updated to make sure that it's always fresh. On most other types of pages, content modules provide secondary, or supporting, content. Using content modules based on a clear taxonomy and specific criteria is the only efficient way to provide dynamically updated content designed to create a specific user experience across an entire website.  

Through content modules, you can create an information path for users to follow that is changeable and outside of the standard navigation. Content modules provide visual distinction and consistency to specific types of information (such as call-to-actions, article excerpts, alerts, etc) and enables you to easily update information throughout the site. If a contact number changes, simply update the information in your content management system (CMS) and all content modules used in the website that refer to that contact number will automatically update. 

Consistency between similar types of information helps users to accurately predict and find information on any page in your site. Content modules are also a great way to give your users more than they came for. If you know that people visit a specific page on your site to learn about something, use content modules to provide the next steps in learning or taking action. Correctly anticipating what your users want or need next, and providing an opportunity to proceed, goes a long way in creating a positive user experience. Content modules can keep your users engaged, on your site, and pleasantly surprised.

The specific purpose of the content modules will depend on your overall content, user, and business goals as well as on the capabilities of your CMS. Here are some ways that you can use content modules:
  • Time-sensitive themes or campaigns. In many websites, you have huge areas of static, never-changing page copy and then a blog area that is frequently updated with new content. There is often very little interplay between these areas and, editorially, there is no connection. Using content modules allows you to unify your entire website, not only by promoting your blog posts throughout your website, but also by presenting a common theme or perspective for a period of time. For instance, you may want to showcase your in-depth knowledge of your industry by sprinkling interesting and relevant facts and informational tidbits throughout your site. Or you could profile people who have inspired you or your customers (or of course you can profile your staff and your customers). You may want to highlight seasonal information or advice, or raise awareness of a specific current affair that's relevant to your business and your customers.

    To create themes you need to think like a magazine editor. Themes are determined through a strong understanding of customer interest and business strategy and are defined in advance to give content contributors an opportunity to develop relevant content. Using themes helps to prevent a "mish-mash" approach to content that often ends up just creating "noise" where every message competes with each other, rather than demonstrating a unified voice that conveys a strong message.

    Here's an easy way to think about themes: In reality, your website is a mosaic of messages. Every page, every piece of content, has a distinctly different message. Content modules are small content bites that also each have their own message. Frequently, different stakeholders are each given their content "real estate" and they're each invested in getting their message across. The result is a mosaic of messages that creates no real sense of unity or clarity. By introducing themes through content modules you're able create a layer of information on top of your static page content that combines to create a clear message (or picture) that reflects your organization. When you change the theme, the core content on the site remains the same, but the modules send a completely different message that reflects your corporate values in a new way. These changing and distinct messages are much more apparent and memorable to users than consistently presenting many competing messages.

  • Call-to-Actions. One of the most common uses of content modules is to provide standardized call-to-actions (CTAs). For each type of CTA that you need, simply develop it once and plug it in wherever it's relevant. This results in a much more efficient process and consistent set of CTAs. These can include contact information, "buy" or "apply now" messages, forms of any sort, surveys, downloads, links to more information... anything that causes the customer to take further action

  • Contextual richness. Every module should be contextually tied to the content on the page where it appears. If it's unrelated, it doesn't belong. For example, you would not place a content module with an article excerpt about weed control on a page about recycling. Similarly, you would not put an “Apply Now” call-to-action on a page that had no associated application. A strong taxonomy is essential to provide this type of contextually relevant content.
As you design your web pages and content, design a standard set of content modules that support your communication strategy and user goals. Then, pick and choose which content modules to include on which pages and assign specifications for updating the content based on a taxonomy. For instance, you may set the content modules to check for new content once a day, once a week, or seasonally at pre-defined times. And you can specify that specific modules only update if the new content contains associated tags. 


Next week, I'll discuss in more detail how to design effective content modules and the common categories and content module types. In the meantime, what are some other ways that content modules are used?




Wednesday, August 31, 2011

Using Wireframes to Communicate Information Architecture

Kathy's note: This is the eighth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
___________________________________________________________________

What are wireframes?
As mentioned in my previous Site Maps post, wireframes are akin to a blueprint for a house. For each major page on a website, a wireframe tells you which box should go where, what content should go in the box. You can easily find examples of wireframes by searching for “wireframes images.”

What are they good for?
Since an information architect (normally) has a deep understanding of how users are trying to find information, a wireframe can show others how the information should be laid out so users can best access this information. There are a number of benefits of wireframes, including:
  • Showing layout: for the major pages on the site, a wireframe can act as a template for how the information, images, videos, and forms should be organized on a page. It can also show you how the global and local navigation will appear and behave on a site.
  • Verifying persona needs: With your personas in hand, you can make sure the wireframes represent the most important information needs of the users. For example, a user might need to see a daily financial update announcement instead of the weather. You can ensure this update is in the appropriate wireframe.
  • Fulfilling user scenarios: Scenarios represent what people are doing in “real life” and how the site helps them fulfill their “real life” needs. Wireframes can make sure all the scenarios are satisified. Although the whole scenario doesn’t need to be represented in the wireframes, you can represent the whole scenario or you can represent the more complex parts of the scenario. Ultimate, the wireframe helps you discuss the scenario and see if anything is missing in your design.
  • Verifying requirements: While creating the wireframes, you can refer to the requirements list, then clarify the meaning of any requirements. In the wireframes themselves, you can note which box fulfills which requirement.
How many do you need?
With a site, you don’t need to represent every page in the site map. You only represent the major pages that are significantly different from each other. For example, you might have a content page, a home page, a secondary landing page. If you have any forms or workflows, you can represent these as well. How many you need depends on how many significantly different pages you have and any processes that need to be represented.

What are some challenges?
While wireframes do help communicate the information layout, I’ve run into several challenges with them:
  • Requirements elicitation: Invariably, wireframes always generate more ideas. Instead of being a confirmation of the existing requirements, once people see things on the screen or page, they think of more ideas. This is often called “scope creep.” Often, people don’t have a clear understanding of how detailed the requirements, personas and scenarios need to be and end up fleshing out this detail in the wireframes phase. It happens in every project - I haven’t found a way to avoid it. There should be room for creativity and interpretation in wireframes, but new ideas always elicit a response!
  • More abstract, less concrete: Unlike visual design, wireframes are more abstract. While I use Axure for wireframes and can make them somewhat interactive, people relate to visual design more than they do to the wireframes. Visual design not only adds colour to a design, but it also pulls the eye to certain aspects of the page, gives a better “feel” for the page, and evokes a response based on colour. People respond so much better to visual design, sorry to say. They can agree to a wireframe’s functionality, but once they see the visual design, they get excited. I like to think that the wireframe’s work allows the visual designer to make splendid design.
Conclusion
Wireframes help communicate the information layout for a site. They help the visual designer produce a great design and they speed the development process. While there are some downfalls to them, such as being more abstract and sometimes being used too heavily for requirements elicitation, they do help with agreement on site layout and design.

___________________________________________________________________


About the Author 
 

Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis,    she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.
Read all posts by Theresa.

Thursday, July 28, 2011

Site maps

Kathy's note: This is the seventh installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
___________________________________________________________________

Site maps are something I’ve been struggling with lately. With content dynamically generated, what’s the best way to do a site map? Perhaps it’s best to back up for a minute, explain what site maps are, and then explain my quandary.


What are site maps?
Site maps show the structure of a website. While wireframes are called the “blueprint” of the UX world, I’d say that a site map is more like the electrical wiring diagram or plumbing diagram. These diagrams show you the path that the wiring or plumbing takes through the house. They make sure there’s no wasted materials, no pipes leading to dead ends, no electrical wires not contained in junction boxes.

The site map is used for structuring the pages on the site: it groups the pages into some logical order (based on the user needs or personas for the website). To create a site map, you’ll need to do a content audit or content inventory, deciding on what you want to keep and what needs to be removed. Site map creation can be driven by card sorting and you can test your site map through task testing.

Site maps can be done by either information architects or content strategists. As I see the division:
  • For an IA, the site map is more important for structuring the site properly and creating a representative number of wireframes so the content on the site can be accommodated.
  • For the content strategist, the site map is more important for creating and editing content.
For examples of site maps, do a search for site map images. You’ll find a number of examples.

What are they good for?
Site maps shows you links between pages. The highest level is normally used for the global navigation while the secondary level and tertiary level can be used as sub-navigation items and page links, respectively.

By using a site map, you agree to the site structure before you build it. You know what pages you have and the stakeholders, project team and developers know what should go where. Based on the site map, during the development phase, the content strategist can start creating or editing content to fit onto the pages and continue to revise the site map should it need further modification.

Quandaries
Some issues I’ve experienced in the past include sites that are dynamically created. For example, a page can be created based on a taxonomy. If you take Epicurious.com, they have an infinite number of pages driven from their faceted classification. In this case, a site map cannot express the structure of the site. The wireframes must hold all the information necessary to display information and they must be standardized enough to accommodate the faceted classification. Explaining and agreeing to this structure and functionality with a team that doesn’t understand how faceted classification and the technology works can be quite difficult. I frequently encounter clients who don’t understand the technology driving the websites. While I do explain it to them, there’s always someone else who comes along in the project who does not understand the technology. It’s constant give-and-take between education and progress. You can’t progress and make decisions if clients don’t know how something will work. It’s a constant source of vexation for me because I always have to judge how much someone knows, sometimes I get it wrong. I’m always thinking about how to improve my communication skills so the customer gets what he/she needs out of my work.

Another issue I’ve encountered is what I would call “a site in transition.” For example, some companies need to move their intranet to a new platform, but intranets sites fall into the decentralized control area. Sometimes there are too many sites to move them all at the same time. The site map for the first version of the new intranet might be very small (showing the pages that belong in the first version of the new intranet). But the navigation may still need to lead to these decentralized sites. Not all the sites are carried to the new platform, are on the old platform, look different than the new site. It’s best practice to link navigation to pages within a site and the idea of having landing pages with links has been thrown out. Sometimes the navigation must link to sites that look different. This will cause the user to feel disoriented. It’s also quite difficult to denote these different links within a site map. What pages are on the site? What pages are only in the navigation but not on the site? To solve this problem, I created a site map and a “navigation map,” if you will. 

___________________________________________________________________

About the Author
 

Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis, she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.


Read all posts by Theresa.

Wednesday, June 29, 2011

Personas

Kathy's note: This is the sixth installment in a 12-part series by Theresa Putkey that discusses the intersection of content strategy and user-centred design. Read all posts by Theresa.
___________________________________________________________________

Creating user personas is a fantastic way to get stakeholders to focus during the design. You’re not just designing for people who like... well, everything... you’re designing for that particular someone who likes to do something particular. I always say, “Ask for what you want and you’ll get it. If you don’t ask, people won’t know what you want.” It’s the same with designing software: if a UX professional doesn’t know what the users want, then they don’t know what are they supposed to design.

For content strategists, personas inform the content needs on the site. You can use personas to tell you what things users are looking for, and you can ensure each content need is met on the applicable pages. You can also use the existing personas and fill them out more to meet your content strategy needs.

What is a persona?

A persona is a single, fictitious person who represents the needs and wants of many people. This representation has been created by information gathered in the user interviews. Personas are a great way to focus the design and to resolve design disputes. The team can focus on concrete people and, when questions arise, they can be asked and answered based on the persona’s needs.

Personals are Built from User Interviews

Personas are built based on user interviews. Whether with a new or existing product, you’ll need to identify different types of people who may use the website or software, then line up interviews with those types of people. If you’re just starting off on the design and interviews, your questions might tend to be more general. If you’re further into the design work, your questions might be more specific and get into more process.

Going Without User Interviews

I’ve worked on “user centred design” projects where user interviews were not allowed. It was the second in a series of projects, each building on the last. For the first project, we had personas, but they were specific to that specific project. For the second project, there was a complete turnover in the team (which also meant educating the new people about UX), and it was determined that the personas for the first project would suffice for the second and user interviews would not be done.

As a UX professional, it was tough to hear that the work I was recommending wasn’t valuable, but it also meant that the second project would lack focus. The user interviews wouldn’t be done and the personas wouldn’t be updated. How do we deal with this refusal?

Here’s a great interview for understanding personas, “Making Personas Work for Your Website: An Interview with Steve Mulder.”

I think personas not based on actual user research are absolutely better than no personas at all. A lot of customer and user knowledge already exists in many organizations, and by looking at the sales, marketing, product, customer support, and tech support perspectives, you can bring all these existing bits of knowledge together into personas without talking to any actual end user.

In this case, turn around the refusal of no user interviews by asking for second-hand information. Companies might feel more comfortable giving this information, since it may be readily available.

In a content strategy project, you may not be able to do more user interviews if the business analyst has already done stakeholder interviews and the UX professional has already done user interviews. In this case, interview the business analyst and UX professional, then look at the secondary sources yourself. Fill out the personas as needed.

How Does a Persona Help Us Focus?

In this interview, Mulder communicates the purpose of personas:

The main thing a persona allows designs teams to do is to think outside themselves and really get an understanding of who it is they are designing for. When design teams build a persona, they write a story about a character that represents a whole type of user that is fundamentally different from themselves. They put themselves in the shoes of their users and think about how the persona would interact with a web site or design.

Have you ever been in a meeting where someone in the room says, “I don’t like this aspect of the design. I mean, my mom doesn’t use this kind of thing, she uses this other thing, so I don’t think this aspect is important.” That’s a great way to take the design off-track. Personas help the team focus on the persona using the product. The conversation can be directed away from that person’s mom and onto the persona with some form of this sentence, “I understand your point, but I want to make sure we’re designing for the personas...”

___________________________________________________________________

About the Author
 

Theresa Putkey is an information architect consultant living in Vancouver, BC. With a Bachelor of Arts degree from the University of California, Davis, she focuses on integrating user needs into website and software design projects. She's currently doing her online Masters of Library and Information Science at San Jose State University. You can find out more about Theresa at www.keypointe.ca, or follow her on twitter @tputkey.


Read all posts by Theresa.