- 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:
- Capability: what can be done? Supplied by technologists.
- Viability: what can we sell? Supplied by business people.
- 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 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.
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.
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.
If you search for our university on Google maps you’ll find a listing for a liquor store right in the middle of campus (which isn’t correct, of course). So, what’s a person to do? Report the problem to Google, right? Right. Well, good luck. I didn’t see an obvious way to submit an issue, so I went to the help link and did a search. I ended up a Google help article describing how to report a problem. Let’s count the problems with this process, shall we?
- Most obvious, is that there is no obvious way to report a problem when you’re in the maps area. It’s an outlier use case, I’ll grant you that, but still, it’s not carte blanche to hide it. The most logical place to go then is the help link.
- The help article has a “how do I report a problem” toggle. Perfect! This is exactly what I need. Wel,, hangon a second. It mentions a “report a problem” link, but fail to actually provide the link. They instead choose to talk about it. Hello? This is the web, right?
- Given the above oversight, I decide to open the “where can I find the report a problem link” toggle (which wouldn’t be necessary if they simple gave the link in question). It instructs to click “more” from the info window. What’s the window info, you ask? Who the hell knows? Figure it out for yourself.
- As I ponder what they might mean by info window, I see a “more” link in the top black bar- maybe that’s what they mean by the info window? Doesn’t seem like an info window, but OK, I’ll try it. Nope. That only shows all the various Google product links, no “report a problem” to be found there.
- OK, the info window must be within Google maps then. Ha! Silly me, of course! I should have looked in the maps area all along. User error, my bad. I go back to the problematic map and bingo, I spot the more link right there in the left sidebar, er… info window. Why is the left column called an info window? That’s not my definition of a window, nor anyone else’s I suspect, but hey, details. Why quibble now, I’m so close to successfully achieving my issue submittal.
- I open the “more” pulldown menu, but alas, the report a problem link is greyed out. What gives? Why show functionality when you can’t actually use it? At this point, I’m thinking to myself “Holy crap! I have got to blog about this.”
- My last ditch effort is to click on the offending liquor-store-in-the-middle-of-campus pop-up to see if I can report the problem there (maybe that’s what they mean by an info window?). Indeed, the pop-up also has a more pulldown with a functioning report a problem link.
- The problem report asks me some questions in order to route and solve the issue, but the last bit of information they ask for is to let them know the correct market placement for the liquor store. I was nice in my reply since I’d like the problem corrected, but seriously, they want help in placing the marker correctly? How about using the address they already have listed for the store which is in a different city altogether? It boggles the mind.