This is a book in progress, posted in bits at a time and probably published in another form when it’s done. I started it to help the many designers, marketers, and programmers that want to add to their skills the business knowledge that’s useful in developing digital services. I appreciate hearing your feedback.
I’m finally in a position to use much of my design and business experience and thinking, as well as facing challenges where I have no experience. And the situation is causing me to question much of what I knew about how to effectively deliver design consulting.
In short, there’s a lot of blah blah blah in our industry, and little knowledge and practice of what actually works. And now that my ass is on the line to make something work, the blah blah blah gets no attention from me.
.
Concepts strive to sway opinion by eliciting emotions. Fundamental to this purpose is the new, the aspect that is beyond question different than what has been done in the past. The new is what causes the audience to pause and react.
This reaction can be polarizing (yes/no, this/that) in order to make progress toward a detailed design. This reaction can be stimulating, sparking new ideas to increase the number of possibilities. Effective concepts are carefully constructed to appeal to particular emotions.
Boredom is the enemy of design concepts.
That’s right, Alex Osborn started popularizing brainstorming in the late 1930’s. It’s a classic tool I still use, but I have to wonder if there’s something better.
Brainstorming is simple, and I would bet this simplicity is the key to its popularity. Yet even the basic rules that Osborn set out aren’t very common. Brainstorming is too often reduced to sitting around a conference table discussing a topic rather than storming an objective.
I tried a little experiment with my Business & Design students tonight, introducing them to three different idea generation tools: brainstorming, “yes, and…,” and question the brief. Brainstorming and Yes, and… were slow and stiff. Part of this is probably due to my skill as a facilitator, but I also think these tools require some experience to use proficiently. I liken it to building muscles; it takes some time doing it to see results.
Question the brief, on the other hand, more easily generated plenty of usable ideas, and there were even some explicit comments preferring this method, so that we returned to it. My theory is that it’s simple enough to remember but has just enough structure to produce specific kinds of ideas. That’s a balance I’m going to seek with my other concept design tools.
See also my concept design page at Smart Experience.
The nice folks at Digital Web Magazine published my new article on Concept Design Tools. It’s already received some nice reviews in the Twitterverse…
For those of you who haven’t seen Victor Lombardi’s new article on concept design tools, it’s a must read…
…it’s brilliant stuff and super accessible. It’s great to see solid thinking around the topic. There isn’t enough of it.
…great article on concept design!!!!
Here’s some reactions from bloggers I keep hearing over and over, confirming why I think this topic is important for digital designers. Steven Clark asks, Where is the breadth of our design?…
where is our design process preceding the implementation phase? The moment we receive the brief we’re practically falling over ourselves to push forward, and implementation seems to go on at the same time that we’re figuring out what the product should do. This is as applicable to web solutions as to applications, we jump in boots and all with predetermined assumptions.
And Martin Belam writes…
One strong theme that came out of it for me personally though was that, unlike industrial designers, when we make web applications and sites we tend to rush to wireframes and ‘colouring in’ before we have explored multiple potential solutions. Victor’s championing of questioning the brief looked like a good way to try and break out of that vice.
Since writing it I’ve already discovered similar work that’s been done over the past several decades. My approach is different in that the tools are simple and fast enough for any designer to use without having to learn a lot about method, but I will be spending some time with the masters to learn how I can climb onto their shoulders.
The common way that financial people will judge the potential value of a project, or a design concept representing a potential future concept, is by building a model, usually a discounted cash flow model like Net Present Value (NPV). The calculation essentially asks, if we do this project and gain the profit we think we’ll gain, how much is it worth to us right now? That way we can compare it against our other options.
The problem with these models is that they assume the world doesn’t change. The model tries to predict everything that will happen in the project from beginning to end in order to arrive at a single numerical value. But in the technology world, there’s lots of change.
So peeps at the forward edge of product and service development have started using real options to value projects. Real options essentially breaks the project down into a series of decisions. At each decision point a number of outcomes can occur, and for each outcome there’s a probability it will occur. There’s also a revenue associated with each outcome that we receive if it occurs. By multiplying the probability by the revenue we get the value of the option.
This is often illustrated using a decision tree, as with this analysis of a drug in clinical trials…
What’s the big deal? It turns out this is a better way to value investments in Internet services for at least three reasons I can think of off-hand…
Real options isn’t a perfect technique, however. Proponents claim it supports decisions with “mathematical certainty,” but the probabilities are derived from managers’ experience and judgment which is subjective and imperfect. Getting a group of people to agree on the probabilities may be difficult, and once a project is up and running a team may be unwilling to revise their estimates downward to reflect new information, much less kill their own project. Still, for the kind of work we do it’s better than the old ways.
References:
When you create a product or service concept, you should give it a name. Sounds like a no-duh idea, but in the heat of the moment we forget to do this. Sometimes…
An exception is when you (intentionally or not) have a naming system. Let’s say your company and your first product name is Super Fantastic. When the next product arrives, you name it Super Amazing, then Super Stupendous, and so on.
Just as you wouldn’t have a baby (or a company) without naming it, don’t birth a concept without naming it either.
In my research on concept design processes, I’ve come across two ideas that jumped out as vital behavior that differentiates expert designers from novices.
The first comes from Nigel Cross of Open University, UK, who seems to have studied designers and their processes more than anyone I’ve come across. In his Expertise in Design (pdf) he says (emphasis mine)…
Novice behaviour is usually associated with a ‘depth-first’ approach to problem solving, i.e. sequentially identifying and exploring sub-solutions in depth, whereas the strategies of experts are usually regarded as being predominantly top-down and breadth-first approaches.
While the protocol studies he cites contradict this, when it comes to digital design I find this explains why I see so little concept design these days. Both product developers and designers have a tendency to jump on the first great idea they generate and head down one path, instead of patiently exploring the space of possible solutions. The pain is only felt far down the line when development makes it obvious what doesn’t work and what could have been.
The other big idea comes from How Designers Work, Henrik Gedenryd’s Ph.D dissertation. In the third section (pdf), he observes how designers go about defining the problem to be solved, the most difficult part of the project. How the problem is defined can determine the success of the succeeding design task…
…the two contrasting attitudes make the whole difference between frustration and progress: Quist literally makes his problem solvable, whereas Petra finds herself stuck. The bottom line is that Quist who is the “expert” is acting as a pragmatist, whereas Petra, the “novice”, acts as a realist. And as we have seen, this accounts for a great deal of his superior performance. The choice of either position is not merely a matter of ideology, but has important consequences.
In short, experts are pragmatists, they re-set or re-frame the problem to make it solvable. Novices are realists, they take the problem as a given and get stuck.
Here’s a story of how someone might wind up needing this book, and a one-page overview of it all.
I recently went looking for and failed to find the book I think so many of us would appreciate and enjoy right now, one that captures the excitement, the emergent processes, and the innovative techniques for designing digital services, particularly for the Internet. There are great product development books, great Internet strategy books, and great books that describe the nuances of design and marketing and programming. But there’s nothing like a primer or a manual that helps the majority of people in the field grasp what the process is like to design a service the way the best Web 2.0 companies do it.
That’s what I hope to create. I’ll post pages here, a few at a time. As always, your comments are appreciated.
I’ve been doing a lot of “writing” lately, but in an attempt to emulate great, bestselling computer books that are highly visual and concise, I’ve been thinking about layout first and writing second, because we want to learn and not necessarily read. I’ve started mocking up the piece on index cards to get a feel for the flow of content. As it turns out I’m not the first to go this route…
…pretty much every page of every Head First book first exists as a scribbly drawing on paper before it ever makes its way into page layout software. Same deal with my book. In fact, my entire book was written on paper in pencil before I ever laid out a single page electronically. That version of a Head First book is known as storyboards, or boards for short. The idea is that you sketch up the core visual elements of each page in the boards. And by steering clear of software layout tools with fancy visual effects, you’re forced to stick within the realm of concepts. No characters, no cute graphics, just core visual concepts and whatever your artistic ability can muster. It’s all about focus.
Here’s some of the principles behind the Head First Formula:
It’s about making books fun. In some ways, it’s about making adult’s books more like children’s books.
Kathy Sierra expands on these ideas in the below interview. Some key points:
The responses to my question about your favorite books on innovation were so interesting and useful I can’t help but ask another:
Let’s say you’re a manager charged with developing a software-driven product or service like a website or a mobile service. You already have staff to handle the interface design, programming, and marketing. But you need to figure out a process for creating the product, a process with activities like generating ideas, creating conceptual designs, analyzing business factors, working with partners, etc.
Do you have a favorite book on this topic? And by the way, what term do you use to refer to this?
Again, I’ll start with mine…