Posts

Posted on

The business case for design: ROI

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.

merholz-linking-elephants

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.

Posted on

Software UX/GUI design in education

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

What core competencies are taught?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.
Posted on

Validating your development method

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.

I do that, too!

Here are some more methods and techniques that are similar to parts of Five Sketches­™.

  • Low-fidelity generative design. There’s a huge benefit to exploring and evaluating a range of interaction concepts while involving both business and technology partners. This is, in effect, the divergence stage of generative design advocated by Bill Buxton, and done with low-fidelity. Adaptive Path does this with sketchboarding. Five Sketches™ does this by using mixed teams to separately sketch five ideas per participant, and then iterating from there.
  • Parallel design. This is supported research and advocated in the book of guidelines from Usability.gov. To ensure parallel design, Desiree Sy at Autodesk uses interns to prototype 10 or more design solutions to a design problem.
  • There’s much more that’s already been posted on this site. Use the Search box on this site to look for posts about generative design, design studio, creative hacks, Leah Buley, Bill Buxton, Scott Berkun, Jeff White, and Jim Ungar.
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

More usable features? You’d better design

Recently, I was brought in to assist a software-development team toward the end of its development cycle. In the preliminary discussions with the client, I talked about the benefits of doing design at the early stage.

“Oh, never again!” declared the customer.

“Oh no,” I thought. “This customer’s experience with design went sour.” So I asked a few clarifying questions, and—fortunately—it turned out I had misunderstood. The client had already learned that developing without first designing was less than ideal.

“Never again will I start software development without designing up front.”

development-schedule

The client learned this lesson the hard way, especially since the company wants to differentiate itself by providing customers with a more complete set of features that are also more usable than the competition’s. An experienced user-experience designer will tell you that to get more features and better usability requires a concentrated design effort.

Posted on

Unusable sinks on Boeing planes

Usability isn’t just about web pages, as you’ll know if you’ve tried to dial a phone number on someone else’s cell phone. Or if you’ve tried to wash your hands on most Boeing airplanes built in the past 30 years:

Taps with awkward levers

The water only flows while you press the lever—one lever for cold water and one lever for warm water. It takes one hand continuously pressing to make the water flow. Rinsing one hand without the help of the other hand is difficult. Rinsing soap off is much easier when two hands do it together.

Some of the newer Boeing aircraft—like the 787 Dreamliner—may have better taps, but I’ve never been on one. An aircraft lasts decades, so passengers will be using those old sinks and taps for years to come, on Boeing planes. Airbus planes, on the other hand, have had ergonomic taps for years: one press starts the water flow, leaving both hands free for soaping and rinsing. After a fixed duration, the water stops flowing, but you can always press again to restart the water.

While I’m pointing out usability problems in the airline industry, Airbus doesn’t have clean hands. On the Airbus web site,  type a word in the Search box—the word bathroom, for example—and then press ENTER. Nothing happens. The ENTER key doesn’t start the search, but a mouse click does.

Click OK to start searching

It’s ironic. A design that requires me to move a hand from the keyboard to the mouse is a lot like design that requires me to move a hand from the sink basin to the lever.

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

Cognitive psych in poll design

The WordPress community recently ran a poll. Users were asked to choose one of 11 visual designs. The leading design got only 18% of the vote, which gives rise to such questions as:

  • Is this a meaningful win? The leader only barely beat the next three designs, and 82% voted for other designs.

WordPress pollI don’t know about the 18% versus 82%. I do wonder whether some of the entries triggered a cognitive process in voters that caused them to pay less attention to the other designs, which may bring the leading design’s razor-thin lead into question. This cognitive process—known as the “ugly option”—is used successfully by designers as they deliberately apply cognitive psychology to entice users to act. I’ll explain why, below, but I first want to explain my motivation for this blog post.

I’m using this WordPress poll as a jumping-off point to discuss the difficulty of survey design. I’m not commenting on the merit of the designs. (I never saw the designs up close.) And I’m certainly not claiming that people involved in the poll used cognitive psych to affect the poll’s outcome. Instead, in this blog, I’m discussing what I know about cognitive psychology as it applies to the design of surveys such as this recent WordPress.org poll.

Survey design affects user responses

If you’ve heard of the controversial Florida butterfly ballot in the USA’s presidential election in 2000, then you know ballot design—survey design—can affect the outcome. I live outside the USA, but as a certified usability analyst I regularly come across this topic in industry publications; since that infamous election, usability analysts in the USA have been promoting more research and usability testing to ensure good ballot design. I imagine that the Florida butterfly ballot would have tested poorly in a formative usability study.

The recent WordPress poll, however, would likely have tested well in a usability study to determine whether WordPress users could successfully vote for their choice. The question I have is whether the entries themselves caused a cognitive bias in favour of some entries at the expense of others.

It seems that one entry was entered multiple times, as dark, medium, and light variations. This seems like a good idea: “Let’s ask voters which one is better.” Interestingly, the visual repetition—the similar images—may have an unintended effect if you add other designs into the mix. Cognitive science tells us people are more likely to select one of the similar ones. Consider this illustration:

More people choose the leftmost image. The brain’s tendency to look for patterns keeps it more interested in the two similar images. The brain’s tendency to avoid the “ugly option” means it’ll prefer the more beautiful one of the two. Research shows that symmetry correlates with beauty across cultures, so I manipulated the centre image in Photoshop to make it asymmetrical, or “uglier”.

The ugly-option rule applies to a choice between different bundles of goods (like magazine subscriptions with different perks), different prices (like the bottles on a restaurant wine list), and different appearances (like the photos, above). It may have applied to the design images in the WordPress poll. The poll results published by WordPress.org lists the intentional variations in the table of results:

  • DR1: Fluency style, dark
  • DR2: Fluency style, medium
  • DR3: Fluency style, light

The variants scored 1st, 4th, and 6thIn addition to these three, which placed 1st, 4th, and 6th overall, it’s possible there were other sets of variations, because other entries may have resembled each other, too.

As a usability analyst and user researcher, I find this fascinating. Does the ugly-option rule hold true when there are 11 options? Was the dark-medium-light variation sufficient to qualify one of the three as ugly? Did the leading design win because it was part of a set that included an ugly option? And, among the 11 entries, how many sets were there?

There are ways to test this.

Test whether the poll results differ in teh absence of an ugly-option set. A|B testing is useful for this. It involves giving half the users poll A with only one of the dark-medium-light variants, and the other half poll B with all three variants included. You can then can compare the two result sets. If there is a significant difference, then some further combinations can be tested to see if other possible explanations can be ruled out.

For more about the ugly option and other ways to make your designs persuasive, I recommend watching Kath Straub and Spencer Gerrol in the HFI webcast, The Science of Persuasive Design: Convincing is converting, with video and slides. There’s also an audio-only podcast and an accompanying white paper.

Posted on

Eyetracking: “I’m typical”

If you’ve ever wondered where exactly on your web site or software your readers or users are looking, eye tracking will tell you that. The eye-tracking equipment emits a specific wavelength of light (invisible to humans) that helps the eye tracker to follow your eyes. As the light bounces off your retinas and back to the eye-tracker’s camera, its software calculates where you were looking, and for how long.

There are different ways to display the results. You can see the data as a “video” that shows a sequence of dots, everywhere you looked. Larger dots are longer fixations. You can also see the data as a cumulative heat map, similar to this:

 eye-tracking

Here’s something interesting I learned about myself. When I participate in an eye-tracking study that studies a photograph—such as a full-page magazine ad—I look at all the same places for about the same duration as other participants in the study. I know this because the composite heat map, which combines the eye-tracking data of all the participants into one heat map, looks indistinguishable from my individual heat map. It turns out I’m normal, after all.

Eye tracking has helped researchers answer questions such as these:

If you’re interested in eye tracking and usability and want to read more, try Eye Tracking as Silver Bullet for Usability Evaluations?  by Markus Weber.