Interview tips for UI Prototypers

Recently we’ve been interviewing for some UI Prototyper openings on the Citrix Product Design team (please ping me if truly interested :-). This has brought to everyone’s minds certain things that enable a successful interview and portfolio review…

** First and foremost, show up genuinely interested, passionate, curious about the opportunity. Also, please do some homework about the company’s products and latest news. Just 30 minutes on Google and social news sites is all we ask – it’s not that hard. Arrive prepared to ask and learn more. That stuff really does matter, even for a UI Prototyper. We want interested teammates!

** Prototypers should be prepared to show & describe their process clearly, show any experiments that failed, and articulate lessons learned. The best prototypers draw and mock up stuff too. Or “sketch with code”. Show us! (within the limits of NDAs of course)

** As a bonus, show us relevant stuff done on your own time, as personal projects or hobbies. We love to get a full balance of pertinent skills and projects that get you excited, so we can better assess the role fit.

** Tell us the story about your prototypes, don’t just click through and say “And then we shipped it”. More useful for us: Tell us your main roles, the choices made, key issues surfaced, how your prototypes addressed them (or didn’t), the impact on overall project and user studies, and timeframe too! Was it a one week throwaway to convince a VP, or a full-blown 3 month effort to define the final spec?

** This goes for anyone interviewing, but don’t assume anything. Be explicit about the problem attempted to solve, the context, goals, constraints, etc. Even if it’s for a super well-known brand like Yahoo or YouTube, framing the problem is always a good thing for your interviewers.

** Explain technical methods used and also WHY: performance boosts (any stats? comparisons?), ease of refactoring, modularity of code, etc. What are the pros/cons, risks, issues, etc. Please don’t just say, “And here I used CSS3 selector blah blah”. Why? What benefits achieved?

** Describe approaches to triangulating amongst Design, Dev, and Research all together… prototyping for tests vs quick explorations, vs handing code to Dev.  What challenges were faced and how were they handled?

** Perhaps the most critical keys to success for a UI Prototyper are communication and chemistry with the team. What do you do to enable that, and how do you respond when things break down a bit?

 

There’s many more, but these are the major points that should lead to a successful portfolio review and interview round for UI Prototypers. Good luck!

 

No rules, recipes or formulas: just practice!

As I prepare my upcoming talk for the Silicon Valley Code Camp on “Fundamentals of Good UI Design”, I keep returning to a piece of feedback I’ve received in the past for my popular talk: “Enough with the theory, just please give us the rules!”

Sigh.

By and large my audience’s reaction (mostly coders and managers–all non-designers) has been very positive and receptive, with lotsa great questions and fun debates thereafter. But my mind returns to that specific point with some crestfallen hopes. It should be clear to anyone in software that there are no rules, recipes, or formulas for good design. Crafting an amazing UI design that permeates multiple devices and contexts, while enabling utility, joy, and profits is nothing like ticking a checklist or baking a cake. And even then, isn’t it almost always true that your cake doesn’t taste exactly as your mom’s (or Martha Stewart’s)?  :-) There is a certain “x-factor quality” via one’s expertise, intuition, talent…and in design, this is manifested through deep team collaboration.

Now, of course, there are general UI guidelines and visual standards (for example, the Apple Human Interface Guidelines (HIG)) and UCD best practices derived from real case studies, as well as UI pattern libraries cataloging the various ways to, say, enter a calendar date. All of which is great fodder for product teams!

But none of these can or should be taken as precriptive rules on “how to design” a software interface. There is always variance, which requires sound judgment and takes time to evolve, and reflect upon. The awesome diversity of situations, users, roles, features, contexts, business drivers, and technologies, makes a compact rulebook for design virtually impossible. Even declaring “Never use Comic Sans” can’t be a rule, because, no matter how unimaginable, there might be a tiny excruciating case where using this font may work (abhorrent as it may be! :-) Flat-out copying (imitation) isn’t sufficient either, to create a set of pseudo-rules based upon “the other kids are doing it”. Just because Facebook or Apple (to name some hugely popular hi-tech firms) does something doesn’t mean you should too. Of course, they’re fine as starting points to get wheels turning, begin exploratory sketches, etc.

A design problem is like a massively multivariable calculus problem, all the social / technical / visual considerations that go in, and how they change per situation: a mobile app for a pizza company, a heart monitor for a local clinic, a tax optimization app for the accountant, etc. You can surely apply contours of a “user-centered design” process, but that must flex per project or team too. Being able to maneuver the variables accordingly is key; and the guidance should come from principles and values and goals, from all key stakeholders.

Dieter Rams’  succinctly wise 10 Principles for Good Design does read like a series of absolute commandments; yet they are principles for guidance of a designer’s intentions and behaviors. They don’t tell you where to stick an icon or what button size to use. Nor should do they. The point of design, as a problem-solving activity, is the arbitration, the dialogue, the mediation of conflicting priorities to arrive at a balanced choreography of visual / technical / profitable elements. In doing so, it yields discoveries and understandings that should lead to a better product and user experience overall. And that, quite simply, takes years of practice, honing your judgment, learning lessons, deciphering successes & failures, and developing a viable point of view. It takes exposure, training, repetition, imitation, to shape that sensitivity, or knack, for design problems and solutions.

But what are those areas of practice, the core elements that comprise a good software design? Now that we can itemize! Areas of communication & interaction: layouts & grids, typography, color, iconography, behaviors, patterns, metaphors/models, and usability heuristics, to name a few… (Dan Saffer’s book on Interaction Design is excellent in summarizing the core areas). And the fine art of design synthesis, making those “creative leaps”, after thorough logical analysis, that includes many methods. Jon Kolko has an excellent short book summarizing this point. And you just gotta practice, practice, practice, studying what has succeeded and failed. Iteration and feedback are vital.

So, there are no rules or recipes for good design. Sorry! There are general practices, principles, guidelines, patterns, and of course teachings from legends like Paul Rand, Dieter Rams, Charles Eames, borrowing across contexts and time periods. You study and practice, with a good faith commitment. And of course, expressing the rationale for design decisions, from these sources is key. For me (and what I try to impart to others), that’s what makes design such a rich and wonderful field of investigation and invention. The day design (interface, product, fashion, furniture, etc.) is reduced to a set of rules is the day I leave this field, for that is the day design has lost its potential for constant evolution and change. The ability to learn about design through practice, iteration, imitation, and innovation is the source of joy design grants me, and hopefully to others who truly aspire to create good design.

Steve Jobs: design hero

Steve Jobs is not dead, as of this writing. He has resigned as Apple CEO but still serves as Chairman of the Board. He remains a larger-than-life figure that symbolizes, embodies, and exemplifies the “design-driven executive”. And he’s my design hero. I’m guessing for other designers as well, though some may not want to admit it publicly since he’s such a non-UCD rule-breaker, and game-changer. (sorry, I had to say it ;-)

This is not a eulogy but a declaration to aspire.

Steve has proven that we can dream bold beautiful visions of a humanistic yet technologically ambitious future, and make it happen…with amazing profits. It’s what almost every designer strives to achieve, and he has done it–many times over.

He has proven it can be done, with not only superb, almost maddeningly obsessive design craftsmanship, but also brilliant (perhaps brutal) business savvy, generating billions of enviable dollars. Vividly gorgeous products and interfaces that can deliver the cash results Wall Street demands…nope, it’s not just lipstick. And any sucker who thinks it is, simply doesn’t get it. Steve Jobs, maybe more than anyone, has truly achieved the “integrative aesthetic experience”, as philosopher John Dewey described it, successfully. It can be done.

He has transformed how people regard design as something that positively shapes lifestyle and behavior, ushering novel eras of information, entertainment, communication, and yes even enterprise data, from the original Mac to iPod to iPhone to iPad. It can be done.

He has proven that designing the future doesn’t have to be some 20% “innovation exercise” shelved due to some ornery process or lack of user data, but can be an aggressively optimistic posture of making a “dent in the universe”…practically re-conceiving our lives, impacting literally decades and generations. Babies in strollers along University Avenue in Palo Alto today may never know what a keyboard or mouse is, because Steve dared to challenge longstanding assumptions and demand a better intuitive way. He proved it can be done…meaningfully and beautifully.

For every designer who seeks a powerful, luminous vision of a better tomorrow, with beautiful style and elegant functionality, Steve Jobs as Apple CEO has proven it can be done. There is hope: he has educated a few generations now, delivered fabulous examples (both good and bad–remember the G4 Cube or MobileMe?), ushered a forward way of thinking about technology that’s fresh, simplified, elegant, and enriches our lives. He has made computers “magical” and objects of desire. He has elevated our expectations to new heights when it comes to “hi-tech design”, as a tastemaker, a trend-setter, a businessman, a visionary and…a design leader. He has proven it can be done, successfully.

I often talk about how design can’t be “proven”, but rather a “demonstration” for a context–an admittedly academic subtlety ;-) But Steve Jobs has proven that a technology company executive, through the phenomenal force of their charisma, vision, and smarts can champion good design values, produce well-crafted products, and deliver stellar financial results. And millions of people, from schools to hospitals to banks, have reaped the benefits. He has proven that visionary design works.

That’s why Steve Jobs is my design hero. This is not a eulogy but a declaration to aspire. Let us all as designers strive to be so bold, so daring, so crazy, so vivid, so innovative to pursue a profoundly better way…and prove it can be done. After all, as Steve said, “only real artists ship”. So, thank you Steve for proving it can be done. Now it’s time for us to take that lesson to heart and make amazing happen.

Why designers don’t like A/B testing

Awhile back I saw this tweet from a UX consultant that struck a nerve: “I don’t trust designers who don’t want their designs a/b tested. They’re not interested in knowing if they were wrong.”

I responded quickly in the short staccato bursts afforded by 140 char limits while I was (at the time) jamming on some key designs needed by the Citrix CEO for his keynote the following day. Oops! Perhaps not the best time to engage in twitter arguments ;-) For a long time now I’ve wanted to elaborate beyond twitter why (I think) many designers (certainly myself and most of my closest peers) do not love A/B testing.

And believe me, it has nothing to do with a lack of interest in being proven wrong.

As a former UI design consultant for two of the most famously data-driven internet firms, Netflix and LinkedIn, I totally understand the arguments for A/B testing and its commercial value at mercilessly incremental levels of marginal revenue value, literally nickels & dimes across millions of clicks, etc. Yep, I get all that. Massive scales, long tail value chain, so forth. Tons of money! I get it.

However, as I responded via tweets, as a designer, I must defend and assert aesthetic integrity as much as I can, keeping in mind key business metrics and technical limits. And, quite frankly, the first victims of A/B testing are beauty, elegance, charm, and grace. Instead we get a unsightly pastiche of uneven incrementalism lacking any kind of holistic cohesiveness or suggestive of a bold, vivid, nuanced vision that inspires users. A perplexing mashup of visuals, behaviors, and IA/navigation that leaves one gasping for air. It is the implicit charter of a high-quality design team (armed with user researchers and content strategists!) to propose something a user may not be able to imagine, that is significantly better, since they are so conditioned by mediocre design in the mainstream. (Look up Paul Rand’s infamous quote)

So why don’t many designers like A/B testing? I think it’s mainly the following:

* A/B testing may only be as effective as the designs being tested, which may or may not be high quality solutions. Users are not always the best judge of high quality design. That’s why you hire expert designers of seasoned skills, experience, judgment, and yes the conviction to make a call as to what’s better overall.

* As is true with any usability test, you gotta question the motives behind the participants’ answers/reactions. Instead, biz/tech folks look at A/B test results as “the truth” rather than a data point to be debated. Healthy skepticism is always warranted in any testing. Uncovering the rationale for a metric is vital.

* A/B testing is typically used for tightly focused comparisons of granular elements of an interface, resulting in poor pastiches with results drawn from different tests.

*  How do you A/B test novel interaction models, conceptual paradigms, visual styles (by the way, visuals & interactions have a two-way rapport, they inform each other, can’t separate them–see Mike Kruzeniski’s talks) which may vary wildly from before? Would you A/B test the Wii or Dyson or Prius or iPhone? Against what???

* A/B testing locks you into just two comparative options, an exclusively binary (and thus limited) way of thinking. What about C or D or Z or some other alternatives? What if there are elements of A & B that could blend together to form another option? Avenues for generative design options are shut down by looking at only A and only B.

• Finally A/B testing can undermine a strong, unified, cohesive design vision by just “picking what the user says”. A designer (and team) should have an opinion at the table and be willing to defend it, not simply cave into a simplistic math test for interfaces.

——–

Ultimately, no A/B test proves a design “wrong”. Designs can’t be “proven” wrong, only demonstrated to be in need of more effective improvement or better iteration. Therein lies the real flaw of the original statement. This assumption that designs are either “right” or “wrong” is inaccurate. Instead designs are “better” or “worse” depending on the audience & context and purpose, not to mention business strategy as well. Designers (and researchers) seasoned in the craft of software understand this deeply.

A/B test results perpetuate a falsely comforting myth that designs can be graded like a math test, in which there’s a single right answer. Certainly this myth soothes the nerves of an anxious exec about to make a multi-million dollar bet on the company’s future :-) Wanna relieve anxiety? Take prozac. Wanna achieve top quality design results, then assert confidence in a rigorous creative process as promoted  (and well articulated) by Adam Richardson, Luke Williams, Jon Kolko,  and others…as well as in your design team. Because, if you hired top quality designers & researchers with a sensble PM and skilled Engin team, you more than likely have a pretty darn good product on your hands .

At end of the day, A/B testing should NOT be used as a litmus test of a design or a designer. It’s a single data point, that’s all. It can be compelling, no doubt. Its level of impact and value varies per product/company/market, however. And just like Roe v Wade which has become an unfair litmus test for Supreme Court candidates (as part of a greater political-media circus, a whole separate issue), using A/B testing in this way only polarizes things, and makes the vetting process of a design or designer unnecessarily difficult. And you risk dissuading top quality design talent from joining the team’s cause for good, beautiful, useful designs that improve the human condition. After all, isn’t that what we are all fighting for? A/B testing is simply one tool; not something to judge the character or quality of a professional (nor her work) striving to do what’s right with integrity.

 

Fundamental design truths (part 2)

A few days ago I published a few initial design truths as I see them, per my professional insights across a variety of contexts and projects. As promised, here is part 2 featuring a few additional thoughts…Enjoy!

All design is political : I don’t mean in the “conspiratorial backstabbing” sense, but that all design necessarily involves navigating & meditating socially constructed purposes/values/opinions from invested stakeholders of differing, often conflicting backgrounds (ie, engineering vs business vs human factors vs marketing). To put it bluntly, everyone at the table has an agenda, and it’s not just you. As a design leader, you must ascertain those agendas and navigate/mediate with persuasive skill a balanced approach with conviction. Hey, it’s not easy!

As Dick Buchanan once told our grad seminar class, “If you want to get away from politics, design is the last place to hide. It’s deeply political.” Limited budgets, tight resources, impossible constraints, shifting priorities, short schedules, and of course those persnickety customers ;-) Whew! Compounded with compromise and trade-offs, the political aspect of design can make it brutally difficult for many. The ability to argue, champion, evangelize, and reason is vital to thrive well. Not for the faint of heart!

An aside: Buchanan once described politics to me as “the subtle maneuvering of ideas to advance selfish or collective aims”, with an emphasis on rhetorical agility in influencing others to follow your lead, per Classical criteria for oratory brilliance (Socrates, Cicero, Marcus Aurelius, Augustus, etc.) It is a rhetorical concept: generic, archetypal, overarching, and adaptive to changing situations.

Every design project has implicit assumptions / dependencies / expectations : You gotta clarify implicitly held  team beliefs about users/markets/contexts/activities/goals. You must diligiently identify any technical or political/social dependencies that will enable your solution to be set up for support and success by other folks, esp execs. Finally, managing expectations laterally with teammates and upwards with directors/sponsors is vital towards securing design success. Yep, it’s all those “soft skills” in addition to your technical powers, to help drive a satisfying conclusion to a project. Often this requires the designer to play secondary but critical roles of advocate, educator, facilitator, coordinator, even “therapist” to some degree, with teams. Being that Yoda-like coach helping teams uncover their own latent motives and values is hugely valuable!

There is no one right way to design : Yes, it’s important to apply UCD ideals and HCI methods. But The fact is there are many approaches to designing. Dan Saffer articulated several approaches in his book Designing for Interaction, from user-centered design, activity-centered design, systems design, and even “genius design”. Folks talk about “data-driven design” as well, reliant upon extensive statistical studies for design decisions. The inherent pluralism of design practice, with values and methods of diverse backgrounds, makes this a broad field of numerous discussions and questions, ushering even more and better approaches. Again, that’s a good thing! No designer truly wants just ONE standard way to design–even the vehement defenders of UCD or Data-driven design. It would be frankly boring, and deny us the very cultural, aesthetic, methodical richness such diversity affords us, to enable unique and rich possibilities. And as I explained before, every seasoned designer applies multiple postures in designingsomething, given different problems & contexts.

Finally, all design comes down to one thing: influence. I recall one of my very first meetings with a design manager, shortly after starting at Oracle. He said to me, “Uday, you should focus on only one thing, and that’s influence.” I nodded obediently not truly grasping the totality of what he was saying. But a decade (and several projects / employers / clients) later I finally get it. Design is about change, at varying scale or intensity. To change a prior status quo, you must exert influence and persuasive ability upon those resistent (and of course, there’s a TON of folks who want to leave things well enough alone!) so they buy into the vision you are providing them. Yes, you showcase your nice comps, builds, prototypes, demos, etc. but the behavioral and emotional attitude (ie, hearts & minds) must be won over in other ways. Same goes for consumers roaming the aisles or surfing the web: every piece of design is a signal of influence, trying to convey how such a design can empower and behave positively.

Let’s face it, Steve Jobs makes Apple products seem that much better because he himself is a powerful force of influence, swaying our opinions through his uncanny knack for tapping into our desires, his charismatic persona, demand for excellence, and sharp insights that cut to an issue directly. It’s not manipulation per se, but instead what Barack Obama had once called “the charisma of confidence” in conveying your ambitious yet unfamiliar vision for how to improve the human condition. In short, design is a complex game of influence, perception, and confidence.