Expected and Actual

I'm a fan of simple hooks to summarize complex ideas, and one of my favorite go-to's is simple, memorable and versatile:

Expected == Actual

Not much to look at by itself, but I've gotten a lot of mileage out of this in some useful contexts. You probably recognize one of the most obvious applications immediately: testing / QA. We're well-trained in applying expected == actual in testing, and most bug-reporting contexts will define a bug as a scenario in which actual behavior doesn't match expected behavior.

Even in this simplest application, all the value here is in how we exercise the framework, and I promise if you really work this equation, you'll have a better handle on bugs immediately. Of the two sides of this equation, "expected" usually seems easier, but is almost always more difficult becuase we most of our expectations are unspoken. If I had a dime for every bug report I've seen where "actual" was well-documented but "expected" existed only in the mind of the reporter, for instance, I'd be writing this from a beach in Hawaii.

Of course, that's where the exercise begins to get interesting. "What were you expecting" is a great place to start here. If you can trace expectations to real documented requirements, it's a short conversation (perhaps followed by another conversation to see why that scenario was missed in autometed testing). It's not unheard-of, though for these bugs to occur in scenarios that weren't explicitly called-out in requirements. If this is the case, be sure to examine "expected" to see if it's reasonable for most users to expect the same thing under those conditions, which is a great segue to my next favorite application of expected == actual.

I'm of the opinion that expected == actual is also a pretty good foundation for understanding usability. I touched on this recently in a post about API usability, and it holds true generally, I believe. In that post, I referenced Steve Krug's Don't Make Me Think, which is both an excellent book and another great oversimplification of UX. Both of these are built on the premise that whenever an application does what a user expects it to do, they don't have to think about it, and they consider it usable.

Mountains have been written about how to accomplish this, of course, and I'm not going to improve on the books that talk about those techniques, but as I pointed out with resepct to API usability, consistent behavior goes a long way. Even devices or applications we consider highly usable have a short learning curve, but one a user is invested in that curve, it's tremendously helpful to leverage that learning consistently -- no surprises!

A final consideration that applies in both these areas - when you find a case where "expected" really isn't well-definded yet, and can't be easily-derived based on other use cases (consistency), this is a golden opportunity. Rather than just taking their version of "expected" at face value, ask why they expected that (when possible). You probably won't be able to invest in a full "nine-why's" exercise, but keep that idea in mind. The more you understand about how those expectations formed, the more closesly you can emulate that thinking as you project other requirements.

Besides these examples, where else might you be able to apply "expected vs. actual"?

APIs have usability, too!

Usability has a long history in software. In fact, as I sat down to pen these words, I googled "history of usability ux" and turned up some scholarly articles going back over 100 years. Too far. In software, you can't go wrong starting with Apple, which puts the origin of UX in the mid 90's. Better.

But for much of this time, we've tuned in to software usability as experienced through our user interfaces by end-users. Today, there's more to usability than user interface design, and I'd like to broaden the discussion a bit.

Usability? What usability?

When you think about great user experiences, typically, we don't consider them to be great user experiences unless we start comparing them to lesser experiences. I believe this is a big clue into how we can apply UX more universally. I really think a lot of usability boils down to doing what a user is expecting you to do... so when you do it, most users will never even notice.

Think about it - when's the last time you gave a passing thought to usability for an application that was already behaving the way you wanted? There are scores of great books on how to achieve usability (I love Steve Krug's Don't Make Me Think, and Don Norman's The Design Of Everyday Things), but I really believe if you can manage to do what the user is expecting you to do, you're typically in pretty good shape.

The changing landscape of applications

Next, let's look at changes in applications and application design. You can probably see where this is going. Whereas once the only users of our applications were end-users operating via a Windows or web interface, cloud-native applications based on microservice architecture rely heavily on APIs to orchestrate, integrate and extend functionality. In many cases, APIs are the interfaces for services, and developers are our users. In this sense, APIs are the interface, and the user experience (UX) is found in the ease-of use of these APIs.

And what is it about an API we'd consider more usable? As with the generalized case above, I think the ultimate yardstick is whether the API behaves the way a developer would expect. I believe the popularity of RESTful APIs, for instance, isn't just because JSON is easy to work with -- it's because a well-written RESTful API is discoverable and predictable.

Note that discoverable isn't the same as documented - even correctly documented, which never happens. Discoverable starts with tools like swagger that expose live documentation of API methods and objects, but it connects with predicatable in an important way: as developers engage with your API and discover how some of it works, consistent behavior and naming creates predicability. When these two factors are combined, they reinforce one another and create an upward spiral for developers in which learning is rewarded and also helps future productivity. And yes - this exact relationship is part of understanding usability in a visual / UX context, as well.

Watch for more posts on API conventions and style soon, and watch for the ways these ideas support one another and ultimately contribute to Krug's tagline: Don't make me think!

Design resources for developers

Keeping abreast of technology updates has always been a formidable job.  As always, there are all sorts of options for consuming the fire hose of news.  For me, RSS feeds (I use Feedspot for my reader now) from some trusted sources remains a favorite, and I'd like to share a couple of gems that have been really fantastic for a number of years now.

Both of these are design-oriented sites, focusing on UI technologies, techniques, and reviews as well as design theory, layout reviews, and the like.  Given my typical focus on back-end design and architecture, these sites are a great way to bolster by front-end perspective and give me some tools to jump-start UI work.  I've been following both of these sites long enough that I honestly can't remember where I found them, but I'm really impressed with the track record for both.

Honkiat.com (odd name, I know, but it's good stuff) is a real grab-bag of articles, so be prepared to filter out some topics you may not be interested in.  If you sift through to topics that are of interest, though, there are some really good resources.  In most cases, these articles are annotated link collections, so don't expect to find source code here.  Do expect to see examples of UI tools and technologies put to use with links to source sites where you can learn more.   A quick flip through recent articles shows topics like these:

Smashing Magazine tends to cover fewer topics more deeply, with more of a focus on their own content, vs curation of content from other sources.  This is a great source for tutorials and backgrounders, and they've published a number of books based largely on rolled-up content from the site.  Again, not everything will be of interest, but the quality of the content that's here is really high.  Here's a quick sampling of some recent articles from Smashing Magazine:

If you're looking for a couple good streams of design inspiration, give these two a look, and if you've got any other favorites, let me know!

In design, details matter

Have you ever experienced a cascading menu that seemed to run away from you as you navigated it?  This is one of those subtle usability failings that can lead to a disembodied hatred of a site or application.  Very few people will notice what's actually going wrong, let alone what should be done to fix it.

Galileo
Galileo (Photo credit: dglambert)

Ben Kamens noticed when Amazon got this right.  Not only did he notice, he wrote up what he found and developed a jQuery menu you can use on you own site to achieve the same fix.  The improved implementation, by the way, has its origins in noticing what direction your mouse is moving -- if it's headed toward a sub-menu, this implementation gives you a chance to catch it.

The moral of the story?  When you get this stuff right, most people never notice the details, but they'll notice the feeling of quality in the product.  Nobody loves an Apple iAnything because the edges are chamfered exactly so or because the icons are rounded just a bit, but they notice that it feels solid and sorted out.  I'll bet you'd have a hard time finding people who can tell you exactly why a BMW feels better than a Chevy, but most of them will agree that it does.

As a designer, it's important that you do, in fact, notice the little stuff, and that you understand how these details contribute to the quality of your product.  With any luck at all, you'll work for an organization that also gets this stuff, because you'll also find it pretty frustrating to try to explain details like this to a bean-counter that hasn't got any awareness of this relationship.

Enhanced by Zemanta