Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Follow us on Twitter
Steve Calde
Steve Calde
Steve Calde is a Principal Design Consultant at Cooper, where he's been helping to make the digital world a safer place for users since 1998. Steve has worked on design projects in diverse domains such as golf course irrigation, IT administration, online
You're only a first-time user once
We’ve all got our own personal benchmarks for what makes a good user experience. My personal list includes a few: Does it delight me? Will I recommend it to my friends and colleagues? Would I have used the same approach if I had designed the product? I’ve found among some product executives one particular pattern for this subjective evaluation criteria that is both humorous and troublesome: “Would my mother/grandmother/Luddite Uncle Bill be able to use this product on the first try?”
While there is a sort of noble aspirational quality to this kind of thinking—let’s make everything so dead simple that any person can use every product—it also sets the bar for the experience rather low. I imagine a sea of step-by-step wizard dialogs that target the lowest common denominator and force everyone else to step through the same predefined (and very explicit) experience. If I’m designing a product for people who have specialized knowledge, I want to leverage that knowledge in the product. Why force people to walk when they can run? I’ll want to provide these people with clear, appropriate pathways through the product, but I also want these specialized users to be able to forge a variety of their own pathways through the interface, dependent on the specifics of their situation or how they want to do things.
I once worked with a client to design an intravenous medication delivery device called an infusion pump. This is a machine that nurses in hospitals use to administer drugs to patients by attaching a bag of medication to the device and specifying delivery parameters such as how long and how fast to dispense the medicine. This is critical stuff; the consequences of a mistake could be catastrophic.
Does your persona eat twinkies?
I recently stumbled across an article about personas written by Andrea Wiggins late last year in Boxes and Arrows. Wiggins does a nice job talking about how personas can help the design and development process, and some approaches for creating a good persona set. But what really gave me pause was the title: “Building a Data-Backed Persona.” Data-backed? Wait a minute…is there any other kind?
Communicating Design Concepts Without Getting Skewered
We have a saying around the office: "If you can't explain the design, it must not be right yet." It's a reminder to designers to not get so caught up in idea generation and specifying details that we lose sight of creating a coherent big picture for the design.
We need to exercise the ideas we generate by articulating them coherently; chances are high that if we can't describe our "great idea" with clarity, it's not such a great idea, after all. It's amazing how many design ideas seem just dandy on the whiteboard, then deflate like a punctured balloon when poked at with the sharp pencil of design communication.
Myths and Measurements: Evaluating the ROI of Design
There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product…without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.
But just because you can construct software products without designing them first, why on earth would anybody want to?
The analogies are endless: you wouldn't point a construction crew to an open lot and tell them to build a structure without giving them blueprints, would you? You wouldn't ask a doctor to re-set a broken bone without looking at an x-ray; you wouldn't storm the beaches of Normandy without a battle strategy and a good map; you wouldn't even don your shoes before putting on your socks.
Executives chuckle warmly at these analogies, and agree wholeheartedly that yes, it's always best to design products—the things that their companies sell for money—before building them and putting them in the hands of customers. Yet even though business decision-makers of all stripes acknowledge the merits of design, it's the designers and usability professionals who are the first to get jettisoned from a project plan when the going gets rough.
Using Personas to Create User Documentation
Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.
Using personas to guide your user-documentation creation-process helps you:
- Determine the primary and secondary audiences for your documents
- Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
- Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features.
Technical Writing and Interaction Design
Technical writers are oft-forgotten constituents in the product development cycle. Although they are rarely tasked with participating in product requirements definition and product design, technical writers are in a unique position to affect product design. However, they will find that subtlety and subterfuge are sometimes necessary to make a politically correct impact in an organization that has not embraced interaction design as a formal part of the development process.
Technical writers and interaction design
When I started my career as a technical writer in 1992, interaction design did not exist as a stand-alone discipline in a product development organization. My role in the development process went something like this: early in the development process, I made a documentation-effort time estimate based on some vague, high-level requirements provided by a product manager. Months later, development would finally distribute an early internal release, which only faintly resembled the initial requirements definition. The technical publications team would revise our time estimates and scramble to start documenting the software. Once a week, the development team would release another internal version of the software—which might or might not resemble last week's release—and so on.
Critic to Creator: Recognizing Good Design
Someone always asks the question, and I am never ready for it.
"So, what products out there are well-designed?"
As an interaction designer, I learn about users and design a product that helps them meet their goals—one that is tailored to the way they work. Yet this question can still stump me. I am not alone: all too often, people in our field focus so much on pointing out the egregious interaction design mistakes that make it to market, we forget to pay attention to the good design that exists. Not only does it make our profession look bad if we are always complaining, but it also makes us less effective. How can we create good products if we can only articulate what “bad” is?
Design Research: Why You Need it
Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? The story goes like this: Product is introduced at show to much fanfare. News media gives Product lots of press, and consumers everywhere express interest in Product's features and capabilities. Product hits store shelves…and stays there. Some early adopters purchase Product, but it never penetrates into mass consumer markets.
What went wrong? Market research clearly identified potential dollars in target markets just waiting to spend money on the new product. So why did it fail?