Site Map Do's and Don'ts

It may come as a shock to hear this, but, unless your client is a developer or a content strategist, site maps are rarely valuable documents to show them. Why then, is the site map continually socialized to the wrong stakeholders, and incorrectly positioned as a dependency for other Design deliverables (Which we know will result in the site map becoming a road block for the rest of the Design process)?

Site maps confuse and distract certain stakeholders, because:

• Site maps are abstract, system-level documents - They document a system, but are not visually representative of that system at an interface level. Consequently, they take a certain level of extrapolation to understand how the hierarchy works, at a page, or screen, level.
• Site maps can appear dense or complex - Site maps take time to study and understand. You'll likely have about an hour, max, to present your site architecture to your client. How on Earth are you going to convey that level of complexity and detail, in that amount of time, especially to a "C-Level" executive? When designing a site map, think about simplifying the diagram, or presenting multiple views of the map, "peeling away the layers of the onion," to gradually expose more detail.
• Site map "approval" is typically considered a dependency for the start of the Design process - Yeah. It's weird to think that everyone on the team expects the Information Architect or User Experience Designer to completely nail the entire taxonomy and flow of an application, without even having sketched a screen or two. Word of advice...don't hold up Design, while awaiting site map approvals.
• Site maps are NOT good for presentation of a UX vision - There are more effective visualizations, infographics, and high-level diagrams that can be utilized to convey the User Experience Vision, or Strategy, for an application, to a marketing executive. The interconnection of pages or screens isn't a visualization of a strategy. It is a visualization of a content hierarchy.

What are site maps good for, then, if they aren't great tools to convey the high-level vision for an application?

• Site maps are good for development and implementation - Site maps are invaluable documents to illustrate to developers, how to construct the hierarchy of pages or screens in the application. It is a document that is generally delivered to a client or team of developers, prior to the screen level user interface designs. That being said, I strongly recommend that site maps are not considered "FINAL," until the very end of the Design process. There. I said it!
• Site maps are good for content development and categorization - Because site maps represent the "outline" of the content, they need to convey, in some cases, the flow of the narrative to the end-user. This is especially true when designing the information architecture of a marketing web site or application. Content strategists and developers will want to map their copy and content to the site map sections and sub-sections.
• Site maps are good for SEO planning - The underlying framework of a web site is extremely important, when planning for the search engine optimization of a web site. It is critical to understand the likely searches that consumers will perform to access the client's web site, and create an information architecture that will, at a primary level, satisfy likely searches. Thus, the site map becomes a communications tool amongst four parties:
• Information Architects/User Experience Designers
• Copywriters
• SEO planners
• Developers

Of course, old habits die hard. It will take a long time before agencies realize that they shouldn't, out of habit, shove the "site map" deliverable at the beginning of a project plan, and require the client "sign-off" on the document before the Design process begins. But, please don't force the client's CEO, or CMO, to sit through that presentation!

Jonathan Lupo - http://www.twitter.com/userexperience

The Proper Use of a Site Map

It may come as a shock to hear this, but, unless your client is a developer or a content strategist, site maps are rarely valuable documents to show them. Why then, is the site map continually socialized to the wrong stakeholders, and incorrectly positioned as a dependency for other Design deliverables (Which we know will result in the site map becoming a road block for the rest of the Design process)?

Site maps confuse and distract certain stakeholders, because:

• Site maps are abstract, system-level documents - They document a system, but are not visually representative of that system at an interface level. Consequently, they take a certain level of extrapolation to understand how the hierarchy works, at a page, or screen, level.
• Site maps can appear dense or complex - Site maps take time to study and understand. You'll likely have about an hour, max, to present your site architecture to your client. How on Earth are you going to convey that level of complexity and detail, in that amount of time, especially to a "C-Level" executive? When designing a site map, think about simplifying the diagram, or presenting multiple views of the map, "peeling away the layers of the onion," to gradually expose more detail.
• Site map "approval" is typically considered a dependency for the start of the Design process - Yeah. It's weird to think that everyone on the team expects the Information Architect or User Experience Designer to completely nail the entire taxonomy and flow of an application, without even having sketched a screen or two. Word of advice...don't hold up Design, while awaiting site map approvals.
• Site maps are NOT good for presentation of a UX vision - There are more effective visualizations, infographics, and high-level diagrams that can be utilized to convey the User Experience Vision, or Strategy, for an application, to a marketing executive. The interconnection of pages or screens isn't a visualization of a strategy. It is a visualization of a content hierarchy.

What are site maps good for, then, if they aren't great tools to convey the high-level vision for an application?

• Site maps are good for development and implementation - Site maps are invaluable documents to illustrate to developers, how to construct the hierarchy of pages or screens in the application. It is a document that is generally delivered to a client or team of developers, prior to the screen level user interface designs. That being said, I strongly recommend that site maps are not considered "FINAL," until the very end of the Design process. There. I said it!
• Site maps are good for content development and categorization - Because site maps represent the "outline" of the content, they need to convey, in some cases, the flow of the narrative to the end-user. This is especially true when designing the information architecture of a marketing web site or application. Content strategists and developers will want to map their copy and content to the site map sections and sub-sections.
• Site maps are good for SEO planning  - The underlying framework of a web site is extremely important, when planning for the search engine optimization of a web site. It is critical to understand the likely searches that consumers will perform to access the client's web site, and create an information architecture that will, at a primary level, satisfy likely searches. Thus, the site map becomes a communications tool amongst four parties:
• Information Architects/User Experience Designers
• Copywriters
• SEO planners
• Developers

Of course, old habits die hard. It will take a long time before agencies realize that they shouldn't, out of habit, shove the "site map" deliverable at the beginning of a project plan, and require the client "sign-off" on the document before the Design process begins. But, please don't force the client's CEO, or CMO, to sit through that presentation!

Jonathan Lupo - http://www.twitter.com/userexperience

Social Marketing: Reach Vs. Engagement

There seem to be two opposing sides on the topic of marketing through Social Media. Although I'm certainly no expert, and never claimed to be, I can say that the side whose platform is "get as many followers as you can," is probably less credible than the those who believe that success on Social is determined by how engaged your followers are with you, and with the content you push.

That being said, social media should be treated like any other marketing medium, and a balance needs to be struck between "Reach" and "Engagement." These are classic marketing objectives that are measureable, with metrics and indicators to allow for improvement over time.

Mobile UX Strategy - Web Site or App?

With the wide consumer adoption of smartphones and tablets, digital consulting firms are proposing mobile tactics as part of a larger digital strategy, to their clients, based on an understanding of their clients' business objectives, competitor landscape, and consumer needs. When proposing this strategy, consultants must decide whether it is more beneficial to their client's business, to develop a native, mobile application, or to build a mobile-optimized, web site.

Recent research seems to suggest that, in general, consumers prefer to engage with native mobile applications (due to their responsiveness, and because they are better able to leverage some of the nifty, user-interface capabilities of the mobile device). However, mobile-optimized web sites enable businesses to be accessible on a wider spectrum of form factors and devices.

The question is, since there are clear benefits to both tactics, how should a business decide which mobile tactic would best meet their specific needs?

The following are key considerations to help a business decide upon a mobile direction ( App vs. Mobile Web Site):

1. How well-known is the client's brand? There is a greater likelihood that consumers will seek and download an app from a well-known brand than a lesser-known brand, so, brands with less awareness are more reliant on app store placement, prominence, and promotion, to gain popularity with consumers. Since an app has a limited "promotional" window within an app store showcase, a lesser-known brand should consider entering the mobile space with a mobile-optimized web site. Why? The client probably already has a traditional web site that has gained a certain amount of organic search engine equity over the course of years. Consumers are more likely to look for services that the client offers, via mobile search, than directly searching for the brand, via app download.

2. What are key, mobile use cases, based on anticipated, consumer behavior? Are they "online" or "offline" use cases? One benefit to native applications, depending on their intended functionality, is that they can sometimes be useful in an "offline" situation. Mobile-optimized web sites, on the other hand, are always accessed via "the cloud," restricting their usage to "online" use cases. A key question a business should ask itself, is whether or not the application needs to function when end-users are offline. If so, a native application may be the way to go.

3. What is the "technographic profile" of the consumer base? The technographic profile of an end-user segment, describes the nature of the segment's likely adoption of relevant technology. An important consideration, when developing a mobile strategy targeted to this segment, is, obviously, whether or not the target segment is likely to adopt the application's intended mobile platform. If not, or if adoption will likely be spread across a wide variety of mobile platforms, the mobile strategy may lean in the direction of mobile-optimized web site, versus a platform-specific application.

4. Will the app functionality need to access data or capabilities native to the mobile device? As mentioned earlier, an application may be more useful, or engaging, if it leverages specific features of a smartphone or tablet, which cannot be accessed by a mobile-optimized web site. If this is the case, choosing to develop a native, mobile application, may make it easier for a client to take advantage of the cool features of the application's intended devices.

5. What is the budget for the mobile initiative? Developing a native, mobile application may be costly for clients with a limited budget (depending on the functionality of the application). Additionally, the native application may need to be redesigned, to be optimized for a variety of form factors, which, ultimately, increases costs. If a client only needs a simple, mobile presence, and wants to be accessible on a wide spectrum of mobile platforms, it may be a good idea to recommend a simple, mobile-optimized, web site.

6. How aggressive is the timeline for the initiative? Aggressive timelines may actually prevent a client from developing a native application, distributed via an "app store" like Apple's. Consultants must factor in the "app store approval process," when planning a mobile application's design, development, and deployment, timeline. If the application does not meet the standards of the app store (and Apple has very strict standards), there is a risk that an aggressive timeline may be blown.

7. Will there be an eCommerce, transactional component, to the mobile application? Currently, all purchases of digital media (music, movies, etc.) initiated via native iOS applications, must end up as iTunes transactions. That means that Apple gets a percentage of each sale initiated through a native iOS application. To avoid paying the fee, a business with redundant digital media products to those found on iTunes, should consider developing a mobile-optimized web site, as a consumer-facing storefront.

In short, the decision to build a native app, or develop a mobile-optimized web site, requires careful consideration. Consultants need to thoroughly examine a client's brand, business, and likely end-user behavior, before making this decision. Making the wrong decision could be costly, miss a window of opportunity, or result in an application that goes largely unnoticed by it's intended audience. As always, planning, through careful investigation of business objectives, as well as likely, end-user behavior, can prevent a failed mobile strategy.