Ghost in the Pixel

Now don’t get too excited :-) This isn’t meant to be a roundup of all the grand universal “rules of good design”–whatever those are! No cookbooks or recipes for some “quick & easy” design fixes (like taking a pill in The Matrix). Instead, these are some of my collected insights into the major commonalities that comprise any design situation, whether for software, services, devices, environments, etc. If you abstract away the mundane details of daily work, certain themes and threads emerge, as described below.

For newbies to design (eg, fresh outta school or newly switched from another field) these pithy phrases may seem somewhat cynical in their terse wording, but that’s not the intent. Instead, take these with grains of salt and feel them out in your design gigs and projects. Test them and see what discoveries you make in your design career! I’m betting many of these will ring true later if not sooner…

• No design is perfect : Even the simple, ordinary paper clip can be iteratively improved–soften the sharp edges, add texture to the slippery curves, color code the loop, have different shapes, etc. Every design is subject to improvements at varying scales (whether great leaps or minor tweaks) as the use cases, contexts, materials & technologies adjust over time–or new discoveries made. And as new designers across the globe, armed with fresh perspectives, join our diverse community, different and hopefully better ideas will be introduced. That’s a good thing and must be expected. There is no perfect design; anything can be improved which is a healthy attitude in this field.

But of course, you still gotta get the design “good enough” for shipping to your customers, which is a separate issue altogether. As Steve Jobs famously said, “Real artists ship”. So you can’t wait til perfection. How do you know if something is just right? Something “minimally viable” but supports the goals of the product purpose and aspirations of intended audience is a start…

• Every design involves compromises, trade-offs, constraints : This is just a hard fact of design practice, period. You can’t get everything 100% due to the social and political complexities of…working with people :-) The pragmatics of any design problem require understanding of and wrestling with constraints (technical, commercial, social, etc.), negotiating various trade-offs (since no design is perfect, see above) which then forces critical debates about what is most important (prioritizing content, functionality, features, so forth) to the product & user & business. This debate is what should lead to a well-guided strategy adapted over time. The ability to artfully compromise to achieve goals for all stakeholders is at the heart of any design. This is echoed in Eames’ classic Venn diagram .

• The criteria for a “good design” depends : Per the UCD standard canon, the trifecta of qualities that determine a “good design” is bound by useful, usable, desirable (per Liz Sanders & Dick Buchanan). Other qualities include feasible, viable, findable, per Larry Keeley, Tom Kelley, Peter Morville, etc. So what really makes for a good design? It all depends upon the purpose and situation driving the design effort. Sure, it has  to enable a user’s goals, make money for your company, efficiently apply a technology, but how does the design resonate with the specific deeper values & goals underlying the audience, the business, the market, and the designer’s vision? How does it improve the human condition in a way that supports the market while helping the environment, enabling a social benefit too? It’s more about the debate over essentially contested meanings associated with your brand and strategy, in addressing human needs, then a rote checklist of criteria items. That internal stakeholder debate should help illuminate the right criteria for your product and market.

However, far from being relativistic or “anything goes for whatever moment”, there are some core qualities. As Marty Neumeier says in his book The Designful Company, good design, at its essence, connects to human virtues, embodying the exact qualities we wish to see in our fellow human beings: generosity, courage, diligence, honesty, clarity, curiosity, wit. In contrast, bad design exhibits vices like fear, deceit, pettiness, confusion, apathy, waste, laziness.

• Designing without principles endangers the integrity of a design : Inevitably, because of the many compromises needed to balance conflicting priorities and demands, there’s a risk of a “watered down design” that makes nobody happy but achieves all the “checklist tasks”–design by committee, for example. It’s vital to assert and defend the integrity of a design vision by having conviction and “principled compromise”. You need design principles at the outset, as it’s what drives what you (AND the product team/company) believe in and ensures everyone stays on path, towards product excellence…how ever that is defined for your organization. Whether it’s whimsical, heartfelt stories for Pixar or sturdy yet smartly hip furniture for Haworth, principles ensure the likelihood of a strong, cohesive design vision emerging from the tough compromises. It’s also what helps ensure the benchmarks for successful criteria and post-mortem evaluation after ship. And such principles provide the architectonic framework for feature evolution and upcoming iterations in a thoughtful, coordinated manner. Mike Kruzeniski’s clear articulation of the Windows Phone 7 design principles is an excellent reference for this point.

More truths coming soon…!

Last week for 3 full, intense days I participated in the Stanford d.school “design thinking” bootcamp (along with 13 others from Citrix, including designers, managers, execs, from around the company). Just wanted to share a few initial thoughts as I reflect upon the activities we performed.

As everyone has acknowledged–and i concur– it was certainly exhilarating, intensive, productive, mind-blowing, enlightening, inspiring, frustrating, difficult, empowering, and any other contradictory superlative you want to throw at it ;-) Yes, it’s all of that, with some minor issues. Very grateful to undergo this workshop with my colleagues and meet others from many walks of life who sought something actionable to light the fire of “design thinking and doing” in their workplaces.

 

My key takeaways:

* The d.school’s flexible basic process of 5 steps is NOT a formula or recipe but instead a pathway of generating novel solutions, to break us out of the usual “left-brained” analytical mindset. The steps are Empathize > Define > Ideate > Prototype > Test . You can bounce among them, iterate multiple times, as needed. Indeed the language can adjust per your culture’s and team’s needs. Do what makes sense, no need for fancy stuff.

* Evaluate ideas per 3 basic criteria: Successful, Delightful, Breakthrough. (Helpful after brainstorming, and putting a sticker to denote each idea)

* Identify a specifically shaped “point of view” to suss out novel opportunities and extremes of possibilities, and to force debate about what’s really important in the product/service you are creating.

* Brainstorming well needs a strong context definition and framing of a “point of view” and problem statement: Person needs/wants X in order to achieve Y which will provide Z benefit. Not just randomly throwing up ideas on a whiteboard and see what sticks. (BTW, Luke Williams at frogdesign demo’d this brilliantly with their trademark frogTHINK exercises to drive creative problem solving)

* You can achieve alot in just a short, acclerated comprssed timeframe! It’s all about quick, nimble creative thinking in the moment. The bias to action helps you lean forward constantly.

* Empathy and humanity are the drivers for doing what’s right and good in the world. Positive change emanates from that simple yet often hard to grasp premise. Gotta try to remember that in large, anonymous organizations rife with policies and templates, etc.

* Design isn’t about you, the designer, but about the community you serve: the users, providers, vendors, partners, suppliers, parents, neighbors, etc. Totally reminds me of Eames’ legendary diagram.

 

My own color commentary:

Now, admittedly I went through this bootcamp as an experienced hi-tech designer trained in a rich set of methods/approaches from CMU and through Valley mentors at various companies like Oracle and Adobe. I had to put all that away! So I did humor the process and just go with the flow, realizing that the purpose and point of view is truly oriented to break via “shock and awe” tactics the rest of the workshop participants, without a design background who have grown weary of neverending Excel/Powerpoint/Word docs and tedious meetings that devolve into petty politics. I totally got the value of the breakneck speed and crazy intensity, with very minimal discussion or reflection time, just run and act very purposefully with intention. Truly, like a bootcamp :-)

You are pushed beyond what you think are capable in very short timeframes, and rather unexpectedly to tap into latent abilities deadened by Powerpoints. It’s great to shock folks to wake up… but I’m not sure about the intellectual value which seemed tossed aside in zealous favor of “fast and furious” action. Is this 72 hour bootcamp the “fast food” equiv of a burger or donut?? Impromptu tasty satisfaction but what about long-lasting value?? Not much reflective analysis (or conceptual tools for deep analysis), ironically for something called “design thinking” ;-)

I do wonder how other participants will take the ideas and experiences back to their workplaces. And after 3-5 years from now, will they still be applying the same lessons? What value will have been achieved? WIll their opinions have evolved given the rigors of practical execution? Design is not for the weak, as I often mention. There’s always such tremendous organizational/cultural pressure to kill infectious ideas and powerful possibilities (see Machiavelli, The Prince). The forces that shape real execution, as Steve Jobs cites, demand that “real artists ship”. You gotta deliver and it’s often the devils in those implementation details, the gotchas, that separate the real change agents from the posers & dreamers. Not sure how much that message was conveyed in the wrap-up sessions.

I also had issue with their very liberal use of the word “prototyping” verging on buzzwordy jargon. Per d.school’s ideology, literally anything and everything that is hand-made is a prototype, including a blob of dough with a straw in it, or a sticky note sketch. Emphasis was on crude and raw, which I understand. But I didn’t care for the obvious disdain for hi-fidelity prototypes, continuing to spread the false myth that people don’t give feedback to highly precise demos. They clearly haven’t done real-world design at a hi-tech context which often demands very accurate visualizations to elicit critical opinions. Also repeated a few times was criticism of designers as “forces of authority”, which really does justly occur in many contexts. Designers must be forces of persuasion, given all the constraints and compromises endured. While design is overall collaborative, there needs to be a clear vision and voice driving a focused agenda. “Make it so!” as Picard would say.

Despite these relatively minor misgivings, the d.school bootcamp is perhaps the most vivid, potent expression of what it means to learn design by doing, truly living the experience in all its pain and glory. It’s certainly a very bold, powerful start…

 

 

The standard UCD-based design canon operates from the basic premise that there is a user problem to identify and solve. User can’t do X so we design an interface/product/service to help said user achieve X or alternatively Y.

As I become more involved in “next gen” or “concept” design work, I’m sensing that the real question that drives forward-looking situations isn’t really about “solving a problem” per se, as much as it is “identifying opportunities” to exceed expectations, leapfrogging banalities and envisioning scenarios that were previously impossible or simply ignored. Of course, there’s still some subliminal or ambient “itch” (or “felt difficulty” as a former prof liked to say) that’s greasing the axles in your mind to turn forward, searching out new possibilities.

What’s driving this opportunity seeking?

* New technologies, esp coming out of research labs or code geeks trying novel techniques. Does it sound like “invention in search of a problem”? Perhaps. But that doesn’t necessarily make it horrible in its own right, per se. This is where a designer with a strong grasp of the humanistic / cultural / social potential can join the fun and suggest avenues that really amplify the technology’s merits, towards becoming something that enables a total human experience that people will seek and value. In other words, meaningful tech.

* New business models for revenue generation, but NOT through urgent cost-cutting or gritty price-wars. Instead through expansion of markets, tapping new domains and customer segments, seeking new geographies and thus demographics that represent strong economic potential. Or even defining new business territories, over-turning existing models on their head, as Steve Jobs / Apple did with music and tv shows, or Netflix did with video streaming or Google did with search/ads.

* New contexts, scenarios, social/cultural behaviors and attitudes emerging with younger generations, sub-cultures, social mixing of populations, as well as adoption of new tech (like texting, facebook, webcams, smartphones). This requires constant vigilance and sharp observations to intuit underlying insights on motivations and approaches for doing something–the why and how. Is there something happening on the edges and fringes of social groups that are poised to “cross the tipping point” and become massively mainstream? Why is that so? How big of a phenomenon is it and what are the opportunities to shape it into a meaningful form or service or product?

So it’s more than just fixing problems (whether quick band-aids or triaging wholescale re-work projects) but actively seeking out those moments for what’s next and better than what’s current. What are those opportunities for significantly improving the human condition, maximizing a business’s value, and/or capitalize on some new technology magic?

I always find it amusing to see elaborate, trumped up job titles amongst UX folks like “ideation igniter”,  “strategic experientalist” or “interface pathfinder”. You could almost start a short career out of extravagant naming a la Dilbert “mission statement generator” :-) One title in particular that I’ve heard a few times is “design catalyst”, whether in job descriptions or personal resumes. What does it mean, anyway? It’s perhaps the sanest sounding of such titles, but still suggests some grandiose notions of design’s function in product development, almost like “rockstar” or “ninja” ;-)

Although, given some recent design projects I think I’ve gained a little more clarity around what a “catalyst” is in a designerly way, towards helping advance multidisciplinary team agendas. In some sense you could say I’ve been a “design catalyst”, but this realization only came to me very much afterwards, during a project post-mortem, reflecting upon what I did and how it followed through. A few key insights I want to share here:

A design catalyst IMHO is someone who is…

* Willing to drop in to a contested situation (a la Heidegger’s “throwness”??)  with little contextual background info, confidently generate models and solutions quickly on the fly (leveraging “rapid expert” or “genius” approaches of past experience), and spark questions that help the conversations move quickly through initial phases

* Able to quickly foresee and surface issues with current debates/questions/ideas (which may be muddled in some way due to language, politics, schedules, etc.) and think ahead to better possibilities, in a sense “leap-frogging” what’s currently being discussed, jump over the bottlenecks

* Quick to intuit the latent, unspoken yet very critical issues about the context, audience, functionality and business model, and express them in a very quick, active way: diagramming on whiteboard, rapidly sketching real-time, or mocking/protoyping right there with the team to force vital discussions of what’s most important

* Adept at abstracting away the tedium of details to the bigger issues: genres, modalities, paradigms, archetypes…and then diving back into the specifics with rigor and articulation to clarify what’s really at stake for the product: user, tech, and biz model too

Seems what’s key to make this a “catalyzing” function (from a design POV) is the speed & intensity of engagement, which is also quite brief (small doses, if you will), to help accelerate three major things:

a) the team’s understanding of a problem
b) the team’s discovery of novel design solutions and
c) an improvement of overall project / team dynamics towards a more productive, and dare I say, enlightened view of the situation

It is through the power of the designer’s imagination, visualizations, and persuasive rhetoric as a mediator to enable this catalyzing value for the benefit of the product team. Of course, it takes years of experience and a willingness to leap with confidence with one’s judgment…as well as a fearless sense of possibly being wrong! But the goal is the accelerate the team forward to a stronger, better place regarding the proposed product/service offering for customers, and a great experience for users.

Is being a “design catalyst” simply functioning as a “rapid expert designer” (aka, “genius designer”)?? That’s a debate for another day…hmm! :-)

No, this doesn’t refer to savvy engineers wearing hip, trendy fashions ;-) Just wanted to share some thoughts on this oft-debated issue of whether UI/interaction designers need to learn how to code.

Jared Spool recently spoke about it on his blog here. (and posted a nice short follow-up here on 3 reasons to learn to code, particularly about “knowing your medium” and “bringing your ideas to life via prototyping”) He was primarily looking at start-ups and the need to stay lean given the financial constraints and time-to-market delivery pressures. Although truly in any software development context, to maximize your ability at both designing and programming while supporting the overall product vision is an awesome ideal posture–just very difficult for many, if not impossible. But it can be done and is a great professional goal.

Some arguments raised against doing both design & code concern compromising theUCD stance when ascertaining what is best for the technology (versus the user) or struggling with two inherently contradicting masters, thus nicking the “user-centered” design vision. Or trying to be a generic “jack of all trades but master of none”, thus ruining both the code and the design. But those are frankly amateurs anyway ;-)

As for “compromising the UCD stance”…any pro designer has to contend with multiple masters (including Prod Mkting/Mgmnt, QA, Docs, the GM of the division, etc.)  and assuage the politics and nuances of needs/wants accordingly. Designers are inherently often in the crossfire of mediation, but with the advantage of seeing cross-functionally, empathizing with multiple POVs and visualizing options along the way to keep the conversation (and tough decision-making) moving forward. Any responsibly honed design must factor in tech capability, commercial viability, as well as user fit. Indeed the designer who willfully ignores the technical aspect is doing the user a grave disservice, in effect relinquishing their seat “at the table”. That designer, IMHO, has no right to complain if the shipped product doesn’t correspond to the design vision! Instead, the designer needs to figure out how to get involved in UI engineering discussions at a partnership level, if not as an actual coder herself.

So if we instead re-cast the issue around “how to insert designers into engineering collaboration”, this might make for a better cause overall. Whether the designer does the coding herself, or is deeply embedded (not just observing but participating actively, advocating critical choices) in tech discussions, it’s all for the same purpose: to achieve the intended vision of a design, made real and feasible, and adapted along the way to address and optimize for any tech hiccups so the user (and business) benefit. That’s our goal, right?!

I realize, it’s not as slick sounding as “designer coder hybrids”– which are awesome and perhaps will become more of the norm, as newer generations of designers become increasingly comfortable with toolkits, APIs, SDKs, etc (and taught them in d-schools)…

Ultimately, for their own pro credibility and enabling a product success, UI designers need to be much more aware of the capabilities of a UI technology and how this affects their design, and the user’s experience. Gotta ask yourself some key questions to start:

• Can the chosen technology be re-skinned and styled to get the desired design, with pixel accuracy? 
• Can it be made responsive / performant enough in the enviro intended to be used? (desktop/web/mobile)
• When the engineering team says it cannot be done, do you believe them? Are you able to suggest an feasible alternative with justification? 
• Is it a problem with engineer’s existing codebase than the framework of the technology? In other words, is it really bad “code design” on their part and would it mean a lot of rework for the “UI design”?

And in terms of skillset, the following are becoming invaluable for designers:

• Translate interface layouts into functional prototypes with clean, modularscripts and code snippets that can be reused for subsequent builds (as needed)
• Effectively and constructively call out an engineer when that person resists design-driven changes to a product
• Ability to argue back effectively and generate workaround design alternatives that logically address the engineer’s technical concerns

Bottom line, if you are willing and able to learn programming or at least some development tools/frameworks and gain familiarity, then by all means go for it! This will make you a better, stronger, faster, capable, influential designer achieving the user’s goals of enjoying a product that is satisfying and faithful to the vision. At very least, get involved in the geeky UI tech discussions and keep abreast of tech issues. Do tutorials and participate in forums or attend seminars at events like Microsoft MIX or Adobe MX, etc. (or Silicon Valley CodeCamp ;-) Become the UI engineer’s  buddy! As I wrote in my paper for HCI International, the ties between design and engineering are necessarily getting closer.

Design teams need to inform and guide the selection and use of proper UI tools/frameworks/tech for proper front-end presentation. At least having a close, active partnering relationship, asking good critical questions, and showing curiosity will help a long way!