In simpler times, this is how upgrades worked (photo by L. Marie).
When redesigning the new syllabus for our GMAT prep course, I became somewhat nostalgic for how software upgrades used to work.
Remember when you used to choose whether software you used every day should be upgraded? Once enough new features became available or you couldn’t live with a certain bug anymore, you would go to CompUSA, pick up a new set of floppies and install. Â You could go for years with an outdated version of WordPerfect; as long as you were able to use it in the manner to which you were accustomed, you never knew what you were missing.
It was also not really in the software publisher’s best interest to give you updates all that frequently. Those enhancements were expensive to deliver–bits needed to be imprinted on thousands of little 3.5″ disks and distributed across the country. Crazy, huh?
Today, it’s far less expensive for software publishers to offer updates to users. Thanks to the Internet, enhancements can be completed and delivered as soon as the code is deemed ready for production. You can deliver an upgrade to all of your users essentially simultaneously, but should you?
For some items, defects for instance, instantaneous upgrades have an enormous benefit for both publishers and users: one user reports the defect, and the defect is then patched and released for all users. However, other types of changes–such as major alterations to the user interface–can be jarring, discomforting, and ultimately frustrating for users.
Changing user interfaces doesn’t only pose a problem in the world of software. Earlier this year, Tropicana Orange Juice made a small change to its packaging that ignited an angry firestorm from their customers. The uproar was so intense that Tropicana ultimately reverted to the old packaging.
Given the ease of releasing software, problems like the one Tropicana encountered can be exacerbated when upgrades are made to websites. Facebook learned this lesson after its October 2009 release, which prompted the formation of groups like “We Hate The New Facebook, so STOP CHANGING IT!!!.” The more familiar a product, whether orange juice or a social network, the more resistant users become to changing it. Is there a way to enlist user support for change, while making the act of changing ultimately their choice?
For our redesign, we wanted to make sure we violated neither user expectations nor user control. Â The syllabus page is the most frequently visited page on our GMAT course customer site. Our GMAT customers are all at various stages of study on any given day. Â Some of have just started their GMAT prep yesterday, while some are taking the actual exam tomorrow.
For users who just started their course, are we really going to make them learn a new syllabus page? For users who are taking the GMAT tomorrow, think they have time to learn how a new page works?
To ease customers’ transition to their new syllabus page, we created a notification bar that highlights how to use the page, a link to go back to the old syllabus, and the ability to easily send feedback. This way, users can learn how to navigate the new layout, tell us what they like or what they would like us to change about it, or even decide that they want to keep using their old, familiar page.
We made some additional investments to create a way for users to choose which view of the syllabus they want to see. While there is some expense in maintaining both versions for a limited time, we see this investment as minimal when compared to the value of keeping students in the driver’s seat.
–
Pete Miron is Knewton’s Chief Technology Officer, and you can follow him on Twitter.
