Usability research and analysis
Five Sketches™ Consulting helps your development team with user-experience research and design to meet your goals and your customers' needs
How tiny does the keyboard on a handset or smartphone need to be?
If you ask me, I’d say: “Not anywhere near as tiny as they are.”
I’d also say: “If you make an app for iTouch or iPhone, ensure that the keyboard flips into a larger, wider version when users rotate the device on its side.”
If your user persona includes an image, which type of image helps the team produce designs that are more usable?
The illustration on the left? Or the photo on the right?
According to Frank Long’s research paper, Real or Imaginary: The effectiveness of using personas in product design, photos are better than illustrations. Teams whose user personas include a photograph of the persona produce designs that rate higher when assessed with Nielsen’s heuristics for UI design.
Frank Long compared the design output of three groups, drawn from his students at National College of Art and Design (NCAD) in Ireland, in a specific design project. Over the five-week project, two groups used user personas of different formats. One group was the control group, so they worked without user personas. The experiment looked for differences in the heuristic assessments of their designs.
Photos—versus illustrations—are one of the ways I’ve engaged project teams with the user personas that I researched and wrote for them. Here’s a teaser:
My friend Donna, who is in her 50s, asked me to help her with her photos. (Donna is not her real name.)
Here are the things Donna wanted to do:
Previously, when the camera’s memory card was full, Donna would delete unwanted photos by using the camera’s delete function. At some point she wouldn’t want to delete any more photos, so she’s replace the memory card.
She once removed the digital photo frame from the package, but never plugged it in. She had no idea how to get photos into the digital photo frame.
She’s seen other people use a slideshow-style photo viewer, but Donna doesn’t know this feature starts by default when she clicks a photo. Without any photos on her laptop, she hasn’t had the opportunity to discover this.
This is not a simple problem. I showed Donna how to plug in her camera’s memory card to the laptop. I showed her the My Folders folder, how to create subfolders, how to multi-select and rename photos from her camera, and then move them into a folder on her laptop. And I showed her how to use a USB drive to load photos into her digital photo frame. Since I’m a good instructor, I used scenarios (“You go to Barbie’s house. How will you show her your photos?”) and, after she learned each task, I gave her the chance to confirm what she learned by demonstrating the task. We did this repeatedly.
The next day, I got a Facebook message from Donna saying that her photos were nowhere to be found. Her adult daughter later confirmed that the photos had been unintentionally deleted.
Donna’s not stupid. During our one-hour informal session, she knew to ask performance-oriented questions. For example:
Translated into Windows XP jargon, her question was:
Windows Explorer, to view my files?Exploring files is alien to people who haven’t done it before. Dragging-and-dropping is easily grasped. Creating folders is manageable. Folder hierarchies (putting one folder inside another folder) takes longer to grasp. When it comes to mapping the objects in the GUI to physical objects like the camera and the laptop’s hard disk, it’s a challenge.
Since I’m an expert user of Windows Explorer, throughout our informal training session I kept wondering: “Am I showing Donna the way Microsoft intended a novice to work with files?” I tried to show her the easiest possible way to manage her photos.
I feel awful that Donna lost her photos, and it’s a good reminder for me that not every user is an expert user. Except for the products we use daily, most of us are perpetual intermediates—we’re people who master certain skill areas and then continually backslide due to our intermittent use. With every software upgrade, we’re transfer users—people who know conceptually what they want to do, but who cannot get it done in the new interface. With every first experience, we become novices again—people who don’t know what’s possible and may not be able to put our questions into words. People who lose their work, waste time, and mess things up.
If it happens to one user, that’s too bad. If it happens to lots of users, it that’s not the user’s fault; it’s a design problem. The thing is—and before you conclude that my point is “Windows is poorly designed”— Donna uses Windows XP, which was released in October of 2001. That means Windows XP would have been designed last century. The imagination and research needed to foresee how an operating system would be used 10 years into the future is staggering. And, even if you could have predicted that, some of your options might have been restricted by the legacy code (existing programs) you inherited.
Actually, it sounds like fascinating and challenging work. It also has me thinking that there’s something to the built-in obsolescence of SaaS. But most of all, I’m thinking this model of files, folders, and disks needs to be examined closely with an eye to improving usability.
I was recently invited to join a design-specification review for a feature I’ll call Feature X.
As I listened to the presentation, I thought: “There are pieces missing from this spec.” When the time came for questions, I asked about the project’s scope. “Your spec is titled Feature X, but I see very little X described in this document. What does X mean to you?” Sure enough, there was a gap between the title of the design specification and the content of the design specification. And the gap was deliberate, on the part of the Development team.
The company in question makes software, not cars or bicycles, but the gap between the spec’s title page and the spec’s content was just as great as the one in the illustration. The company’s potential customers say they want Feature X. The Development team says they only have the resources to build Feature Non-X. Non-X is missing some of the key features that define the X experience.
Except for its sleight-of-hand usefulness to sales staff, Feature Non-X may be a non-starter. But there’s one more thing to tell you:
Apparently—I say “apparently” because the evidence is anecdotal—one reason customers who have a competitor’s X don’t use it is because X is complicated to set up and complicated to use. This is, of course, a golden opportunity to make a simple, usable feature that provides only what customers will use.
If this small company is lucky, their Feature Non-X will sell well and the company will leap-frog their Feature-X competitor. With a little marketing- or ethnographic research, the company would have some certainty about why Feature X is requested but not used—and the team would have information to help them design Non-X. Unfortunately, a lack of resources may leave the team’s designer and developers guessing, and the company will have to take this uncertainty in stride.
Recently, one of the new-media gurus characterised Twitter as a place where people whine about the annoying or unexpected things that happen to them, in microblogs of 140 characters or less. Here are some examples:
The people I pay attention to on Twitter usually post positive or informative messages. But there’s nothing wrong with a little griping. We can all relate to a situation that’s gone wrong. Twitter is about shared experiences through a social network.
It’s often also about products, services, user experience, and design. In order, the above tweets say things about salespeople, Twitter, lifeguarding oversight, Omnigraffe, OpenIt scissors, and Sony’s site. Two thirds of these name or link to the company or the product in the message. And they do so via a social network.
Social networking is the equivalent of a reception. It’s a roomful of people, some of whom you know, some of whom you don’t. At this reception, the chatting happens asynchronously and it’s entirely free of geography. This is important to understand, because it’s the kind of world in which and for which we’re designing and building software and websites. Anyone, anytime, can comment on our products and sites, and others can search for—and be influenced by—those opinions. Consumers can get opinions from people they don’t know about a product or service, before they buy. For example, you can find opinions about a phone company by using these keywords in a Twitter search
or by visualizing the keywords or tags that people type in their Twitter messages about the phone company. Check this tag cloud for tweets that contain the words “Telus” and “phone”. Are the tags positive? negative? neutral?
Would any of this influence my decision to purchase a mobile-phone contract from Telus?
Finally, just to show there’s nothing new under the sun, here’s a blog post that has already said a few of the things that I just thought of.
If you’re creating user personas, How-To articles often tell you that you only need two or three personas at most. That’s fine for most web-design projects. However, if you are working on an enterprise-wide system that has modules for different types of professionals who each perform distinct and substantial tasks, then you will have a larger number of user profiles.
Imagine a product suite the size of Microsoft® Office that actually consists of very different pieces: Excel, Word, Access, PowerPoint, and more. Usually, the only persona who is involved with every module of a suite is someone like Ivan the IT administrator, whose tasks are very different from most users.
That may sound obvious, but I really struggled for a while with the notion that I was “doing it wrong” because I couldn’t squeeze the user roles and needs into a mere three user personas—or five, or seven, for that matter. When you have a dozen user personas, it’s challenging to keep them all apart, but most teams only need a few at a time. Likely, the only people who need to know all the user personas are on the user-experience and product-management teams. And the alternative—to have a catch-all user persona whose role is to “use the software”—is of no help at all.
If, by chance, you find you need many user personas, then beware once the projects wrap up and the teams turn to their next projects. They may have incorrectly learned to begin a project by creating user personas (“…well, that’s what we did last time…!”) instead of re-using and tweaking the existing user personas. [Not everyone agrees with re-use; see the comments.]
User personas will influence your product design and affect how people throughout Development and Marketing think, strategically and tactically, about their work. So you need to get the user personas right. Getting a series of user personas reviewed—not rubber-stamped but mindfully critiqued—is a challenge; nobody ever makes time to do it well. Here’s my solution: after you research users and then write your draft user personas, review them together with some subject-matter experts, Marketing staff, and developers, in a barn-raising exercise. Pack them all into one afternoon for the initial review. Then meet the first Friday of the month until you have agreement about each user persona. During one such meeting, one of my subject-matter experts said to another: “Oh, this user persona is just like [a customer named H—]!” The user persona was so on-target that that it reminded her of someone I had never met or researched. That was a nice way to learn that I got it right.
For detailed How-To advice on developing user personas, try these readings:
During usability testing, I’m always fascinated to see how creatively users misinterpret the team’s design effort. I’ve seen users blame themselves when our design failed, and I’ve seen users yell at the screen because our GUI design was so frustrating.
One Wednesday, over a decade ago, the tables were turned.
I unintentionally “agreed” to let Facepoke—that social-networking site—invite everyone with whom I’d ever exchanged e-mail. Think about all the people you may have exchanged e-mail with. Former bosses and CEOs. Your kid’s teachers and the principal, too. People you used to date. Prospective business partners, or people you’ve asked for work but who turned you down. Your phone company, car-rental company, bank, and insurance company. Government agencies. The person you just told “I’m too busy to volunteer,” and your teammates from that course in 2005. Your e-mail records are full of people that you simply wouldn’t want on your Facepoke page.
See paragraph 1: User blames self for poor design.
Facepoke had been interrupting my flow for several days, offering to help me find Friends by examining my Gmail records.
I gave in, chose three Friends, and clicked Invite.
The screen flashed, but the list was still there.
I clicked Invite again.
Then came the moment of horror: I saw that the list had been changed! Switched! It was now a list of every e-mail address in my Gmail account that was not already associated with a Facepoke account.
With that second click, I had “agreed” to let Facepoke invite everyone with whom I had ever exchanged e-mail. There was no confirmation, no “Invite 300 people? Really?!?”
I sought in vain for a way to Undo.
With each passing minute, I thought of more and more people who would have received this inappropriate inivitation to join me on Facepoke.
Why wasn’t there a confirmation?See paragraph 1: User emotes in frustration.
In my usability- and design work, I will continue to ask: “What’s the worst that can happen?” I will promote designs that prevent the worst that can happen. I will not present two apparently identical choices back to back, one of little consequence, one of great consequence. I will allow users to control their account and to Undo or recover from their unintended actions. I will not make users feel like they’ve been misled.
Peter Merholz of Adaptive Path explained his view that customer experience is an investment, not a cost, in an article this week on Harvard Business Publishing’s site.
I adapted one of the “linking elephants” illustrations in the Merholz article by adding another row of boxes and text to illustrate what Merholz says: it is design that motivates people to modify their behaviour. I also added an ROI or return-on-investment calculation.
Design makes the difference. By “design” I don’t just mean how it looks; I’m including the mental model (how the site visitors or users think the site meets their needs), the workflow and interaction (how users complete the task), the experience (including how users feel about using the site), and the prototyping and formative usability testing needed to validate the proposed changes. Your business case needs to include the cost of all this design work.
Making a business case can be intimidating, but the above illustration shows that it’s conceptually easy. In your business case, you predict the benefit to the company of a project, using the best estimates you can come up with. What would be your organisation’s goal? What behavioural change on the part of site visitors moves you toward that goal? What is that behaviour worth, either in revenue or in reduced costs? How many site visits do you get per week? What’s the potential impact to your organization of redesigning part of your site? After you implement the new design, you use summative testing and comparisons to get feedback on the assumptions of your business case.
I recommend reading Merholz’ article on the Harvard Business Publishing.
I was wondering whether the “design” of web sites and software is anything more than “intermediation” (inserting a layer between the user and the raw data), whether “intermediation” is just a synonym for “information architecture,” and whether “design” must therefore be something greater—something that includes the emotional impact of the experience. Or is that last phrase merely another way to say “user-experience design”?
Apparently, it was a day for wondering, because, next, I thought about the many excellent software developers I’ve worked with, and wondered how they would respond to my apparently pointless musings. Then I wondered: would the opinions of my software-development colleagues be informed by their formal education or their work experience, attendance at conferences, or professional development reading? [For me, as a usability practitioner and CUA, it’s all of the above.]
After this, I wondered how much software developers are formally taught about user-experience design and user-interface design, in school.
A quick online search led me to the course lists, summarised in the table, below, for the different program types offered where I live. I’ve highlighted the two courses that specifically mention interface design. There’s no mention of usability, or of the all-encompassing user experience. There is one program at Capilano College that includes user-experience design, and my own course, Fundamentals of user-interface design, is only offered every two years through one of SFU’s continuing studies programs. Also, I’ve noticed an increase in the proportion of software-development students at monthly Vancouver User-Experience events. So change is in the wind.
What’s the situation in your community of practice?
It seems to me there’s a hole in the bucket, but we can mend it. The answer simple. Go back to your school and ask to sit as an industry representative on the academic-advisory committee. The local chapter of your professional association can help open doors. Once appointed to the committee, participate in a curriculum review. This is a slow, formal, and somewhat political process—but it works. It’s a great way for experienced software developers and interaction designers to improve our communities of practice. And it looks good on a resume.
| Bachelor degree, Computer science, Simon Fraser University | Certificate, Software systems development, BC Institute of Technology | Certificate, Software engineering, University of British Columbia |
|---|---|---|
| CMPT310 Artificial Intelligence Survey. CMPT411 Knowledge Representation. CMPT412 Computational Vision. CMPT413 Computational Linguistics. CMPT414 Model-Based Computer Vision. CMPT417 Intelligent Systems. CMPT418 Computational Cognitive Architecture. CMPT419 Special Topics in Artificial IntelligenceComputer Graphics and Multimedia. CMPT361 Introduction to Computer Graphics. CMPT363 User Interface Design. CMPT365 Multimedia Systems. CMPT368 Introduction to Computer Music Theory and Sound Synthesis. CMPT461 Image Synthesis. CMPT464 Geometric Modeling in Computer Graphics. CMPT466 Animation. CMPT467 Visualization. CMPT469 Special Topics in Computer GraphicsComputing Systems. CMPT300 Operating Systems I. CMPT305 Computer Simulation and Modeling. CMPT371 Data Communications and Networking. CMPT379 Principles of Compiler Design. CMPT401 Operating Systems II. CMPT431 Distributed Systems. CMPT432 Real-time Systems. CMPT433 Embedded Systems. CMPT471 Networking II. CMPT479 Special Topics in Computing Systems. CMPT499 Special Topics in Computer Hardware. CMPT301 Information Systems Management. CMPT354 Database Systems I. CMPT370 Information System Design. CMPT454 Database Systems II. CMPT456 Information Retrieval and Web Search. CMPT459 Special Topics in Database Systems. CMPT470 Web-based Information Systems. CMPT474 Web Systems Architecture. CMPT373 Software Development Methods. CMPT383 Comparative Programming Languages. CMPT384 Symbolic Computing. CMPT473 Software Quality Assurance. CMPT475 Software Engineering II. CMPT477 Introduction to Formal Verification. CMPT480 Foundations of Programming Languages. CMPT481 Functional Programming. CMPT489 Special Topics in Programming Languages. CMPT307 Data Structures and Algorithms. CMPT308 Computability and Complexity. CMPT404 Cryptography and Cryptographic Protocols. CMPT405 Design and Analysis of Computing Algorithms. CMPT406 Computational Geometry. CMPT407 Computational Complexity. CMPT408 Theory of Computer Networks/Communications. CMPT409 Special Topics in Theoretical Computing Science. MACM300 Introduction to Formal Languages and Automata with Applications. |
SSDP1501 Systems Foundations 1. Application development, OOP, C#, Java, fundamentals of programming and program design. SSDP2501 Systems Foundations 2. Web-based applications, architecture, web design, principles, HTML, XHTML, CSS. SSDP3501 Systems Foundations 3. Medium and large-scale applications, dynamic web technologies, project management, relational databases, security issues of web applications. SSDP4001 Specialty Topics. Enterprise-scale applications, ASP.net, advanced Java. SSDP5001 Projects. Practical experience with an internal and external software-development project. |
IE535 Software Teamwork: Taking Ownership for Success. IE520 Introduction to Practical Test Automation. IE523 Agile Development Methodologies. IE527 Applied Practical Test Automation. IE507 Object-Oriented Methods: Object-Oriented Modelling and Development with UML. IE526 Principles and Components of Successful Test Team Management. IE503 Requirements Analysis and Specification: A Practical Approach. IE505 Software and System Testing: Real-World Perspective. IE504 Software Architecture and Iterative Development Process: Managing Risk through Better Architecturd. IE510 Software Configuration Management: Controlling Evolution. IE502 The Software Engineering Process. IE506 Software Project Management. IE509 Software Quality Assurance: More Than Just Testing. IE511 Software Team Project. IE525 Strategic Test Analysis and Effective Test Case Design. IE528 Testing for the Global Market. IE508 User Interface Design: Designing an Effective Software Interface. |
On Agile product design, I read:
If you tell someone about a great idea, and they say “That’s a great idea,” it’s not a pattern.
If you tell someone a great idea, and they say “Yes, we do something like that too,” that’s a pattern.
Exactly! That’s why I speak about Five Sketches™ at conferences and professional development sessions. And that’s why I post and write about everything I come across that’s similar to Five Sketches™.
Design Studio was the first undeniable indication that we’ve solved a problem that others in software development and web development are experiencing. That’s because the Design Studio method is very similar to Five Sketches™. Two completely separate teams, in different countries, came up with nearly the same solution to their respective design-process challenges. Design Studio was developed at Jewelry TV by Jeff White and Jim Ungar.
Here are some more methods and techniques that are similar to parts of Five Sketches™.