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.
There are 11 posts filed in Digital Service Design (this is page 1 of 1).
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.
New headquarters and cultural center for China Central Television. Design by OMA.
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.
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.
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.
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.
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…
Versioning: The Web 2.0 way of doing things is to release our work in stages, the public beta being a perfect example. If the beta is a big fail, we stop there and cut our losses, or we go down a different path of the decision tree.
Uncertainty: There’s a great deal of uncertainty in our work. Twitter, for example, is a big success, but at the cost of a very tricky technical challenge. Instead of an NPV model that would judge the value of the project to be either simply negative or positive, we can model this reality of “large audience / technologically expensive.”
Fast Risk Management: The ease of building betas makes it tempting to skip a big financial modeling activity, especially if it can’t accurately reflect (i.e. predict) how customers will react. Creating at least a simple real options analysis can save a lot of investment before building a beta that is hard to emotionally trash once it’s built. And while it’s tempting to say predictions are impossible so we should just run a trial, few managers with any P&L responsibility will invest in that.
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.
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…
we give them numbers or letters. “You see the change in materiality here in concept 2…” or “Clearly Concept C is a total paradigm shift…” But this kinda sucks. It’s hard to remember how the concepts map to numbers or letters, and that makes it hard for people to reference the concept. “Um, you know, I think it was the second one, the one with the thingie…” And if people can’t reference it, they can’t talk about it, much less buy it.
we only have one concept, so we name it after ourselves. “Our idea is to…” or “The Bixby Canyon Software System, from Bixby Canyon Inc., gives your plants just the right amount of water…” This feels good at first because you can publicize your company and concept name at the same time, and it avoids those messy, expensive naming exercises. But it falls apart when concepts grow up into products. Say when…
you want to change the product or the product name, but people keep referring to it by your company name. You’re stuck, or you change it and risk lose brand recognition.
you introduce a second product which means you now need three names, two product names and a company name, that need different identities. For a long time Symantec was synonymous with anti-virus software, and they had to work hard to be a company known for more than that.
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.
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.
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?