Month: January 2008

Design process as a Swiss army knife

Going back to my previous post about my flavor of the user-centered design process, I want to clarify one vital point. The most important thing about having an effective design process is not that you march lockstep through every step and every single artifact (persona, object model, taskflow, functional map, etc.) for every single design situation or every client.

Nor is it helpful to manage the process with excessive layers of bureaucracy, mandatory reviews and approvals/sign-offs from various people before design actions can be taken or movement forward to the next step.

Such approaches transform the design process into a heavy-handed tool that can take control of the designer and the designs themselves, adversely effecting mood and attitudes, perhaps even subverting cooperation with your clients and allied teams. It’s the designer’s (and team’s) process, so you have to own the process, else the process owns you.

Instead, it’s better to approach your design process (whatever flavor or variant accepted and evolved for you, your team and/or company) like a Swiss army knife. Nobody enters a room boldly brandishing the knife with all its tools fully exposed–At least, I hope not! :-) Instead, it’s kept in the backpocket and pulled out when it’s needed by the wise, knowing owner who recognizes when a necessary situation arises that would make best use of a particular tool.

Similarly, a designer shouldn’t simply barge into a meeting blasting the problem with full-on UCD process with all its minutae, which could unsettle the other project collaborators–unless they’re totally clueless and chaotic, thus desperate from some militant order and structure!

So it’s assumed here for an effectively waged design process, that the designer knows when to use it well, when to leverage certain phases and artifacts, when there are gaps in knowledge or stalemates to break through via certain artifacts or design activities, and so on. It’s also assumed that the designer can and will leverage whatever past experience and knowledge (i.e., wisdom) to resolve immediate design problems, particularly repeated patterns–just try to use what you’ve done before for another client. See if it works! If the designer feels confident to move forward per instincts and experience, so be it and then evaluate results with alpha testers or customers with iteration, accordingly.

It’s far more important to have a solid valid process, and use it flexibly, adaptively, per situations, operating in the back of the designer’s mind to be unleashed in a judicious manner…not as an explicitly wielded function of bureaucracy or project management which can often be counter-productive.

Just to rant briefly for a bit… I think there’s a general belief in the IxD/HCI world that if a designer doesn’t go through every single step of a militantly ordained UCD-driven process, then the designer is not “user-centered” or the result is no longer “usable”. I disagree. I think it is actually possible to trust a designer’s instincts and past experience/knowledge as a visionary leader who can solve various problems. And just possibly, it’s those moments when personal ingenuity and creative insight emerge forth. The last thing you want to do is use your design process as a recipe or formula that stifles innovation and creativity…or serendipitous moments of insight!

Digital product design

This is something that has come up a few times while working at Involution Studios with Andrei and my other colleagues: Is what we do “digital product design”, melding the arts of interaction, interface, and information design with a good dose of programming and business savvy. Hmm…

I must confess, I really like this label as it breaks away from solely “making websites” but gets closer to the heart of the challenges we face at the studio (and surely others in design firms around the world), struggling to design & build functional, viable, desirable software/applications/devices that are inherently digital (pixel-based, internet-driven, computer) and enable specific human tasks/goals/activities, like writing a message, editing a spreadsheet, sharing photos or buying music online…with some commercial purpose as well, of course.

Digital product design in my view is more substantive of a label, more holistic and encompassing, speaks to the product-based nature of what is being made, with a complex array of features/functions/actions with sophisticated back-end engineering required to make it all actually work in real-time for real people. Also it suggests that we are indeed the digital/pixel/code equivalents of traditional product and industrial design professionals, just as rigorous and demanding and perhaps even more complicated as digital/physical devices become more popular (what’s known at frogdesign as “convergent design”, with embedded digital controls or screens, like the award-winning TurboChef).

Another reason I like this term is that it stands in direct contrast to “people who make websites”, namely the Event Apart folks. I attended one of their traveling roadshows back in June 2007 in Seattle. (read my review here) It was a great time, really an eye-opening experience that exposed me to this sub-culture of sorts focused on the exquisite crafting of damn good websites, fully standards-compliant and beautifully visualized. It’s an intensely passionate crowd focused on this art and discipline, for which I have the greatest respect and admiration! However, I felt a bit empty at the event, mainly because issues of interaction, application, or software design were not addressed explicitly and seemingly out of the scope of “people who make websites”. That is certainly their prerogative. However, I do think that making the deliberate decision to avoid tackling such critical issues (at the personal or community level) may be a career-limiting move downstream, as more content websites take on transactional, application-like interactive qualities, which Bob Baxley analyzes in his articles and book. Just a thought.

Maybe we’ll all be called “digital product designers” in a few years…! :-)

The 4 orders of design

Dick Buchanan postulated at CMU and in his writings that there are 4 “orders of design”, based upon product type and dimensionality (as well increasing complexity level and scope of influence). These orders map closely to the traditional commonplace labels ascribed to design disciplines, like graphic design or industrial design.

  • 1st Order: signs and symbols >> graphic design/2-D products
  • 2nd Order: objects >>industrial design/3-D products
  • 3rd Order: services and activities >> interaction design, service design/4-D (time or motion-based) products
  • 4th Order: systems and environments >> architecture, urban planning, organizational design, systems architecture, etc. (N-dimensional, multiple axes of concerns and change including society, government, community, public policy, law, natural ecologies, etc.)

For starters, it’s important to not get hung up too much on these labels, but instead to take a “topical” approach to what these orders may mean, as conceptual places for interpretation and invention, towards understanding their potential, both intellectually and professionally for the various design disciplines. There is no value judgment as to whether one order is “better” than another order. It’s simply a way to organize an ever growing and complicated field of activity.

What’s really cool is what interaction design and subsequent fields mean as places for design activity with post 3-D situations, dealing with people, time, motion, change, etc. Interaction design in particular is at a crucial nexus, as a novel and transitional field. There is a controversial (maybe for some folks) mix of principles and techniques from “yesterday’s design fields” (graphic design and industrial design) and “tomorrow’s emerging fields” (service and systems design).

For instance, typography, color, imagery, grids, layout all still matter greatly when crafting the well-formed engagement with a digital interface, whether it is a website, cell phone app, or your car GPS or even an electronic toaster. Those elements shape the message of the product and communicability of the interface to the user, just like a speech composed for an intended audience, swaying them towards some specific action or attitude.

In addition, high-level issues of social relationships, touchpoints for brand identity, feedback loops via customer service, overall architecture and flow through a system, must be considered just as important when designing a piece of software or other form of technology interaction. Increasingly, issues of public policy and organizational process “design” are taking on flavors of interaction/communication, within broad contexts of business and government–trending towards designs of the immaterial, shaping people’s relationships, behaviors, and values rather than distinct “products” per se on the shelf at your local electronics store.

It is this fascinating and provocative potential for interaction design thinking (with its inherent concepts and methods) borne from rhetorical traditions that i find the most exciting, in addition to the cool sexy rich interfaces and interactions, of course :-) Not just limited to websites or software or gadgetry, but influencing larger spheres of activity concerning people and their problems, in other contexts.

What do designers want?

I remember on my first job out of school, just a couple months after graduating from CMU, one of the principal designers at Oracle had a quick introductory chat with me to help me get settled in. Great chat, very inspiring. He himself was trained at Royal College of Art (RCA) in industrial design and architecture too I think. He’s now the VP of the Oracle UX team.

Anyway, one of the key things he said to me was: “What do you want as a designer? It’s what every designer wants–to have influence, to change things.” Influence. That’s the key elusive thing that’s highly sought but difficult to possess and make good on.

Design is just one competing element in a complex organizational system serving the primary busines function. BodyMedia’s Head of Design Chris Pacione has described business as a “multifaceted and complex organism…students need to recognize what value they offer the organization”.

The fact is design functions within a complex milieu of forces. There is an interdependent system of business actions via some sponsoring organizations (marketing, engineering, research, etc.), oscillating among dynamic levels of budget, time, and resource availability, given the lifecycle of the company (and market conditions), all of which continuously shape corporate strategy. In addition, there are constituencies in product development, like customers and partners, armed with competing requirements. As structural engineer and author Henry Petroski says, this complexity is inherent to design practice:

“Designing anything involves satisfying constraints, making choices, containing costs, and accepting compromises.”

And designing requires a healthy dose of achieving influence, through rhetorical means, persuasive communication, a strong way to leverage one’s own personality, experience, knowledge, and of course the “stuff” that gets made in the design process: diagrams, sketches, mock-ups, prototypes.

It’s all about influence. (more later about power, control, ego, and fame :-)

Key questions for every designer

When entering a situation for the first time, or when re-visiting issues later on in the cycle, there are a few critical questions that as a designer you should continually ask (at least subconsciously if not always out loud) to avoid confusions or misunderstandings downstream.

1. What assumptions are we making (about the user, task, context, technology, marketing requirements, etc.)

2. What are the dependencies if any? Should team x be aware of what’s going on with this part of the product? Does team y know about team x’s change request?

3. What are the expectations for this feature (held by stakeholders, customers, users, etc.)? Do we need to adjust those expectations due to changing circumstances, etc.

So in sum, always examine your assumptions, dependencies, and expectations and make sure everyone is on the same page! It’s hard to remember this when you are suddenly thrown into a situation or aggressively pounced upon by an engineer or product manager, but it pays off invaluably down the road in complex, multi-disciplinary contexts.