it sucks to be you

steve krugmonday morning at HighEdWebDev05 opened with a presentation from keynote speaker Steve Krug, author of Don’t Make Me Think.

“After a decade writing computer manuals, in 1989 Steve Krug moved up the food chain to usability testing and interface design so he could fix the problems instead of explaining them. Since then, he’s evaluated and improved interfaces for a wide variety of clients, primarily in online services and the Web, including Apple, AOL, Netscape, the late, lamented Excite@Home, BarnesandNoble.com, Lexus.com, and Circle.com.”

impressive enough by description, steve’s keynote was quite engaging, titled It Sucks to Be You (an inspirational keynote by Steve Krug) - steve opened with a small background and an important reminder; most of his work it based on common sense, and can easily be applied to any organization’s project plans. i took notes so i’m quoting as best i can-

steve gave us his entertaining and accurate ‘top ten reasons it sucks to be you’
(read: 10 ten reasons why it sucks to be a web developer in higher ed):

  1. we face corporate expectations on often non profit or non existent budget
  2. stakeholders can be petty & whiney when it comes to a project- and behave in ways they wouldn’t dare in the ‘real world’
  3. we are expected to develop content management systems in our spare time, and also quickly herd kittens while we’re at it
  4. we almost always face unique fiefdom hells when developing sub sites (e.g., ‘we want this typeface!!)
  5. we have multiple audiences
  6. we need to work from many disparate databases
  7. we often find ourselves in the classic ‘homepage death match’
  8. academic leaders are much less likely to force everyone to tow the site consistency
  9. we have tons of ‘dynamic’ content that we never seem to receive, but all of which is enormously important despite variable quality
  10. we are thrown into personal arms races to use what’s cutting edge and cool

aside from instructions being pointless, he commented that ‘happy talk must die’. he argues that mission statements, way finding pages, and type on the web in general is utterly pointless. he mentions one should take all the words on their page, and cut them in half. then take the word count left over, and cut that in half - then you will have the truly read amount words the audience is reading in the first place.

steve loves templates, because people don’t do usability on their own- they need the professionally designed, tested webpage. this tied well into his thoughts on navigation. people must always know where they are on a site- a navigation should always be easy to spot. it should be approachable: never more than 7 list items, and they should always be in a list. the menu items should always be clear and unambiguous, and consistent across all subsites.

steve argued there’s no reason to be subtle about the old ‘you are HERE’ indicators. He prefers big page titles that match the originating text link. interestingly enough, he mentions that breadcrumbs are ok, but not really a necessity.

one item he mention that shocked everyone in the room was that he couldn’t find one higher ed site in all his surfing that did a good job of presenting why the school was a great place to matriculate in 20 words or less. taglines and welcome blurbs were sorely missing in their proper manner, which took away from the sites opportunity to make a unique selling proposition to the audience. he also mentioned that most university sites that weren’t named after their location gave no clear indication as to where they were located outside of marketing messages.

before closing, steve also ran his common gauntlet about the importance of usability testing. he recommended that even on shoestring budget, this can be easily achieved. he says it’s a good idea to only test with 3-4 people in one morning so that discussion can be brought to the table that same day. he recommends that usability testing occur once a month- without stats, surveys or exit questions- what he defines as faux validity. rather, he recommended using screen and sound recorders for general review. the process he advised to sum this notion up was: test. fix, test..

Save and Share »
  • Digg
  • del.icio.us
  • StumbleUpon
  • NewsVine
  • YahooMyWeb

Leave a Reply