Tag: software design

Posted on

Last century’s disk-folder-file legacy

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:

  • Move photos from the camera’s memory card to somewhere else.

    • 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.

  • Use the digital photo frame that she received last Christmas.

    • 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.

  • Show her photos to her friend, Barbie, but she doesn’t know how.

    • 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.

    Photo and Fax Viewer

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:

  • How do I get here, next time?

Translated into Windows XP jargon, her question was:

  • How do I start Windows ExplorerWindows 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.

Posted on

Twitter whining or shared experiences?

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:

  • davidcrow tweeted “You can’t blame a guy for trying.” Ugh, you wasted 90 minutes of my day dude, and for trying to waste my time I blame YOU!
  • scottallen tweeted: RT @Mike_Wesely “Twitter has their heads up their butts” @replies still not fixed.
  • feather tweeted: To the girl on my left as I turned to swim back: you weren’t supposed to be there—your fault my hand went into your bathing suit, not mine.
  • sladner tweeted: Omnigraffle, what was life like before I met you? Did people really have to nudge objects using CTRL-Arrow?
  • dezign999 tweeted: Plastic container opener fail? http://twitpic.com/5y64d
  • TheDaveCarlson tweeted: sony email fail… i only need to send one. come on server!
  • jessmcmullin tweeted: I’ve never heard of a customer happy with Vaio support

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?

A tag cloud of words that appeared in tweets from 2009 that contained the words “Telus” and “phone”. The tag cloud was generated by the service ouTwit.me.

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.

Posted on

How many user personas?

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.

How big is the feature set? 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:

Posted on

Developers can learn ¾ of Design

Microsoft’s Bill Buxton recently wrote an article for Business Week, titled On Engineering and Design: An open letter. In it, Buxton explains that developers can improve the user experience of the product that they’re building by learning three of the four layers that engage designers:Four layers of design
  • Design awareness.
  • Design literacy.
  • Design thinking.

Buxton also mentions a fourth layer, design practice. He explains that design practice represents a fulltime job for highly trained professionals, and that it’s rare to find a developer who straddles both. (In my experience, small- and mid-sized companies may get by without a design practitioner, if their designs are constrained by the rules and standards of the operating system and hardware, and if their competitors do no better.)

Buxton thinks non-designers can easily learn about and appreciate the first three layers of design. On the third layer, design thinking, Buxton writes:

Cognitive science makes it clear that the strategies designers use in approaching problems or questions are different (not “better”) than those employed by those trained in engineering disciplines. Both strategies are complementary. Given the complexity of the problems that confront us, it seems to me that expanding our collective arsenal of techniques is something we could all benefit from.

This difference in problem-solving strategies is the ideation-judgement axis that I wrote about in Please exit your comfort zone. Learning to use these different strategies—at the right time in the design and development process—is what Five Sketches™ teaches to developers and other non-designers.

Posted on

Speed sketching vs. art/perfectionism

For a Five Sketches™ design session, I ask design participants to bring at least five substantially different ideas to the table, in the form of sketches. A common initial reaction is: “…But I can’t sketch!”

Many design participants believe they cannot draw. To be honest, I believe that about myself. People who feel they cannot draw tend to extend that belief to encompass design sketching, as well. However, I have learned to distinguish between drawing (below, left) and sketching a software design (below, right).

Drawing versus sketching

Software design does not require drawing, only sketching. From experience, I can tell you that sketching is easy once you realise that the goal is to produce only rough and low-fidelity ideas, not decorative and high-fidelity pictures.

Occasionally, I encounter a design participant who has trouble with sketching. I once had a participant who was so self-conscious of her sketching ability that she was paralyzed during the rapid iteration phase, when the design participants are quickly mashing up the sketches with borrowed and new ideas to produce additional sketches. I noticed that this participant was always busy—talking or wiping the board or replacing the snacks—but never sketching. This avoidance, and the underlying mental block, was an impediment to the whole team. Like all generative design processes, Five Sketches™ relies on its participants to saturate the design space with ideas. If a participant isn’t participating, it increases the project risk.

To pre-empt this mental block and to reduce the project risk, during Five Sketches™ training, I now introduce a quick speed-sketching exercise. Speed sketching is a race against the clock. With pen and paper ready, before each round, I give the participants five seconds to think, and then:

  • Speed sketching in seconds!10 seconds to sketch a cell phone.
  • 8 seconds to sketch a sandwich.
  • 6 seconds to sketch an airplane.
  • 4 seconds to sketch a ship.
  • 2 seconds to sketch a house.

After each sketch, the participants look at the other sketches. I ask them to identify the details that make the sketched object recognisable. There isn’t time to draw a high-fidelity rendering, so the sketches are rough and have few details.

Interestingly, with few details the sketched objects are still clearly recognisable. Participants learn that detail and fidelity aren’t needed. By the last round of sketches—the “2 seconds to sketch a house” round—participants have seen that everyone’s ability to produce sketches is about equal, and they usually conclude: “I sketch well enough for others to grasp my ideas.” Generative design requires lots of ideas—disposable ideas—not fancy drawings.

Jason Santa Maria says a similar thing in his Pretty Sketchy blog post, in which he declares that sketching is not about being a good artist; sketching is about being a good thinker.

Posted on

This sugar packet is a movie

Whether it’s ethnographic research, usability research, or marketing research, I’ve learned that the best insights aren’t always gleaned from scheduled research.

Here’s a photo of impromptu research, conducted by Betsy Weber, TechSmith’s product evangelist. I was her research subject. Betsy recorded me pushing sugar packets around a table as I explained how I’d like Camtasia to behave.

Jerome demos an idea to Betsy. Photo by Mastermaq

Betsy takes information like this from the field back to the Camtasia team. There’s no guarantee that my idea will influence future product development, but what this photo shows is that TechSmith listens to its users and customers.

The ongoing stream of research and information that Betsy provides ensures better design of products that will be relevant and satisfying for TechSmith customers down the line.

Posted on

Sketch, wireframe, prototype

Over the past month, I’ve come across the same discussion several times: “When designing a website or product, do you use wireframing or prototyping?”

The first part of my answer is: “Make sure you sketch, first.”

At the design stage, sketching, wire-framing, and prototyping are not equal. Sketching is useful at the divergent phase of design because it lets the design participants express and capture lots of different ideas quickly and anywhere that pen and paper will work. Nothing is as fast as running a pen across a sheet of paper to capture an idea—and then another, and another. And since sketching is intentionally rough, everyone can do it.

divergence-and-convergence

Responding to Œ the problem statement, first  saturate the design space with lots of ideas, and then Ž analyse and rapidly iterate them to  a design solution.

I also believe sketching is great for the convergent phase of design, but there are potential hurdles that design participants may encounter. It can be challenging to convey complex interaction, 3D manipulation, transitions, and multi-state or highly interactive GUI in sketches without learning a few additional techniques. This is unfortunate, because having to learn additional techniques reduce the near-universal accessibility of sketching.

The second part of my answer, therefore, is that “if you need to learn additional techniques to make sketching work, feel free to choose wireframes or prototyping as alternatives when there are compelling reasons to do so.”

I should point out that the three techniques—sketching, wireframing, and prototyping—are not mutually exclusive. Wireframes and paper prototypes can both be sketched—especially for simple or relatively static GUI designs.

There are no validity concerns with the use of low-fidelity sketches, as these readings show:

Posted on

Low-fi sketching increases user input

Here are three techniques for eliciting more feedback on your designs:

  • show users some alternatives, so more than one design.
  • show users a low-fidelity rather than high-fidelity rendering.
  • ask users to sketch their feedback.

To iterate and improve the design, you need honest feedback.  Let’s look at how and why each of these techniques might work.

Showing alternative designs signals that the design process isn’t finished. If you engage in generative design, you’ll have several designs to show to users. Users are apparently reluctant to critique a completed design, so a clear signal that the process is not yet finished encourages users to voice their views, but only somewhat.

Using a low-fidelity rendering elicits more feedback than the same design in a high-fidelity rendering. Again, users are apparently reluctant to critique something that looks finished—as a high-fidelity rendering does.

hi-fi_vs_low-fi_sketching

The design is the same, but it feels more difficult to criticise the one on the right.

Asking users to sketch their feedback turns out to be the single most important factor in eliciting feedback. It’s not known why, because there hasn’t been sufficient published research, but I hypothesize that it’s because this is the most indirect form of criticism.

Where’s the evidence for sketched feedback?

The evidence is unpublished and anecdotal. The problem with unpublished data is that you must be in the right place at the right time to get it, as I was during the UPA 2007 annual conference when Bill Buxton asked the room for a show of hands. Out of about 1000 attendees, several dozen said they had received more and better design-related feedback by asking users to sketch than by eliciting verbal feedback.

When you ask a user: “Tell me how to make this better,” they shrug. When you hand them a pen and paper and ask: “Sketch for me how to make this better,” users start sketching. They suddenly have lots of ideas.

My own experience agrees with this. In Perth, Australia, I took sketches from a Five Sketches™ design session to a customer site for feedback. I also brought blank paper and pens, and asked for sketches of better ideas.

Not surprisingly, the best approach is to combine all three techniques: show users several low-fidelity designs, and then ask them to sketch ways to make the designs better.

Posted on

Usability of a potential design

Three-quarters of the way through a Five Sketches™ session, to help iterate and reduce the number of possible design solutions, the team turns to analysis. This includes a usability analysis.

 generative-design-stage-3

After Œ informing and defining the problem  without judgement  and  generating and sketching lots of ideas  without judgment , it’s often a relief for the team to start Ž  analysing and judging  the potential solutions by taking into account the project’s business goals, development goals, and usability goals).

But what are the usability goals? How can a team quickly assess whether potential designs meet those usability goals? One easy answer is to provide the team with an project-appropriate checklist.

Make your own checklist. You can make your own or find one on the Internet. To make your own, start with a textbook that you’ve found helpful and inspiring. For me, that’s About Face by Alan Cooper. To this, I add things that my experience tells me will help the team—my “favourites” or my pet peeves. In this last category I might consult the Ribbon section of the Vista UX Guide, the User Interface section of the  iPhone human-interface guidelines, and so on.

[local /wp-content/uploads/2009/04/make-usability-checklists.wmv]

Posted on

Teamwork reduces design risk

It takes a range of skills to develop a product. Each skill—embodied in the individuals who apply that skill—brings with it a different focus:

  • Product managers talk about features and market needs.
  • Business development  talk about revenue opportunities.
  • Developers talk about functionality.
  • Usability analysts talk about product- and user performance.
  • Interaction designers talk about the user experience.
  • QA talks about quality and defects.
  • Marketing talks about the messaging.
  • Technical communicators talk about information and assistance.
  • You may be thinking of others. (I’m sorry I’ve overlooked them.)

What brings all these together is design.

Proper design begins with information: a problem statement or brief, information about the targeted users and the context of use, the broad-brush business constraints, Design as a teamsome measurable outcomes (requirements, metrics, or goals), access to a subject-matter expert to answer questions about the domain and perhaps to present a competitor analysis.

Design continues by saturating the design space with ideas and, after the space is filled, analysing and iterating the ideas into possible solutions. The design process will raise questions, such as:

  • What is the mental model?
  • What are the use cases?
  • What is the process?

The analysis will trigger multiple rapid iterations of the possible solutions, as the possible solutions are worked toward a single design:

  • Development. What are the technical constraints? Coding costs? Effect on the stability of the existing code? Downstream maintenance costs?
  • Usability and experience. Does the design comply with heuristics? Does it comply with the standards of the company, the industry, and the platform? Does paper-prototyping predict that the designed solution is usable?
  • User experience. Will the designed solution be pleasing due to its quality, value, timeliness, efficiency, innovation, or the five other common measures of customer satisfaction?
  • Project sponsor. Is the design meeting the requirements? Is it reaching its goals or metrics?

It’s risky to expect one person—a developer, for example—to bring all these skills and answers to the table.  A team—properly facilitated and using an appropriate process—can reduce the risk and reliably produce great designs.