Ghost in the Pixel

I’ve posted previously about design thinking more than a couple times in the last few years, continuously struggling to understand just what it is that makes this phrase such a buzzword-worthy novelty among non-designers…and also connect it back to humanistic aims of rhetorically nuanced good design, as advocated by Dick Buchanan/CMU. Recently my thinking on this has taken another evolution, influenced by reading books like The Lords of Strategy, helping drive design leadership in a corporate context, and chatting with colleagues at places like Second Road and MSFT.

Here’s what I’ve concluded so far; nothing earth-shattering but good to capture and share to feed the fire ;-)

** Foremost, it’s clear “design thinking” has become the new “user experience”– a convenient, catch-all, shorthand phrase alleging a pro-design posture by non-designers that is mundane/generic in daily language yet somehow implies a substantive realm of intellectual & practical activity. Which it may be, if you sincerely, earnestly want to master and absorb design–and all its lovely quirks, imperfections, frustrations–into your values, people, actions, etc. I think that’s the rub, at the end of the day.

Design thinking has got to be more than a “mot du jour” among the business class jetset but a mode of being for a team striving to improve themselves and their products and customers.

** Design thinking is just applying routine “designerly” concepts of observing people/contexts (ethnography, people research), generating lots of options (brainstorming), stating an hypothesis or two or three (solution proposals), prototyping them somehow (paper, video, code, etc.), and iterating based upon feedback. That’s really it! Nothing too fancy, folks. And applying that across the board: finance, human resources, biz dev, operations, IT support, etc. Where anyone can feel empowered to brainstorm valuable options to solve relevant problems, and experiment with diverse solutions without being penalized. What a revelation! And for some companies and departments, it truly is…sadly.

** Design thinking has more to do with an attitude shift from “select and execute a decision” towards “what’s the problem, how can we frame the options properly, and iterate til we get it right”. It’s about adopting a mentality that “failure” (a highly inaccurate word, BTW) is perfectly fine and normal. Actually it’s not truly “failure”, but simply allowing yourself to “get it wrong on the first try”; failure inexplicably sounds sexier in pithy business article headlines ;-)

** Design thinking is NOT “designers can now do business strategy”. That is totally the wrong lesson to learn. And for any designer who thinks that she can suddenly run a business, I highly recommend reading The Lords of Strategy on the historic rise of strategy as a business and intellectual mode of thought. Really brings into brutal focus the tough issues of growth-matrices, labor experience curves, cost cutting microeconomics, and accounting standardization which I seriously doubt an designer without a relevant business/economics background (or raw eagerness/curiosity) can tackle formidably.

I challenge the typical product or service designer to go toe to toe with a seasoned biz execs or strategists from Bain, Boston Consulting, McKinsey, etc. Or HP or Dell or Wal-Mart or Boeing for that matter. Real hardcore business strategists are pretty fracking smart and driven. They may not account for the “human dimension” of empathy/imagination/iteration that designers bring to the table, but that’s where designers can help supplement, not substitute.

** Likewise, design thinking is NOT “business strategists can now do design” (as in product design or brand design or similar). Seasoned execs have a strong vision for a product, market, customer and the various elements that determine a viable business model: costs, risks, debts, sales, etc. which is awesome and can only be strengthened by an increased awareness of the observe/brainstorm/prototype/iterate cycle and how designerly thinking can help forecast opportunities and further evolve the business. But that doesn’t mean the exec is now ready to design a logo or interface just yet! ;-)

** At the end of the day, I consider “design thinking” a mental lubricant to loosen up non-design thought processes, pushing more open-minded, right-brained, synthetic problem solving that applies what designers have done for decades and thereby empower everyone, particularly designers, to have better collaborations with peers/superiors/partners.

** It’s also an attitude adjustment that all members of a company should focus and can contribute to design successes, not just “the designers”. It’s a conversation starter and team builder for all interested and engaged stakeholders…

Since I missed the original cut-off date for SXSW 2011 panel submissions due to my super crazy work schedule, I’ve started a very large head-start on next year’s submissions for the 2012 confab ;-) Just perusing the list of accepted panels for 2011, there’s quite a few very panels worthy of attending–at least based upon the fancy wordplay in the proposed titles. Indeed, sexy tantalizing risquee sounding titles have a way of seizing one’s attention, while the content is still a big question mark. Who knows how it will all go down? Hmm!

Nevertheless, here’s my proposed panels for 2012. Please get ready to vote for them when the Panel Voter re-opens in 12 months. Thanks!! ;-)

---

* Dancing with the Executives: Lessons on working within executive-led design cycles

* Jedi Councils and Tiger Teams, oh my! Alternative models of unifying an interface design language

* I love the way you touch me! How multitouch makes the mobile enterprise fun, sexy and procreative ;-)

* Wicked innovation: The “black magic” of enabling a design culture through persuasion and propaganda

I’ll be speaking at the annual Silicon Valley CodeCamp next month on a couple topics: Fundamentals of good UI and how to work with a designer.

First is my standard “stump speech”, if you will, covering the fundamental graphic design principles that govern the creation of a good software application interface, whether it’s for iPhone or TV or website or RIA app. I’ve taught and practiced according to these fundamentals the last several years for various clients in silicon valley.

1. Dialogue: user | other
2. Mental models & metaphors
3. Screen layout, structure, organization
4. Grids, Type & Color
5. Visual noise, emphasis, complexity
6. Language in UI
7. Behavior: feedback, affordance, motion
8. Multitouch UI’s
9. References (books, websites, etc.)
10. One more thing… ;-)

Second is a new talk that I’ve been meaning to do for some time now, on how to work with and develop a positive relationship with a UI designer for a project. So many techies/devs/PMs seem to harbor diverse expectations that may not map to reality so I’m hoping my talk will clarify things ;-)

1. Typical scenarios: sound familiar?
2. Identifying the need
3. Hiring a designer
4. Critical design skills
5. General design process
6. Main artifacts/deliverables
7. Prototype, prototype, prototype!
8. Big advice on working with designers
9. References (books, websites, etc.)
10. One more thing… ;-)

Last week I attended a 2-day workshop sponsored by The Design Mgmnt Inst (DMI) on improving our decision-making and concept evaluation skills, led by Jeremy Alexis, of IIT Inst of Design, and held on MSFT campus in Redmond (Bldg 92, which is the Visitor’s Center).

Overall not bad, expected more in-depth discussion but got a few nice golden nuggets to add to my arsenal of “design thinking” tools. Also some great networking with like-minded senior designers/leaders (incl folks from MSFT XBOX/games studio, HP, Kraft, Mattel, and a nuclear engineering firm!), and we indulged in some “group therapy” sessions about day-to-day “Big Design” stresses in corporate settings :-) Whew!

I’ve posted pix of whiteboard notes from group discussions and team exercises here.

---

Day 1

· Distinguished btwn “debating ambiguous ideas” VS “evaluating viable alternatives”. Often we’re wondering aloud in meetings, when we should be deciding among options against consensual criteria.

· Good decisions involve a steady beat of reflection/questioning from start to finish, not “shoot first ask questions later”

· 3 Levels of decisions: Casual (instinctive, low impact/risk), Conscious (more analytical complexity, guided by policies/standards/requirements), Rigorous (rarely done by designers, huge strategic impacts, high risk, wicked)

· General process fwk for decisions: Create a basis for decision, Evaluate options for the decision, Synthesize options and make decisions

· Key tools: Decision statement (like a mission statement but for a decision), Have a point of view (designers must have a POV to have impact/influence, not just be bland/neutral)

· Constraints (musts) vs Objectives (shoulds)

· Decision Trees as a graphical/numerical tool for gauging the better decisions. Lists out decisions and uncertainties with branching paths for each possibility, with numeric probabilities assigned. Helps provide some numerical objectivity but of course all interpretive.

· Leadership: involves being an impartial, considerate decision-maker, someone who removes ambiguity and wages influence accordingly.

Day 2

· Concepts should be evaluated by what’s desirable/feasible/viable (standard triangle)

· Avoid doing the “number of stickies” on concepts after a brainstorm; instead ask hypothetically which would you do if had a million bucks and unlimited resources (moonshot), which inspires the most passion. Forces a discussion of values/principles/goals, which may have evolved due to concepts generated!

· When clustering concepts from a brainstorm, do it by functionality (what it does), not what it is (verb vs noun or adjective, basically)

· Focus on how strongly functionally related, meaningful clusters > pruning/sifting towards a compact set of primary potentials

· Solution Architecture: individual ideas > directives > system name (hierarchy of elements basically, small to wide scopes)

· Six elements of a business model: customers, offerings, risks, economics, competitors, capabilities

· Key aspects of a killer concept: Emerges from multiple diverse sources (not just one person), Core hypotheses upset corporate process/controversial, Ask how your competitor would handle it, Tends to violate customer orthodoxy/common sense, Hypotheses make folks feel uncomfortable, Not just constrained by costs/risks/time

· Multiple “filters” to evaluate concepts: Strategic alignment > Market oppty > Capability to deliver > Worth the pay off > And is it “elegant” solution? (Pencil vs Space Pen)

Overall

I like some of the tools and concepts introduced, much of them are quite familiar from past classes/books or common sense from a business or general design sense. Nothing earth-shattering brilliant, but nice tools to keep in mind. Much more moving towards general product development influence, not just “fixing a broken interface” or “make a quick icon”, towards helping a designer become a veritable leader, trusted in the corporate context.

This has been simmering in my mind for some time now…and finally decided to jot it all down :-) Just a few strong proclamations to provoke vital team collaboration with non-designers/stakeholders and build great products and services, meant for Product Managers, Engineers, QA, and related folks. Warning: not for the faint of heart!! ;-)

Basically, if you want to achieve great design, you better be ready to do the work, break some old habits, and erase false expectations. Designing is NOT like throwing paint on walls with mere “skinning” of the interface! Instead, it takes some serious, tough, negotiated compromises and earnest debates to work together towards the best solution. Here we go…

1. “Need it by tomorrow” is not a schedule, it’s a freak-out. A design solution needs a proper runway of exploration/iteration/feedback to lift-off successfully and get it airborne. Plan for design time accordingly into your schedule! (Do you even have a schedule? If not, make one first!)

2. No documented business or technical requirements? No design for you! Get your stuff together first BEFORE asking for the designer to “make something”. If you need help with that, then best to stage some discovery workshops or strategy discussions with senior design leads, not “hey make a mockup and see if it sticks”.

3. Not everyone can be a driver AND approver AND contributor of a proposed design solution. Apply the DACI model (driver-approver-contributor-informed) to be effective, else you get the “too many cooks” problem. Sucks when making a stew at home, and it’s a nightmare when building a complex product.

3b. Relatedly, while everyone has an opinion about a design, the designer is not obliged to react to all of them. It’s true. Stop crying and leverage the designer’s professional judgment and experience. That’s why you hired that person, right??

4. Product Managers are not art directors. End of discussion.

5. No stakeholders or users/scenarios/markets identified yet? No design for you! See Number 2 above.

6. Want user feedback? Then fold it into the schedule and make sure the dev team is ready to uptake changes as needed. Don’t say you want user feedback and then scoff at changes. That’s called hypocrisy. Not a fan and won’t help your product or customers.

7. Email is not the record. Get a wiki, evernote, sharepoint, google docs, perforce, SVN, whatever. Just something defined as the central place for docs/reqs/specs. Not email! Way too chaotic.

8. A design sketch is never the spec. Neither are wireframes, which are hi-level blueprints. Specs must be reviewed and signed-off BEFORE implementation can begin.

9. Playing the “The [big name exec/director/VP] likes blue” is a crutch. Real defensible rationale please for design pushback/changes.

10. Design takes a full-body commitment. Not ready yet? Call the designer when you are. Or, admit you’re not ready and you’d like help getting ready. Senior designers are often very happy to help get your team on the right track towards product development prosperity, since it benefits everyone involved. Just don’t act like a crybaby when they suggest doing things you’re not used to, like writing down requirements or a design brief.

There’s so much more, but by following these essential points, the likelihood of team design success is much greater!