Usability testing a support mobile page at the NetVet lounge with NetVet Mike Williams.
Recently at CiscoLive!, we spent a full week with customers and partners doing in-detail usability tests of Cisco.com and some of our mobile sites and apps. This is one of the main methods we use to make our web and mobile easier.
What’s a usability test? Something different than you might think. While you’ve probably heard of other research techniques like focus groups and surveys, usability tests and listening labs are a way for us to learn through observing how people use our sites: We have someone sit down in front of the screen and ask them to do a task that they would in their real work day. This could be solving a support question, researching a new product, finding the right download, investigating a new API, or any number of other things.
Here’s the difference between a usability test vs. a focus group or survey: In a focus group, a facilitator often throws out an idea or scenario and gets a group of people to comment on it. The people in the room will tell you what they might like… they will build on others comments… they may give you some great ideas! But, you won’t really be learning by observing. You won’t understand the kinds of things they will actually do in real life, because you’re asking them what they think they would do. You aren’t observing.
But when we observe people using our mobile apps or web sites, we can see lots of things. For instance:
- We can see the areas that trip them up (even if they report to us that the experience is just fine)
- We can see the areas where they’re getting the wrong result (even if they think they’re getting the right one).
- Or sometimes even technical problems that we see and can troubleshoot, but they can’t.
We recommend running usability tests or listening labs at multiple stages for major projects:
- At the beginning of the project – when you want to understand current state and also look at how competitive or best practice sites and apps are doing.
- In the middle – while you’re still developing, and direct observation and feedback can make a huge difference
- Before release – so you can catch any last-minute problems
- After release – because sometimes when outside factors and environments affect the app or web experience in way you can’t expect (for instance, how and whether people can find your site topic on Google or other search engines, and how they interact with the results).
Even though this sounds like a lot of testing, there are some new techniques you can use to get real user feedback very quickly – within hours or days. I’ll talk about that in a future post.
Meanwhile, keep testing. And, remember baseball legend Yogi Berra, who said:
“You can observe a lot by watching!”
Tags: cisco.com, design, mobile, usability, user experience
Did you notice the recent change to the menus on Cisco.com? We call them “megamenus” — those convenient lists that fly down when you mouse over the masthead bar on any page on Cisco.com. We recently updated the “Products & Services” megamenu on the site to make it more readable and simplify navigation.
Here’s the new improved Products megamenu:
For comparison, the here’s previous version:
What We Did
Do you notice what’s changed?
- We reduced the length of the list of product categories so that it’s more readable.
- We updated the layout so there’s less back-and-forth scanning.
- We made Solutions and Services a bit more visible.
- We put Cisco Validated Designs in a more obvious place.
- We reordered some other things here and there to help us understand traffic patterns.
We think this is a nice simplification for our site-wide mega menus. And, of course, you can still find the full list of all products via the “All Products” list.
(And, as always, if you have feedback, please send us a note here or at the [+]Feedback link that’s at the bottom of every page.)
Tags: digital experience, navigation, products, usability
There’s an adage that “if you can’t measure it, you can’t manage it,” and all of us that are in the business of managing or running things pretty much live by that.
But, how to do you measure something as squishy and ephemeral as an “experience”? And, what experiences are worth managing? At Cisco, we’ve taken a very focused approach to managing the online experience you have in web, mobile and our social media: We focus on customers’ and partners’ top tasks and missions with us, and then we measure relentlessly the success, failure and satisfaction on those. This allows us to reduce complex experiences to a set of trackable numbers that we can manage. We take this approach on big things, like the experience of getting support answers online. In fact, usability guru Gerry McGovern explains this approach to “Top Task Management” in a recent article featuring Cisco’s Bill Skeet. And we also take the “manage the experience approach” on little things — those simple but important tasks that people do with us every day. Read More »
Tags: design, digital experience, usability
Editor’s Note: This is the last of a four-part deep dive series into High Density Experience (HDX), Cisco’s latest solution suite designed for high density environments and next-generation wireless technologies. For more on Cisco HDX, visit www.cisco.com/go/80211ac. Read part 1 here. Read part 2 here. Read part 3 here.
If you’ve been a long time user of Wi-Fi, at some point you have either observed someone encounter (or have personally suffered from) so called “sticky client syndrome”. In this circumstance, a client device tenaciously, doggedly, persistently, and stubbornly stays connected to an AP that it connected to earlier even though the client has physically moved closer to another AP.
Surprisingly, the reason for this is not entirely…errr…ummm…unreasonable. After all, if you are at home, you don’t want to be accidentally connecting to your neighbor’s AP just because the Wi-Fi device you’re using happens to be closer to your neighbor’s AP than to your own.
However, this behavior is completely unacceptable in an enterprise or public Wi-Fi environment where multiple APs are used in support of a wireless LAN and where portability, nomadicity, or mobility is the norm. In this case, the client should typically be regularly attempting to seek the best possible Wi-Fi connection.
Some may argue that regularly scanning for a better Wi-Fi connection unnecessarily consumes battery life for the client device and will interrupt ongoing connectivity. Therefore the “cure is worse than the disease”. But this is true only if the client is very aggressively scanning and actually creates the complete opposite of being “sticky”.
The fundamental issue with “stickiness” is that many client devices simply wait too long to initiate scanning and therefore seeking a better connection. These devices simply insist on maintaining an existing Wi-Fi connection even though that connection may be virtually unusable for anything but the most basic functionality. Read More »
Tags: 3G, 4G, access point, AP, beacon, cellular, client, connection quality, device, environment, experience, feature, HD, HDX, high density, IT, LAN, mobile, mobility, monitor, network, performance, retransmission, roaming, solution, sticky client, sticky client syndrome, usability, user, wi-fi, wifi, wireless, wlan
One of the most consistent challenges in designing for your customers’ digital experiences is understanding what things they’ll be doing when, which in turn governs what device they’ll be doing those things on. Will it be on the couch with a tablet? On the go with a smart phone? At work on a laptop?
On the Cisco digital team, we do a lot of research and planning on this very topic, and have found that some tasks are very time/device specific (such as looking up appointment information or background information on your phone right before a meeting) while some are more broad and could happen anywhere, such as checking product information or searching. To illustrate this better to our teams internally, we put together a storyboard to illustrate how our customers and partners use multiple devices (desktops, laptops, tablets, smart phones) within the course of their day when interacting with us and each other. Here’s a panel from it:
What this doesn’t show is that there are also “could happen anywhere” cases. These are often the most mundane of things, but important ones. For instance, our login page on Cisco.com receives more than 2,000,000 visits per month. But when we took a look at the mobile part of the login experience, we knew something had to be done!
The most obvious problem with this page above is the teeny tiny type. And then, to use it, you have to stretch and zoom to get the fields big enough to even type into. It was, as we euphemistically say in the tech biz, “suboptimal.”
One solution would have been to create separate login designs for large tablets, small tablets, phones and desktops. Instead, we chose a smarter way, using Responsive Design, which I have blogged about previously: We used one “smart” code base that adapted the display for the size of the current device. The result was very simple and very nice: A clean login page we launched recently that retains its normal behavior on the desktop browser, but shrinks to fit for tablets and smart phones. It’s a simple example of where Responsive Design saves time in deployment because we could write the code once and put it through one development and test cycle, rather than creating three or four different experiences and having to develop and test them all separately.
Responsive design doesn’t solve every problem — and there are many, many experiences on mobile that need to be designed specifically for venue and device. But use responsive design where it helps save time and money, and can provide some consistency in basic behavior.
Thanks to our mobile, design, and IT teams for pushing this out. Enjoy!
Tags: mobile, usability, webexperience