Category Archives: Information Architecture

Why Invest in Research?

Research is a powerful business tool. Professionals throughout all organizational levels know this to be true, yet sometimes skip it. Common reasons include time, cost and a belief that the factors for success are already known. While I wouldn’t dismiss any of these reasons outright, my experience tells me they’re often myths. Research needn’t be a speed bump, budget buster, distraction or inconvenience. Rather, it’s a practice and mindset that comes with the following positive benefits.

Make better decisions
Whatever your skill set and role, researchers collectively bring strategic thinking, tactical skills, best practices and intuition to the table. Research brings another voice to the conversation — your target audience’s — that is objective, free of organizational bias and able to surface ideas that may otherwise not be seen or considered. These outside perspectives can profoundly change how the world is understood and, therefore, how it needs to be approached.

Reduce risk
Research allows project teams to better pinpoint where attention, time and money are best spent. A team that has a comprehensive understanding of problem(s) will also be a team of effective problem solvers. And while research does come with financial and timeline implications, it reduces or completely eliminates the greater costs incurred building problematic or failed products and services (not to mention the costs needed to fix them).

Fill knowledge gaps
Intuition, experience and personal observations get teams far. Research, in combination, takes them farther. It brings more voices to bear, more subtlety and nuance to what may otherwise be broad generalizations, and pointers when the path ahead is unclear. It also helps surface biases and cultural norms that may negatively impact the project’s success.

Improve organizational dynamics
Research can provide a framework to align people and departments through collaboration and a shared understanding of customers, their problems, and how well the organization is positioned to serve customers and address their problems. Research can rally a team by injecting it with purpose and inspiration.

Speed development
Some perceive research as slowing down a team’s progress. If speed to market is the goal, then this perception may be correct. But if the goal is to build the right product or service for the right people and for the right reasons, then research actually speeds the development process. Teams will ultimately reach success quicker with research than without it and will do so with fewer public stumbles.

If space for research is included in the design and development processes, teams gain an ability to effectively manage and apply their time, money and attention. The results are more likely to be exceptional products and services that customers are willing and happy to buy and use.

Book Notes: The Inmates Are Running the Asylum

  • Cognitive friction: the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes.
  • “#1 goal of all computer users is to not feel stupid.”
  • Larry Keeley’s three qualities for high tech products:
    1. Capability: what can be done? Supplied by technologists.
    2. Viability: what can we sell? Supplied by business people.
    3. Desirability: what do people want? Supplied by designers.
  • Need and desire are not the same. Desire leads to loyalty.
  • Designing for a minority of users leads to success rather than attempting to accommodate all users. Specificity is key. Find a common denominator and work off of it.
  • Personas are a key to successfully designing a product/service. They must be specific more so than accurate in order for development not to get carried away with edge cases. Don’t average them because that saps the power of specificity. Specificity directs what should and shouldn’t be done in the system. Personas need to reflect users, not buyers or other characters that are close to the product, but not actual users of it.
  • Goals and tasks are not he same. Goals are stable while tasks can change with circumstances yet still achieve the goal.
  • After personas are created and goals outlined, create scenarios. Scenarios should outline user tasks (as uncovered by research and user testing) that achieve goals. You want to eliminate steps to complete tasks and make goal achievement as easy as possible.
  • Two kinds of scenarios: daily use and necessary use. Daily use are most useful and important. They’re the main actions a user performs and also the most frequent. One or two is typical- more than 3 is rare. Users will go from newbie to shortcuts to customization quickly. Necessary use must be performed, but not frequently. Typically more necessary scenarios than daily. Necessary uses don’t require shortcuts or customization since they’re too infrequent for the user. As such, they can safely be less thought through from an interaction perspective.
  • Edge cases can safely be ignored from an interaction standpoint. Include the necessary things needed to do the jobs, but don’t spend much time on them. Edge cases are the place where time and budget can be saved.
  • Less interface and design is better for the end user. An interaction designer’s fingerprints should be nonexistent in the best cases.
  • Inflecting the interface: controls for daily use scenarios should be easily found and used. All other controls for necessary and edge cases can be move to secondary locations.
  • Perpetual intermediaries: the idea that most people will be intermediate level users of a product/service. Beginners are important but people grow out of it quickly. Experts are rare.
  • Ensure vocabulary doesn’t get in the way. Semantics matter. Define things up front so everyone is talking about the same things.
  • Conceptual integrity: from Frederick Brooks, meaning that a single minded vision of a program is the most important ingredient to success.
  • Don’t become a customer driven company doing whatever your customers say to do. Instead, become a vision driven company that allows itself to be informed by customers, but not dictated to by them. Take a longer view of the business, take responsibility, take time and take control.
  • “The central recommendation of this book is that the interaction designer should be the ultimate owner of product quality.

Gerry McGovern & Audience Based Navigation

Gerry McGovern nails it again. In his latest post, he laments audience based navigation. Not always, mind you, but often. One of McGovern’s main examples is from the educational world where audience based navigation is rampant and, in my humble opinion, replete with the problems he cites. The main thing to ensure is mutual exclusivity among audience segments. Otherwise, people don’t know where to go if they find that they fall into multiple categories. I’ve covered this topic in the past and I’m glad McGovern has given it airtime. It’s long overdue for higher ed to, at minimum, treat audience based navigation as a secondary means of exploring a site.

Thoughts on Higher Ed in the Mobile Space

Mobile is on everyone’s mind these days. Many schools have already launched some kind of iteration to meet and compete in the mobile space. But I’m finding the early versions lacking. That’s not meant as a criticism though. All early attempts will be rough around the edges as novelty wears off and best practices begin to form. With that in mind, here are a few thoughts on where things stand.

Don’t conflate audience segments with use cases

I see this all the time in higher ed. A mobile site offers links to content aimed at prospects and also throws in “mobile” functionality like maps and directions. Who are the mobile tools intended for? Prospects are not in need of maps or directions- they’re not on campus. Yes, they are on campus during a visit, but with decision making processes lasting months if not  years, it amounts to a rare occurrence (and you shouldn’t design interfaces for the exception to the rule- offer access to the functionality, but don’t make it a focus). Like any other project, you need to settle on who you’re building your project for OR for what purpose (i.e. use case), but not both. It doesn’t make sense to offer tools that are really meant to fulfill particular use cases alongside content meant to fulfill audience segment needs (unless they’re the same thing in which case we’re only talking semantics). Divide an conquer. Create a single .edu experience with focus and intent. Don’t get mesmerized by “mobile” functionality unless it supports the bigger plan.

Use cases might point you towards an app

If research suggests that maps or other kinds of functionality are needed, don’t be so quick to throw them in alongside the content intended for an audience segment. Instead, be ruthless in your curation and editing of the interface and user flow. Let the focus of your strategy be your guide and allow it to simplify your decisions. If your intent is to primarily reach prospects via mobile, then do so. Take the research finding that don’t fit well (like maps) and set them aside. Once you have the segment’s experience honed, then take all the leftover stuff and ask why it was left out. I think in the case of maps, it will be left out because it’s not directed toward prospects. It’s really intended for an on-campus use case which might mean it’s relevant to a prospect when visiting, but more apt for the people who are always on campus- students, employees. The use case cuts across traditional audiences and presents an opportunity to create a second experience, this time centered around the I’m-on-campus use case.

That use case might best be addressed through a dedicated app. Why? Because mobile doesn’t necessarily mean walking on campus. You can just as easily be sitting at home surfing on your phone. This fact suggests that the mobile site should actually be the same as the desktop site, or, in other words, there should only be one universal .edu experience whether it is seen on a phone, an iPad, a desktop or anything else. This is the responsive web design idea that’s gaining so much attention (and deservedly so). So, if all devices point to the same experience and that experience is determined to primarily be centered around prospects, then where should this use case approach apply? I say an app. It can include links to the intranet, Blackboard (or whichever LMS your institution uses), shuttle service, dining hall push notifications, etc.- anything that matches the use case.

Quick examples

Harvard has done an excellent job of providing focus to their mobile experience. You can tell by the content offered that it’s squarely directed to on-campus use. There is nothing extraneous to that purpose which brings it focus, clarity and cohesiveness. Their website, on the other hand, is squarely directed at prospects. There are ways to get to content that isn’t specifically geared to prospects, but those access points are secondary to the main show which is for prospects. Roanoke’s mobile site, in contrast, has less focus. You might think they follow an on-campus use case strategy too, but then you see that they include links for admissions and majors- content meant for prospects. They also have a link labelled alumni which is yet another audience segment, this time literally called out. In contrast to Harvard, Roanoke’s palette of content is much less coherent burdening the user to figure out whether or not the site is of use to them or not. Placement of the links is also a problem. Josh Clark teaches us that the audience specific links are located at the most accessible link target areas of the screen. That further adds usability confusion to the site.

Harvard's mobile site prioritizes the needs of people on campus.Harvard's site is geared toward prospective students.Roanoke's mobile site mashes together content for various audience groups and does so in a way that isn't prioritized.