 |
« | Week of Dec 14 | < | Individual Entries | > | Week of Dec 28 | » |  |
 |
 |
A Note on Terminology
design, language, usability
December 26, 2003, 12:31 AM
As I was writing my post yesterday, I wanted to add a note on my usage of a few key terms here on this weblog, to clarify any possible confusions that might arise.
When I use the term design in reference to software systems, I am sometimes referring to interface design, i.e. the form and function of the portion of the software system that the user of the product sees and interacts with, and sometimes referring to internal design, the structure and specifications of the logical components that power the behavior of this interface. Although I recognize that this is generally a useful distinction to make, I tend to view these two disciplines as different aspects of the same activity. There is no question that the two influence one another. Because these two concepts are blurred in my mind, the word I use for them is fairly blurry as well. For the most part this is intentional.
Secondly, I tend to use the term usability rather more broadly than others do (or so I've found). It's convention in the field to make a distinction between "useful, usable, and desirable" as quality characteristics of software systems (and many other systems, as well). Useful refers to whether the software does what the user needs it to, usable refers to whether he can learn and remember how to use the software, and use it efficiently, and desirable refers to whether he wants to use the software. I often find this distinction silly, since there's so much overlap between these three concepts, and thus I tend to lump them all under the moniker "usable", i.e., to what extent can people use it? I've already argued that all software quality attributes reduce to usability. Now I feel like I need to argue that all usability attributes reduce to usability (which strikes me as a bit silly).
Finally, I have no good word to refer to the group of people who are members of the broad profession that aims to design products and systems for use by human beings. The general term for this discipline is often "human (or user) centered design" but the term "human-centered designer" often isn't seen as applying to user researchers, UI programmers, etc. who aren't necessarily designing an interface. But no other word will do. "Usability person" tends to get rejected by the designers. There are a plethora of more specific terms (interaction designer, information architect, interaction architect, UI designer, interface designer, user researcher, usability specialist, "gooey" (from Yahoo), user tester, usability engineer, usability professional, or generate your own) My friend Dana made up the word "usable" but nobody seems too fond of that either. So I might use any sufficiently general-sounding term to refer to the whole lot of them, until one emerges that everyone can agree on.
I don't believe that any of these issues are idiosyncratic to me, but rather reveal some inherent ambiguities in the way we talk about these things. However, this post should be taken as more of a clarification than a complaint. Ambiguity in terminology is confusing, but inevitable. Human language is riddled with ambiguity, which is part of what makes it such a beautiful and powerful thing. Some of the ambiguities I've pointed out above are (in my view) necessary, and I have faith that the others will sort themselves out in time.
A Systemic Problem with Software
design, software development, systems
December 24, 2003, 11:33 AM
One of the core themes you'll find running through this weblog is an approach to analyzing problems from a systemic perspective, that is, an approach that examines the structure of the larger systems these problems exist to gain a deeper understanding of their causes. Recently I've been thinking about systemic problems in software design, and I wanted to articulate the one that's especially jumped out at me.
First off, lets assume a world in which all our dreams have come true. Human-centered design is the norm rather than the exception. Efficient production and distribution models have arisen for software design and development, and the market is perfectly in tune with the needs of its end-users. Sadly, the following problem would still plague us.
Here's the crux of it:
- Designing good software requires maintaining a strong focus on a small, well-defined user group. Cooper makes this argument, and it's pretty well-known to anyone who has done serious interface design work. Different people have different needs, and any interface that tries to be too general, that tries to do everything for everybody, will only wind up being mediocre (at best) for many, and completely unusable for the rest. Feature creep and the complex, inelegant interaction designs that inherently accompany it will see to that. This is partially why Word and Windows suffer from so many usability problems; they are trying to satisfy too many disparate user groups.
- But people need to work together, so their software must work together too. Users need to exchange documents, send each other messages, work collaboratively on the same artifacts, etc. If they software they use doesn't support this, it cannot fulfill their goals.
- If people have different software, this creates an interoperability problem. Different software systems, especially those made by different companies, are notorious for causing problems with interoperability, from the old issues with opening Wordperfect documents in Word to modern problems with viewing web pages in Safari that were created for Internet Explorer.
- There will always be tension between focused design for usability and generalized design for interoperability. Often, the result of this situation is that natural monopolies get created in the software market, such as Microsoft. One company produces a "one size fits all" solution that everyone uses to avoid the problems with interoperability, but which fails to fully satisfy anyone's needs.
So what can be done about these problems? One option is to explicitly design software to interoperate with other software, which I've discussed before. But it's hard to design two pieces of software so that they communicate together effectively, even when you have full control over both of them. And designing for connectivity with all the software your customers might potentially be using quickly creates an exponential complexity problem.
The obvious solution is to define software standards and design to conform to them. However, we know that usability is not screen-deep, so these standards may put limits on the usability of the final products. Ideally, the standards should be developed while following a user-centered design process as well, but here we come back to our original problem; standards by definition must take the needs of many user groups into account, which is inherently difficult to design for. What usually happens is that standards arise from the experience of many product development efforts, and attempts at standardization that occur too early fail as vendors ignore them in favor of adding proprietary capabilities to their software to fulfill their customer's needs.
I don't see any obvious way out of this messy process, dictated by the structure of software design and development. My guess is that firms must do the best they can in the particular situations they find themselves in, and work to enhance the standardization process so that less time is wasted discarding inappropriate standards.
Email Rob:
Email Rob: