This was originally published at my company blog but I am reposting here as I thought some of you might be technical enough to understand, and not otherwise care to read the company blog. This is what I do, from the point of view of design for technical systems.
If you have a solid comment, try to stick it up at the original location, so I get credit for pulling traffic in :)
I am a designer, so like I guess a lot of people become accustomed to their job, I take the role of design for granted. When challenged, it's often a bit hard to figure out what it really means and say that clearly, without self-referential language.
Sometimes it's easy to use analogies, or quotes. Some years ago, as low-end clones took over the laptop market, some tech writer or other said, approximately, "Apple (and to a lesser degree Sony) design laptops, all others just assemble them."
I always liked that one, and even just said it the other day while trying to explain our role in a particularly large and high-speed process. But that is a bit overstated. Probably in ways that aren't helpful. Among other things, I think it leaves out some key job functions between design and assembly.
While there are many, many facets and phases to bringing any particular technical product to market, it might be best to consider three:
Design > Specify > Execute
I think we all know what is involved in specifying. Lists of materials, business rules, functional requirements, pricing models, data structures, storage, network access, and so on.
But already there is a problem. Specifying is not defined by these goals or documents. It can be generally defined as detailing what specific things (behaviors, features, buttons and materials) will go into the product, in what manner, based on known preconditions, and desired end states. Specifying involves finding an acceptable way for a system to work, and documenting it.
Designing also has tasks, and often the exact same tasks as specifying. But when you get to the core definition of how design works, the overriding principle is that design does not assume anything about the pre- and post-conditions of any one feature. Design considers, ... well, actually still the pre- and post-conditions, but those desired for the whole experience, from packaging to product to use, and how those are related to the needs of the expected users.
[Ed. Note] And "design thinking" is the practice of brainstorming many many options for the system, collecting concepts, and assembling the ideas into a small number of concepts to explore. Amusingly, in my design education there were two classes on this, called "ideation", and the rest was the sort of problem solving and communication described here. — Barbara
Design for Marketing, and People
Consider for a minute something that a lot of people tend to confuse with the type of design I do, marketing and segmentation. A lot of folks seem to think that design for products (and usability research even more so) is some sort of glorified version of deciding which market segment to appeal to. But that marketing – without design input at least – simply creates those assumptions, and the result is marketing-driven specifications. "Colorful and fun, for children" or "Language to appeal to the teen market" or "Must meet $129.99 price point" are all things I have seen result from marketing-driven specification.
These may be fine to kick off a project concept and get funding, but they are not design goals because they do not drive the overall approach to the product. As one example, talking in a teen manner – even when executed well, which is difficult and rare – is always a failure if nothing else changes about the product. And I don't mean "cool teen graphics," but the tasks available, the manner in which they are approached, the integration with other products and services which engage the audience already, and really the entire experience. Design (at least design for user experience) focuses on behaviors more than demographics and fads.
Design for Processes
Design is not in opposition to marketing, nor does it supersede marketing. And neither does design override or disagree with the specification people or processes. Instead, it works hand in hand with all of these phases.
Design, at least the way I do it and write about it at great length, supports marketing, by looking at the perceived needs, the competition, and the users, then creating personas, design goals and other deliverables to help everyone understand the true needs and limits of the product.
Design supports specification by, first, the creation of these goals and understandings; the key assumptions about the product become more clear, consistent, unambiguous and defined. But we also typically perform the traditional task of design and draw things. Rough, conceptual things, that can often be turned directly into specifications.
Just the other day yet another analyst came to me, shocked that the annotations to the side of my drawings were in his language. He simply copied many of them into the requirements document. This is not fortuitous or incidental, but entirely intentional; it is what we do to best support the process, and the specification people to get the product built on time.
Design for Execution
To the last phase of the miniature chart we started with, "execute" in traditional models accepts specifications, and builds (whether with CNC mills or code) the product. But even here well-run design processes can add value and reduce troubles.
Execution-phase people – developers, architects, tool and die makers, QA, etc. – are not robots. We're not talking about the assembly line, or the webserver, but about the people who build that. And they are people. And products are complex, so pretty much cannot be specified perfectly (or, alternatively, cannot be held in a human's brain when sufficiently specified). An absolute, rules-based system does not work, and there are gaps, cost over-runs, errors and rework.
If you are lucky. If not, there are missed deadlines and angry customers. Or no customers. Design can hold a role in documentation, even. A simple way is to carry those early goals created with marketing through the rest of the process. But the documents can be designed as well, to appeal to the needs of the execution teams. And to express the broad vision, and core needs of the product as something inherent to the specification and design documentation.
Aside from creating all my own design documents like this, at Little Springs we even get work on projects that are about nothing but re-designing and re-writing complex, reusable specifications documents.
Design and You
While this is what I do, it doesn't mean pretty much everyone can't do it. One of the biggest drivers to being a good designer of technical systems, aside from the usual good-work-ethic stuff, is internalizing the process and having enough knowledge of the domain. I am better at designing mobile interfaces and account management systems, because that is where my design experience lies.
You could get there also and empower your processes with a design mentality, but I do think "Design Thinking" with capital letters, as espoused by management process types, misses the mark rather widely. Not sure where that came from, but as an art school graduate, designer for years and process-oriented guy, it makes not a damned bit of sense to me.
[Ed. Note] I think design thinking is about "getting the right design" and Steven's discussion is about "getting the design right." Both are necessary. — Barbara
Among other things, design does not have to be "designy." It's not clean lines and pretty colors. Good factories have well-designed processes, but (at first glance) looks like pretty much all other factories, and not like utopian Sci-Fi future factories.
Design can be informed by creativity and aesthetic and even opinion, but I believe this is not what it is at its heart. Design is about looking at problems, or the world, Holistically (other keywords, like Systems Thinking also lead useful places). If your project seems bogged down in minutiae, hire a designer who thinks like this, or back up and try looking at the problem anew, without its initial assumptions.
Consider how your product lives in its world, and how it changes the lives of the users, and how it changes their interaction with the world.
No comments:
Post a Comment