Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
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 radio, enterprise resource management, intravenous medication delivery, telecommunications, and more. Steve also teaches Cooper's Interaction Design Practicum and Communicating Design courses. In a previous life, Steve was a technical writer.
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?
Email it to us and we may answer it in an upcoming article.