Category: Practical Matters

This is based on a talk I gave at IDSA a few years ago, which I re-delivered to my class recently.

---

As the fields of “web design” and “UI design” speed forward into a complex world of integrated, convergent digital products (see iPhone, TurboChef, Tivo, TomTom, etc.) with arrays of “cloud services” and “suites of functionality” (like enterprise e-business software or even consumer suites: iLife, Creative Suite, etc.), designers need to offer more than just pixel-pushing and spec-writing skills. Indeed, more than ever, design leaders are needed who can assert a strategic view of designing compelling digital solutions. What does this mean?

---

1. Designers must be adaptive humanist leaders.

Let’s break this apart:

Adaptive means being nimble, flexible, amenable to constantly changing biz & tech requirements (and seeking out user requirements from the field), yet preserving the integrity of the original design vision (ie, the value proposition).

Humanist refers to the empathetic nature of a designer, to be totally aware of the human condition of designing a total experience, from start to finish. This refers of course to empathy for the user, but also for the engineers, marketers, and other members of complex teams with competing goals/values.

This rolls into then next keyword, leader. A designer has to make decisions, and lead with confidence about their vision for a great solution to often difficult problems. To be a leader often requires compromise, negotiation, diplomacy, and persuasive communication skills…as well as a powerful vision embodied in your sketches, designs, prototypes.

2. Designers should be like ecologists, conscious of the integrated system of invisible consequences.

Every product/service needs to be viewed as part of a system of platforms, hierarchies, and families. This includes the brand, features, and related offerings in the company portfolio—even those outside one’s immediate design responsibility. Legendary designer Charles Eames presented a simple yet brilliant sketch that illustrated the zone of an optimal solution, addressing the ideal fusion of competing requirements, much like a Venn diagram with a “sweet spot” of intersections.

Ecological thinking takes a bit more, recognizing the deep social and technical connections supporting a design’s value, implying a comment by architect Eliel Saarinen: “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

Thus, the designer’s decision-making should be informed by a “global generalist” outlook, which is a systemic perspective on design issues: how does changing X impact Y? What level of change? What severity of impact? Who else is involved across the company? Becoming comfortable with integrative thinking, and sensing problems from multiple dimensions will guide a designer in selecting the proper battles, and gauge the proper level of priority for a design activity amid tightening constraints.

3. Asking critical questions driven by a set of conceptual frameworks is necessary in identifying the right problems.

Knowing the domain is central towards making sensible design decisions. Designers regularly confront varieties of constraints and goals; thus, knowing how to interpret the domain sufficiently can help resolve conflicts. Thus, developing a capacity for critical questioning has become a survival skill to keep the designer focused on what is necessary to solve a given problem. Other advantages include improved relations with remote team members, and identified knowledge gaps.

More importantly, such questions about the primary motivations, purposes and assumptions of a project enable a designer to properly scope a problem, extract relevant data, and prioritize high-risk features for resource negotiation later. This showcases the designer acting as a leader shaping the project direction and pacing, rather than struggling against unforeseen difficulties.

4. Influence and persuasive communication is vital!

Navigating the arcane levels of organizational structure and social networks implicit in a company is a valuable skill for every designer who intends to lead complex problem solving.

In any practical design situation, solving the specifics of a problem can be quite demanding. However, securing the necessary agreement from key decision-makers for implementation of the chosen design is a different matter, and often more difficult. Recall that design is merely one player in a complex game, and often with less political clout. Given the deeply social, collaborative nature of conducting business, influencing stakeholders becomes the path towards success. Rooted in Classical traditions of rhetoric, influence is the art of persuasive communication, a “subtle maneuvering of ideas” towards achieving specific outcomes. Accordingly, influence requires a nuanced balance among skillful argument, negotiation of conflicts, tactful compromise, and all around decisive leadership, with conviction and purpose.

In order to convey a direction amid chaotic situations, the design leader should learn to delegate, identify insufficient data, balance risks with benefits, and know who to contact for further support. In fact, one may argue that the true sign of design leadership is skillful dialogue towards satisfying the ultimate business function and delivery of a fulfilling user experience.

5. Design leadership has hidden dependencies–learn how to tap them effectively.

While someone needs to be “in charge” for a design, collaborative ties can ensure better handling of inevitable conflicts (e.g., scheduling, budgets, resources) and improved design decision-making. Part of that challenge of leadership is transposing the chaos of daily ambiguity into a meaningful and actionable order. To facilitate this, the designer should tap into valuable “connectors” that constitute the hidden infrastructure of product development: customer service agents, professional services teams, quality assurance engineers, even interns and contractors, with their fresh outsider insights.

Peer designers working on related projects and supervising managers will offer the supporting confidence and authority to proceed with designs. This ecosystem of collective knowledge and interest can reinforce tough calls, by providing information that fuels the designer’s read on the pulse of a situation.

“Working as a designer” means many many different things, of course, depending on which context you might yourself. Over the last 8 years I’ve had the unique chance to experience a wide range of situations, each embodying a unique character and quality, from large enterprise to a boutique design shop. But there are few major commonplace types of design contexts, as itemized and described briefly below.

---

1. Centralized standards enforcement group: (corporate)

Refers to a centrally funded and geographically located team comprised of designers (visual, interaction, etc.), usability experts, and design managers focused on standardizing a comprehensive set of interface guidelines, design patterns, components/flows/templates all directed towards ensuring a harmonious consistency across diverse product UI’s in their presentation and behavior, as well as functional integration (as required, for large-scale enterprise systems or consumer packaged suites).

Rigorous processes and methods are employed to ensure accuracy and consistency, including periodic cross-team critiques, score-carding, and executive level reviews. Designers are charged with the duty to enforce the sanctioned design consistency, as well as identify opportunities to create new guidelines/patterns as requirements arise.

2. Embedded within an engineering (or marketing) team: (corporate)

In this model, the designer(s) directly reports to either an engineering manager (ie, development manager/lead) or marketing manager, rather than located within a separate design silo or department. When embedded within the actual engineering team, you are directly responsible for providing design direction and assets corresponding to the product to be built. You are also in direct contact with the product builders, with product-specific demands for implementation immediately imposed upon you. The designer is directly on the product team, not partially distanced by reporting to a separate design team/manager, so the chance for influence and control may increase.

3. Advanced concepts (or research) team: (corporate)

Depending on the team charter, this may be a small team of product developers (PM, Dev, QA, UI, Doc, etc.) recruited to “invent the next generation” product as a limited prototype/concept car, eventually becoming a full-blown product for rollout with rest of the company.

Or this may be a department under a long-term agreement to explore emerging product horizons, technologies, trends, with a focus on continual experimentation in multiple projects across disciplines: animation, eye-tracking, visual querying, touch-screen, etc. Concepts, prototypes, user studies are constantly happening, with product sponsors looking to productize whatever “new ideas” bubble up.

4. Centrally managed/organized but BU-funded: (corporate)

Awkwardly phrased, I admit but basically this refers to a situation whereby the designers, usability, and management are all centralized physically and organizationally…yet the funding for each designer (thus guiding the designers’ product assignments) is done via the business units (BU’s) such as “CRM” or “Dynamic Media BU”, etc. This could cause some awkward tensions if designers are working on multiple projects outside the initial hiring/funding!

5. Internal design consultancy: (agency/corp)

I think this is a bit rare, but I’ve heard Philips does this? Need to re-confirm but the gist is…The designers (along with researchers and managers) are collectively organized into a single team but must bid on internal projects, along with external agencies, thereby setting up an interesting competition! Hmm…

6. External design consultancy: (agency)

There are global design consultancies (ie, frog, IDEO, Pentagram) and smaller boutique studios focused on a specific problem space (etc, Involution, etc.) but either way, the designer works for an outside client. Depending on size and focus (and project parameters/proposal), the agency processes and approaches for engaging with the client may vary. There is camaraderie with fellow studio inhabitants, along with various pressures and deadlines, deliverables, etc. And expect mostly short-term projects of various flavors, dynamics, timelines, thus requiring a great deal of flexibility and adaptation by the designer.

---

This is by no means a comprehensive listing–only based upon my personal experiences. There are hybrid forms, of course. And many other forms of organizational set-ups exist and function with differing degrees of success. Some may or may not match a designer’s temperament and approaches, so for designers seeking new opportunities its important to consider the context in which you will practice design.

At BayCHI’s monthly talk last night, we heard Glen Murphy, lead (only?) designer for Google’s Chrome web browser explain their process and challenges. Quite a fascinating internal look at this specific team’s design process (Murphy made a point to clarify that each design team at Google functions differently per their dynamics and goals, etc.). Below are my key takeaways.

• No design documentation (ie, specs); instead the approach was “mockup as spec”, given the tight loops of trust and feedback among the core team elements: design, engineering, and product management. Engineers used the mockups as the source for prototyping and implementation.
• Each member of the team had a mix of skills, including coding/designing/business sense, etc. so no one person was focused on just one thing as their speciality. Each was able to contribute to the other’s relevant area/domain.
• Chrome was created for the purpose of “speed” and “reliability”, which I personally imho found a bit dubious (couldn’t G team have just collaborated with Mozilla to make Firefox faster and more reliable for Google apps?).
• No wireframes created in their process; went straight to pixel perfect mockups–all mockups were “fully formed” in Murphy’s words.
• The three major elements in consideration of each design iteration and sketch were: interface, graphics, and platform (meaning the platform guidelines for Windows XP/Vista).
• Each tab was treated as an isolated instance of Google Chrome, for better stability/performance. Murphy sez, “we were basically creating a tabbed window manager”.
• The tabs were one of the critical elements from a UI POV as well as branding, became the central identifying element of the interface. Did over 1600 iterations of the tabs in Photoshop, trying finicky levels of radius details, etc.
• Talking about the Omnibox (combined Search bar and Address bar) as the second critical feature of Chrome, Murphy described various iterations of what should appear when a user typed a word or phrase combination. Tried out lots of options in mockup and implementation. Ultimately used user feedback, but did what engineers “felt right”.
• What’s coming next for Chrome: extensions (but do it in a graceful, seamless way, aesthetically and functionally) and openness, which Murphy admitted he didn’t have alot of experience in as a designer, dealing with the challenges of design open source software UI, and allowing users the modify, etc.

Overall I was struck by two things:

1) How the reliance and insistence on pixel-perfect mockups from the get go parallels Apple’s UI design approach from what’s been described in the media…no wireframes or paper prototypes, etc.

2) How Murphy kept using the words “feeling” and “felt right” quite often in his talk to describe design decisions and rationale. Really speaks to the fact that alot of interaction really has to be just done and judged by your own phenomenal experience of it. Does it feel right or not? He did mention the obligatory user studies and quantitative evals but seemed to me, imho, that he took that as just data points, not necessarily wedded to all that, instead relying upon his (and the team’s collective) experience/wisdom/judgment to make design decisions.

Having worked as a designer at some of the largest and most well-known technology corporations in the valley (Oracle, Adobe, and most recently Cisco) in their respective UX teams, I’ve gained insights into how design functions across diverse contexts (both positively and negatively) and learned vital points about digital product design processes in general.

---

** Collaboration vs. deliberation: There is a subtle yet critical difference between these concepts.

Collaboration involves active multilateral, multidirectional engagement (verbally and physically co-present) by team members across integral disciplines (engineering, quality, documentation, marketing, etc.) towards a shared purpose–building the best user experience possible, given time/cost constraints. There is give-and-take, back-and-forth, compromise and argument, blow-ups and chillouts, but all of this guided by a common sense of working together in a cumulative, aggregative fashion of building up the best solutions to the identified problems. There is active sharing of knowledge, a high degree of “human touch” interactions (phone/IM/video/f2f), a social sense of teamwork & pride, etc. And there’s a concern when people are not around, or goals are not achieved, with a desire to course-correct to improve things for everyone.

However, too often corporate managers ascribe the label of “collaboration” to what is really just empty, trite, ineffective deliberation: a group of strangers artificially thrown together to debate project issues or status updates with no connective thread or assured sense of solving problems collectively. Often these occur via conference calls with 20-30 people across the globe, multiple functions–but nobody knows each other! Or their role/value! In other words, just lots of sitting around talking but no action…or even worse, no concern that actions are being taken by someone for some goal! No sense of forward progress with some tangible outcomes. No sense of working together to wrestle the points and their merits. This leads to malaise and disaffected team members, lacking the requisite motivation to inspire and generate innovative possibilities.

---

** Respect vs. contempt: Nothing great can be achieved without a strong degree of mutual, professional respect for each other as teammates striving to do something productive and worthwhile. Anything less leads to a poisonous atmosphere of malice and laziness, in my view.

Respect quite simply is an essential ingredient to effective multi-disciplinary product development, period. This implies acknowledgement of the other’s professional know-how, prior experience, and tactical skills and resulting deliverables as well as their value to the overall project’s success. Respect also implies (imho) a sense of empathy for that person’s contribution–how difficult/challenging it might have been, what hoops that person has to jump through, how to make that person feel like a welcome, valued part of the process, etc.

The opposite, contempt, is the utter lack of appreciation or acknowledgement of that person’s value. Contempt implies arrogance, hubris, pomposity, and a generally subtle attempt at reducing the dignity of the teammate’s humaneness. Contempt is admittedly a very strong word, I realize, but imho it’s an apt description of a sadly common attitude in massive, territorial bureaucratic institutions.

---

** Engagement vs. detachment: This is a hard lesson to learn but is vital for long-term professional growth, being able to be fully engaged in a project with all your might, yet cooly detached to respond to fluid situations and finicky issues. Passion is necessary to achieve greatness (or at least meet your milestones!), yet also needed is a calm rational detachment to sort out sticky frustrations, scheduling snafus, vendor/contractor misunderstandings, botched file deliveries, etc. It’s a tricky balance, that takes years of practice and experience to hone carefully, like a samurai blade skillfully wielded. I recently read an article about Barack Obama’s demeanor on election day: “peaceful, focused, confident.” That’s where you gotta be as a designer to help make forward progress and get amazing results while being a productive teammate!

---

** Coordination cost: Related to collaboration as a factor to be managed and balanced well is the number of people involved in a project, and their geographic locations (at least remote/local). The more people to work with (and thus exchange information/deliverables/assets, etc.) then the greater the coordination cost. That cost, in my view, is multiplied when those teammates are based in remote or offshore locations. Why? Time zone differences primarily, causing conference calls to be held at odd times, often affecting social or non-work schedules. Foreign languages can be a barrier to understanding, as well as cultural habits/differences/misunderstandings, which have to be addressed up front. And let’s face it–nothing is better than just being there, face to face, hashing out the problems and brainstorming solutions! Technical difficulties (which inevitably happen) raise the coordination costs: conference call dial-ins fail, video calls stutter and crash, inability to share screens/documents across firewalls, etc. All adds up!

---

** Dysfunctionality: All corporations to some degree have some form of “dysfunctionality”, kinda like families–all families are dysfunctional! :-) The problems occur when the maladies adversely impact the collective work of achieving a strong solution benefitting the business and the customer. What are the common elements of corporate dysfunctionality? Well, here’s a few I’ve noticed: unstated expectations, contemptuous attitudes towards co-workers, apathetic view of project, unspoken/unclarified assumptions, poor lines of communication, lack of concern for the “coordination cost” of remote teams, lack of understanding new methods/tools, overall broken processes with no feedback loops to fix them, etc.

---

** Sources of authority: To get positive results as a designer, it’s important to recognize the various “sources of authority” that bolster your attempts to persuade, convince, enable, facilitate, etc. And basically get what you want done, thereby influencing the corporate design situation.

The three main sources of designer’s authority that I have identified:

1. An official, sanctified process: “This design is right” b/c it followed a corporate sanctioned process, involving data points, analysis, reporting, etc. Or if teams don’t follow the process, then they can be corrected accordingly per the statutes of what is allowed and valued.

2. Title, rank, and position: “This design is right” b/c I’m the “senior interaction designer” charged with the responsibility to make the call, leveraging my prior experience and education, etc. So you need to trust my professional judgment as I play that role on the project.

3. The power of personality: “This design is right” b/c my force of personality through charisma, drama, voice, theatrics, etc. will convince you of it, period. (Obviously you’d need to employ this with some degree of caution…and make damn sure you can back yourself up when challenged by a brusque technical architect or equally fierce marketing manager)

So which is the “right” source? It really depends on the culture and temperament of the corporate context you’re operating within. Some companies may not take a strong personality-driven designer very well, while other places may respond very well and in fact demand that kind of approach. Meanwhile other organizations may value a more structured, quantitative, itemized process-driven authority structure for justifying a design. In the end, I think a great designer knows how to smartly blend a combination of approaches accordingly per the context and situation (and the design project in question), as well as the attitudes of the team players involved.

While reorganizing my design book collection (which is rather all over place, both physically and thematically!), I came across an oldie but a goodie: Clement Mok’s Designing Business, published by Adobe Press way back in 1996…!

I remember purchasing this book (a pricey sixty bucks) in Ann Arbor for my first interface design class ever, taught by Loretta Staples, who in fact had worked for Clement at Studio Archetype previously. Later on in grad school at CMU, I took a brand design course featuring the opportunity to re-design Sapient’s identity system, and Clement Mok was our guest critic! Nice to have your designs ripped up by him :-) But I digress…

DADI is one of the “golden nugget” takeaways from Clement’s book. It refers to a collaborative design-driven process framework for digital projects. The acronym stand for:

• Definition
• Architecture
• Design
• Implementation

From the text:

Each of these phases involves editing, which is the process of making choices. Editing is selecting the most appropriate way to express a thought or an idea, as measured against defined goals. Design is the enhancement of an entity; it gives an entity form through the processes of addition and subtraction.

Continuing further:

It is by understanding a project’s purpose and following through with it that a business makes a successful product or service…A project needs both an external focus and an internal focus, and the two must not contradict each other…The way focus is articulated in the context of business is called an agenda, and designers must reconcile companies’ agendas with their own.

And finally:

The DADI process creates a framework that defines a project; creates an architecture that explains the process and, if necessary, the technology platform; defines who does what; defines the time frame and budget; and establishes efficient communications among the players. This process keeps any project focused on its purpose by preventing progression from one step to the next if the purpose is not understood.