Category: General Stuff

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!

Every design has three fundamental facets that serve as a framework of analysis when identifying opportunities to evolve the design further, or extend it into families or standards for related designs.

What is inherent: This pertains to the product’s DNA that define its character/persona/voice and its reason for existence. Strongly correlated to product/company brand. Concerns its purpose and core functionality, expressed in successive layers of materials & interactions within the product. These are the qualities and natures.

What is emergent: This is the value that emerges in usage by the intended audience within a given context. The benefits, consequences, emotional/psychological impacts, the resultant quality of experience. These are the values and principles.

What is persistent: The material attributes of the product (visual, structural, formal) that persist across the family line or successive evolutions. These are practical and durable.

To properly take flight and thrive in the upper levels of product/user experience excellence atmosphere, a design needs a significant amount of runway (to use a very extended airplane metaphor :-)…What do I mean by this? Simply put, there’s need to be thorough time, discussion, collaboration, and exploration of possible solutions before settling on “the design solution” to be implemented. Too often PMs and Devs simply want a quick easy fix to solve some bug and then push it out per some pre-determined timeline, thus ignoring the need for proper design engagement and iteration.

That “runway” is the social and chronological space for the design to coalesce into a form worth lifting off. Time is key element, setting up a wide boundary for opportunities of exploration. But also there needs to be social/collab space of discussion, interpretation, identification, iteration, review/feedback, etc.

And within corp environs featuring multiple products, this runway may require discussions with other designers, evaluation of patterns/standards, ensuring consistency of visual and behavioral approaches, with outlets for inventing new standards if necessary.

To get a design properly airborne, there needs to be a sufficiently long runway to get it up to speed properly so it can thrive in production and implementation. Otherwise, the risk is a design that hits some bumpy turbulence with broken visuals, unaccounted or clumsy interactions, missing features/paths/flows, and lots of bugs unnecessarily filed and triaged (which translate into future patches/updates that jam up schedules, etc.).