January 2008 – Page 5 – Ghost in the Pixel

On design process…

I must confess–I find it amusing when people talk about “the” design process as if there were one final absolute ultimate standardized process that always guarantees success. Hmmm! Even I’m not sure what that really is! In my mind there exist multiple flavors of a general “ problem identification/solution creation ” process or methodology, with different steps depending upon the company, industry, and individual characteristics of the designer, as well as personal range of experiences, and evolution of preferred methods.

Fundamentally a design process features cyclical iterations. Not just iterations for the sake of iterating, but towards resolution, winnowing down multiple possible options (hypotheses) to get to the optimal/sufficient/viable solution for a given problem. It’s also cyclical–there’s a 360 degree revolution from start to finish, then starting again with different problems and situations (that may have emerged while investigating the initial issues, for instance). Or you may have to hop back up or jump ahead to other steps per emerging information or changing circumstances. It’s this fluidity and dynamism that I realize confounds non-designers (i.e., engineers and product managers). It’s not a recipe, nor a formula.

Also there’s something else that is difficult to pin down and quantify but must be accounted somehow: that serendipitous spark of brilliant creative insight, often expressed in terms of aesthetics but also it could be clever mechanics or nifty usability or a compelling story of use. To outsiders this must all seem quite confusing, chaotic, or even a bit mystical. Yet there is actually a general overarching pattern and structure, moving from problem to solution.

Here’s my take on the major phases of my particular flavor of “the design process”:

design process diagram

Understanding: a phase for becoming deeply informed about the users, market, industry, domain, competitors, as well as learning stakeholder concerns, issues, values, goals, etc. and ramping up on existing products if available. This will help identify the core problems and shape the personas, scenarios, and overall problem scoping. This is paramount. If you’re not solving the appropriate problems, then the entire design effort is in jeopardy. What is meant by “appropriate”? Depends upon the user, context, goal, task, etc. :-)

** Verify your personas and scenarios with real users and other stakeholders to ensure accuracy. (like the old adage, “trust but verify”)

Modeling: a phase for articulating the pieces that help in later design work, mapping out the objects and data/tasks/flows in the product or system, modeling the main workflows and tasks, and laying out the overall architecture of content and functionality.

These result in analytical artifacts, mostly diagrams for starting critical conversations and getting initial consensus and understanding/agreement from major stakeholders about the skeletal frameworks for the product (especially true for digital designs, web apps, software, services). Architectures are key here too: screen architecture, content structure, etc.

** Assess your models with Product Managers and Engineering leads for completeness of capturing and representing all the relevant tasks and objects and functions, etc.

Visualizing: a phase for actually designing possible solutions, with hand sketches, wireframes, mock-ups and prototypes all done as needed to help identify which options work best for your particular situation.
** Evaluate the visualizations (of whatever fidelity level) with your users via usability tests to catch usability problems, missed features, etc.

Hopefully issues of flow and architecture have been resolved by this stage, but more likely they will be often revisited as greater fidelity of the solutions emerge, especially at the prototype level. There needs to be a general understanding that phases can and often will need to be revisited but this should not be considered “failure” or “wasting time”. It’s all part of the practice of designing!

However, excessive re-addressing of design solutions should be avoided with the help of early upfront activities and artifacts like personas, scenarios, flows, and other items which help identify major requirements and so forth.

And as for that spark of creativity…personally I believe that true designers are always sketching and thinking and writing, jotting down options and alternatives, even when a phase isn’t “done” yet. Or if you’re leaping ahead downstream, that’s OK too. Naturally thoughts and images come to mind, just jot them down. Try things out. Sketching is a great way of probing and reflecting upon issues, just visually. It’s a way of freeing up your mind and getting ideas out there. A lot of it is just statistical: it often takes tons of ideas to get to that good one. So keep generating even while researching and meeting with stakeholders and drafting models/architectures. Developing this habit early increases the creativity potential (as well as open whiteboard brainstorming sessions with stakeholders), so I think it should be folded into “the process” from the beginning and doesn’t become a mad rush at the end to conjure up “the solution”.

So in the end, for me a well-thought out and compelling design solution results from informed understanding + personal ingenuity/creativity + collaborative inputs + technical viability + commercial value.

(I will most likely re-visit this equation, many times! :-)

What drives a designer?

Problems. And a passionate desire to improve upon problems found anywhere.

But to elaborate more on that…I think there are at least two (and certainly more…coming soon!) critical factors that shape the kind of designer you are.

1. The questions: Do you like to ask questions about the user? About the technology? About the business? Ideally all of them, but I’m betting that some designers are more naturally inclined in one orientation than others, which is fine. Also, do you like to ask tactical questions of construction and production primarily? Or more strategic questions about the product lifecyle, platform, ecosystem, etc. Or perhaps conceptual questions proposing hypotheticals, that drive research imperatives and foresight activities?

Just as Trinity told Neo in the nightclub in The Matrix: “It’s the question that drives you.” So what question burns in your mind? That more than likely shapes type of designer you are or strive to be.

2. The artifacts: What do you like to make? What artifacts from the design process do you naturally gravitate towards or have affinity for? Do you like the flows, diagrams, models, and maps? Or getting into the pixels and code? Or maybe somewhere between? Hopefully not excel spreadsheets! :-)

3. (possibly third one) Users/domains: What kind of domains and situations and users do you like to design for? Enterprise? Consumer? Mobile? Medical? Again, no right answers, just something to reflect on for yourself in terms of what challenges you as a designer and gets you excited, what you naturally gravitate towards, and keeps you thriving.

Multiple hats at work

As a designer at work, there are multiple hats to wear, each of varying size and weight and flavor given the situation at hand. Here’s a quick sketch of what I think are the major roles of a designer:

1. Advocate: a designer must primarily serve as the advocate for the user/customer, defending the usability and desirability of a design in accordance to the user’s values, goals, and context. This however, does not mean the designer is simply beholden to all user requests or a puppet for customers paying big license fees (as is often the case for enterprise software vendors). It simply means the designer has a responsibility to ensure what is being decided and designed is in the best interest for targeted users.

2. Educator: a designer must often evangelize user-centered thinking and design processes and methods and tools, to help cultivate self-sufficiency for clients (if you’re a consultant), and get stakeholders on your side, understanding the value you bring as the designer.

3. Facilitator: in working out agreements and settling on designs, the designer must often facilitate discussions between engineering, product management, quality control, documentation, and other parties as needed. Some days at work, that’s all you might do! And it’s very valuable, to serve as that therapist or enabler of tough decisions, or draw out the real reasons certain features exist, or why a design option is not feasible.

4. Coordinator: because of the uniquely holistic, strategic, humanistic perspective designers bring to a problem, they are the best at seeing how different pieces of a product may not be well-connected, thus pulling together different parties to get them to realize those dependencies. A designer can help lead those revelatory moments, coordinating team discussions and facilitating them (see #3 above).

What is meant by “product”?

In CMU-speak, a product can be a lot of things. It has a very broad, liberal interpretation, referring to anything artificial, material or immaterial, resulting from deliberative human effort and planning, not just a piece of hardware or physical gadgetry for sale.

A product thus, in this sense, can be any of the following:

A map
A poster
A physical object
A website
A software application
A network device
An electronic gadget
A user interface
A complex system
A web-delivered service
A business process
An environment
An organization
A course syllabus, even!

When you look at the possible range of what could be a “product”, you can see there’s an extraordinary range of possible arguments and forms of rhetorical communication, as well as methods of thinking to solve their inherent problems. Each of these product types is a potential argument requiring different ways of handling them and presenting them to people. It should also be apparent that each one of these product types embodies a flavor of interaction design thinking, how people engage with the product and leverage it given a particular context or purpose.

Again, there is nothing inherently digital or web-based about product design, or interaction design. Once you’re able to accept this and start from this place as your baseline, it frees up your abilities and approaches as a designer, imho.

Original design thinking* = Rhetorical thinking

* “Design thinking” has unfortunately become an overused buzzword, adopted by Silicon Valley digerati and strategy fashionistas to refer to solving problems in a “designerly” way. I hope to clarify the confusion, focused on the canon of design thought at Carnegie Mellon in the mid/late 90’s – early/mid 2010’s.

Proposed and advocated by Richard Buchanan — as drawn from Classical rhetoric and his studies with Richard McKeon at University of Chicago, with a lineage going back to John Dewey — the humanist, strategic view of design thought is essentially about communication and interaction among people, ideas, values, and cultures towards a deliberated resolution of “truth”.

What is rhetoric? It has unfortunately acquired an unsavory meaning, commonly seen as contrived double-talk or sly deception through verbal sleight-of-hand, associated with sneaky salesmen and unscrupulous politicians. However, rhetoric was originally an art of persuasive communication, dating back 2,000 years, first formalized by Aristotle, as a situated art (a set of disciplined, systematic connnections to ideas and methods, all operating in the background of one’s mind guiding their attitudes and behaviors). So rhetoric really offers strategies to shape people’s actions and thoughts via language.

Going further, a rhetorical act involves communication between a speaker and an audience given a particular set of circumstances and a focus of discussion, or topic. (ah, that notion of topos again, a place for exploration and truth-seeking) Thus the core elements that define a rhetorical moment or situation are: speaker, audience, context, and subject matter. There should also be a purpose, or goal for the speaker to accomplish. And naturally there is a method, or set of articulated techniques that shape the delivery and presentation of the speech to the audience, to elicit a variety of responses. This involves appeals made by the speaker to the audience’s sense of logic, emotion, and trusting the speaker as well, per their sense of character and judgment.

Unpacking this a bit more, a well-formed rhetorical act, or speech has three vital elements that constitute the argument put forth to the audience to interpret and respond:

the rhetorical stance

Logos: the logical, rational reasoning behind the argument, based on facts, evidence, data

Pathos: appeals to the audience’s emotions and sympathies

Ethos: a presentational style, conveying the speaker’s voice, tone, and character as deemed to be trustworthy/credible (or note) by the audience

Giving the argument’s overall shape is a sense of purpose or goal, guided by the context or place in which the argument is being made, and of course the various methods employed.

So how does this all connect to design thinking? What are the qualities shared between rhetorical thinking and design thinking as advocated by Buchanan?

Focus on human-centric communication, recognizing the totality of the human being that is addressed with the “speech” (or designed artifact, in this case), not mere one-dimensional users or tools to be exploited for narrow goals. Strongly socially-focused, either at the individual or collective levels.
A situational perspective, taking into account the variety of elements and circumstances that shape the communication and color the audience’s (or customer’s) perception: context, activity, task, goals, other people in the situation, other artifacts that arise, etc. It’s not just the speech act (or design) alone in a vacuum but the holistic view of all the interrelated pieces impacting each other.
An integrative approach, not a piecemeal or episodic way of dealing with problems. Looking at how the logical structure, emotional value, and human factors fluidly influence/inform each other. Each builds upon each other and should be viewed together, resulting in a fully formed solution.
Conversation is key. Dialogue and debate arise through communication and interaction with the audience. There are no absolute answers necessarily. Iteration and evolution towards some commonly/consensually agreed resolution is the mainstay.
There is a necessary, effective sharing across other disciplines, leveraging knowledge and experience from other fields, ideas, or values as appropriate to make the positive effect upon the audience. So, multi-disciplinarity is a core aspect as well.