Category Archives: UX

BostonAzure.org “Subscribe to Email List” Form gets UX make-over

There is a “subscribe” form on the Boston Azure web site from which people can ask to be added to  the group’s email list.

I just made some updates to improve the user experience (UX). Here are the changes I made, and I list the handy web resources I used to help me decide (where applicable).

For field labels, I place the label directly above the field it describes. I use <fieldset> and <label> to describe my markup, presumably making it friendly to screen readers. (Credit to templates provided with ASP.NET MVC for making this part easy.) This is the layout that Luke Wroblewski (author of Web Form Design: Filling in the Blanks) recommends in his Best Practices for Web Form Design for scenarios where you want to maximize speed, and the user is likely familiar with the data being requested.

Luke’s work is packed with clear, actionable, useful guidance that is easily applied and backed by user research. A gold mine…

Other recommendations I adopted from LukeW include:

  • Since I have two required fields and three optional ones, I removed the (Required) labels, and stuck with the (optional) ones only.
  • Added field length for optional Notes field.
  • Made the Primary Action of the form (the Subscribe button) green, just like Apple Store (got the idea from UIE mailing).

Also from LukeW, but from a different source (The Apple Store’s Checkout Form Redesign, which I learned of from a UIE mailing):

  • After the form is submitted, the user does not get an immediate email. I made that clear in the resulting text.

More improvements I can make in the future, also based on LukeW, include:

  • Validate the data entered. In my case, this is currently only that a well-formed email address is provided.
  • Provide more context on why data is being requested.
  • Disable the Submit (Subscribe) button after it is clicked to avoid double clicks.

Other changes, outside of LukeW’s guidance:

  • Mentioned “low volume” and “will not spam you” – though also need a privacy policy. Will get to that eventually..
  • Programmatically set focus to the first field in the form when the page is loaded. I used the jQuery technique described here.
  • Dropped “:” (colons) at end of labels while also changing labels text from leading caps style to mixed case (“Job title” instead of “Job Title:”). While not decisive for me, I found an interesting discussion around whether to use a colon in form labels.
  • Made sure users could press Enter at any time to submit – but this will only work if they are not in the single multi-line field on my form. Need to consider removing that field … Need to consult with Joan on that one. 🙂

Used semantic mark-up to implement the green Submit (Subscribe) button mentioned above:

Green button that is visually distinctive

Submit (Subscribe) Button

HTML:

<input type="submit" id="primaryaction" value="Subscribe" />

CSS:

#primaryaction
{
 padding: 5px;
 color: #FFFFFF;
 background-color: #267C18;
 font-weight: bolder;
}

Old form:

sign-up form BEFORE the make-over

New form:

The subscribe form AFTER IMPROVEMENT

The AFTER screen shot

Steve Krug on Rocket Surgery Made Easy from Dec 2010 BostonCHI Meeting

Rocket Surgery Made Easy

Steve Krug speaks at BostonCHI

Notes from 08-Dec-2009 meeting

  • Steve’s new book – Rocket Surgery Made Easy – due in bookstores in a couple of weeks – material from this talk will be in his book…
  • Passed a copy of his book around through the audience for quick peek
  • 150 or so people in attendance

Writing process

  1. writing process: collect years of notes
  2. need deadlines to force you to write (and finish)
  3. collect relevant articles for each chapter and post them all on a wall
  4. once you’ve begun to panic, start throwing things overboard
  5. Outline, write, iterate
  6. get help
  7. throw things overboard (save for next book?)
  8. FAQ at the end of every chapter – good idea
  9. Doing usability (vs How to Think About Usability)

Doing Usability

  1. A morning a month – that’s all we ask
  2. Run tests – with whole team – at our site – scheduled monthly and well ahead of time – and debrief immediately after over lunch
    1. maybe do right before iteration planning
    2. company-sponsored lunch
  3. Start earlier than you think makes sense
  4. The sooner you get information, the better use you can make of that information
  5. Don’t wait until the site is “finished” – test it as soon as it is testable
  6. Don’t worry that “you already know about the problems”
  7. If you have nothing built, test other people’s sites
  8. Are you working on the site? –> Yes ==> test now!
  9. Recruit loosely and grade on a curve
  10. Beware implied domain knowledge
  11. Some testing can be done w/o your target audience
  12. Usability testers say many things that are similar to what therapists say – “what did you expect to happen when you did that?”
  13. Keep yourself out of it! It is about the user and what the user being tested is thinking.
  14. Make it a spectator sport
  15. Get everyone to come and watch the test – frequently the observers suddenly just “get it” that they are not their users
  16. Have high quality snacks. Keep the sessions short and compact. Do them on site. Make it easy for everyone to join in, hard to have a good reason to skip it.
  17. Record sessions with Camtasia ($300). Get a good USB desktop microphone ($25). Don’t record user’s face (“useless and distracting”). Use a screen sharing service (like GotoMeeting, $40/month?) to control the UI. High quality audio is important, and should be channeled to the observation room via GotoMeeting or Skype.
  18. Focus ruthlessly on a small number of the most important problems
  19. Serious because everyone will come across them, or serious because for those who do encounter them will be seriously impeded.
  20. Don’t feel you need to come up with the “perfect” fix
  21. Ask everyone in the observation room to write down the three most important issues they observed. These are raised at the debriefing session over lunch.
  22. When fixing problems, always do the least you can do ™
  23. Prioritize the list, then work your way down the list until you run out of time/resources
  24. Sometimes a tweak is better than a redesign – don’t get suckered into a redesign – the perfect is the enemy of the good!
  25. Focus on the smallest change we think we can make to address the problem we observed
  26. Q&A
  27. Remote Testing?
  28. Remote testing is handy – saves travel time, recruiting pool grows, … do over skype or GotoMeeting.
  29. How to get it off the ground? Try a group usability test of competitor’s site – everyone can get behind that. Do one and hope people get enthused about it. Make the cost of swinging by to watch the testing really small.
  30. Be very cautious about asking users how to fix the problems they’ve encountered. “Users are not designers.” “Hopefully you know a lot more than they do about design.” Listen to them, but be careful that they’re ideas are not well thought out. The purpose of testing is to “inform your design intelligence”.

Jared Spool on what makes a UI Intuitive

Jared Spool spoke at a Refresh Boston user group meeting on Thu May 28 in Cambridge, MA. During his talk, which was titled What Makes a Design Seem Intuitive?, Spool delved into some common ways User Experience (UX) goes wrong and some ways to make sure this doesn’t happen to you. My personal notes/interpretations follow; if you think I got it wrong or want to offer alternative interpretations, feel free to comment.

Executive Summary

  • Understand your users and their levels of skill/knowledge 
  • Understand the skill level needed by users of your software
  • Identify any gaps between the actual and needed skills (see two points above)
  • Design the software to bridge these skill gaps (which may vary from one user to the next)
  • Test your assumptions with real users to make sure you did everything right (Yogi Berra was right when he said You Can Observe A Lot By Watching!)

How to Create Non-Intuitive User Interfaces

First, some counter-examples – easy paths to UX Failure – how to be Non-Intuitive:

  • Do the unexpected: Spool showed an example of a site that used * (asterisk) to indicated those field “not required” which is opposite of popular convention. UX Fail.
  • Implement non-standard & sub-substandard behaviour: Spool showed a beautifully designed (visually appealing) site  with custom scrollbar that didn’t work right (pretty but not functional). They had implemented their own scrollbar functionality to get the look they wanted – but a fully-functional scrollbar is really hard to do well – theirs was jerky and unpredictable. UX Fail. (Plus a bonus Form Follows Function Fail.)
  • Be non-intuitive: Spool showed “Hay Net” – a very simple site to help sellers and buyers of hay find each other. This site had two main choices on the front page – “have hay”, “want hay” – but user testing showed that about half the time “have hay” was chosen to find someone who has hay, and the rest of the time chosen when I am the one who has the hay. (This might qualify as what my old friend Julianne would call “Escher words” – where the meaning flips back and forth in your mind between alternative viable interpretations much like certain of M. C. Escher‘s artwork). Wording was not intuitive, even though it was very simple. UX Fail.
  • Add non-core features until your application is large and complex: The larger and more complex an app, the harder it is to keep it intuitive. This was a general comment from the Q&A, supported by examples in his talk [Wang dedicated word processors were very complex (requiring 1-2 weeks of training to use), supplanted by WordStar, supplanted in turn by simpler Word Perfect, later supplanted itself by simpler Word (after Word Perfect had grown more complex), and now Word is really complex – tens of toolbars, including one for editing 3D graphics]. But simple does not imply intuitive (see “Hay Net” example above). UX Fail, again and again.

Different Kinds of People

  • Key point: Intuitive is personal – maybe it works for me, not for you — it is unlikely that all possible users have identical knowledge
  • Prior experience of the user matters – where are the on the Knowledge Continuum?

What is this Knowledge Continuum you speak of? Imagine a continuum where the left-most end is “No knowledge” and the right-most end is “Full knowledge” and your UI is designed for users somewhere on that continuum. If the user’s current level of knowledge is less than the level to which you target your design, your software has a problem – there is a gap that needs to be overcome.

A design is intuitive if the Current Level of Knowledge = Target Level of Knowledge, or if the gap is small enough such that it can be bridged with good UI design. If the gap is too large, you may need training (whether online on in-person).

Two types of Knowledge

  • Tool Knowledge (for a specific tool – Word, Visual Studio, TurboTax)
  • Domain Knowledge (independent of this (or any specific) tool – writing, developing in C#, creating personal tax return with weak tax-code depth)

Techniques for Creating Intuitive Designs

  • Field Studies (watch your users in action)
  • Usability Studies
  • Personas
  • Patterns (reuse known good patterns)

Specific Examples for Creating Intuitive Designs

  • Bring Target closer to Current w/o resorting to training or help. This means your software needs to target the right knowledge level – find that target using the techniques listed above – remember: Developer/Designer does not have same knowledge level as User (at least mostly true).
  • Wizards can reduce target knowledge requirements (bridging that knowledge gap).
  • If your user base consists of very different Current Knowledge levels (e.g., home tax preparation vs. professional tax preparers) you can create two (or more?) specialized/targeted applications.
  • Every six weeks, every member of design team needs to watch users using the design for two hours.
  • Don’t hire an agency to design your experience. (Spool thought it was fine to have an agency implement your application, but you need to design it first if you want to be successful.)

Further Information

Here is an older article by Jared Spool on the same topic as this talk: http://www.uie.com/articles/design_intuitive/ (thanks Joan).

UIE Resources