Web Development Strategy, Part II: Organization Drives Results
All companies describe themselves as customer-centric, yet a vast majority of websites are constructed without customer input, data, or representation. More often, websites are redesigned to outdo the competition or to resemble the look of a trendy website – not to fix or enhance their website’s user experience. As a result, new website redesigns are mostly cosmetic and skin-deep, (which could be as effective as putting lipstick on a pig). Information architecture, content structure, strategy, and the like are rarely considered in these types of redesign engagements.
True customer-centric companies redesign their websites from the inside out and the bottom up, using empathy, direct and inferred insights about their existing and potential customers. Time is spent trying to understand their target segment’s world by walking a mile in their shoes, recreating, thinking through, or evaluating common situations through their eyes. This initial phase, as discussed in Part I, uses tools such as Persona Profiles, Journey Maps, and Task Analysis. In this initial phase, all efforts are in establishing a context for your website within their lives to establish some level of appreciation for the circumstances they face. This step is in recognition that a buyer’s decision is influenced as much by what happens online as it does offline so it examines all potential touchpoints that impact motivations, choices, and decisions.
This post will focus on a visitor’s expectations and reactions based on a website’s content (including copywriting, images, videos, graphics) and how that content is organized, perceived, and consumed. Just as Persona Profiles, Journey Maps, and Task Analysis are intertwined, so are the upcoming set of tools and techniques – card sorting and information architecture. While presented in a linear fashion, each step builds on the next, and as connections are made, previous objectives, strategies, and plans are revisited, refined, or even replaced.
Card Sorting picks up where Task Analysis leaves off. In Task Analysis, the objective was to identify what tasks or goals a visitor was trying to complete online. However, it does not address the role content plays in the process. This is where card sorting comes in. Card Sorting is a collaborative effort between the website team and target audience to identify: 1. What content is needed. 2. How the content should be categorized. 3. How the categories should be labeled. Card sorting can be a quick, simple, and pragmatic means of finding meaningful direction. As important as the first three objectives are, the fourth objective is the most valuable. 4. Determining why. Why did they make the choices they made? This insight is so powerful that it could reframe the way the website team makes a myriad of other decisions in design and development. With a new perspective comes a correction of inaccurate assumptions and beliefs which have a rippling and lasting effect. Using nothing more than paper index cards (with each index card representing a website page) you can understand how your target segment thinks and feels about select topics covered in your website. The process follows two tracks, with each track answering one key question:
Scenario A. Which index cards should be grouped together?
Scenario B. What to label each group of index cards?
In scenario A, subjects are asked to group a series of index cards into homogeneous groups based on their relationship to each other. Index cards are labeled with a list of topics based on findings from the Task Analysis conducted in Phase 1. As subjects decide on which index card is to go with what group, they are asked to think out loud so the website team can get a better sense of their rationalization and justification process. In scenario B, a different group of subjects is asked to look through each pile created by the previous group and to name the pile based on its content.
In combination, findings to these approaches help determine what content is missing, what is considered important, and what labels would resonate best.
Information Architecture. The website’s Information Architecture determines how smoothly and effortlessly visitors maneuver through your site. Information Architecture serves as the skeletal structure and categorization of website pages and elements within each page. The Information Architecture will help determine what content should be created for each page, and how each page should relate to each other for optimal flow. This, in turn, will help users navigate through the site more fluidly, seeing what they expect, and finding what they want. At this stage, the concentration focuses on a visitor’s behavior and thought process while maneuvering through your website.
Just as the Task Analysis technique feeds into Card Sorting, the results of the Card Sorting exercise feeds into the website’s Information Architecture. Each pile of index cards represents global navigation and its corresponding sub navigations. While these results may not reflect the website’s final Information Structure, it does become the working model that is tweaked for the balance of the project based on new information, the connection of new and old information, or for some other substantiated reason.
When the thought of as a cluster, Task Analysis, Card Sorting, and Information Architecture relates to a visitor’s expectations and how they navigate through a website.
Internally, a Requirements Brief is created to provide team members with the scope of the project and requirements based on findings up to this point. A Requirements Brief includes project objectives, marketing strategy, messaging, details about the target audience, feature topics, and website functionality, the impression you want to give your visitors, and the experience you want them to have when on your website. This document will define the project scope, priorities, timelines, who owns each stage of the process, and includes a checklist to verify all commitments have been met and nothing is missed.
The Requirements Brief is often requested at the start of a project, which is perfect if exact requirements are known. Requirement documentation is often the first step in a customary waterfall type methodology, however, a requirement brief can’t be created without the data you derive from your research and development of the site’s anatomy. Any document built without that information is built in a vacuum of assumptions, which often leads to inaccurate expectations from the outset.
In reality, requirements change as more is known, realized, and tested, which means that your requirements brief will change and evolve as the process continues. Even if you create it before you do your base research, it’s important to inform all team members that in the early stages, a requirements brief is malleable, and will be revisited and revised as new revelations are made. That’s why evolutionary, iterative, and incremental steps of design are encouraged, to test each phase, learn from the results and revise as necessary.
With the completion of the Requirements Document, page elements are ready to be assembled in the form of Mockups and Wireframes, Page Designs, and Pre-totypes which are all topics of our next blog.