Category: General Stuff

This has become somewhat of a mantra internally amongst the Citrix Product Design Team. It’s a fun phrase, but also a serious statement of the need for an increasingly scarce resource amid multiple project release cycles– Time! Yes, everyone and their neighbor begs for more time to get something done. But why exactly does good design in particular take time? Let’s try to identify the reasons, for those folks who may be somewhat unconvinced (ahem, stressed out coders and anxious product managers ;-) Hopefully this will lead to a productive conversation around the need for better scheduling and project management overall for everyone’s benefit, especially our users at the end of the day.

* Time for understanding a problem; from multiple angles: biz / tech / social / visual / etc. This involves gathering and processing information, shaping a mental model of the context and audience as well. Learning about the audience’s goals and attributes.

* Time for generating lots and lots and lots of solutions: sketches, pixel comps, and prototypes. Yes, designers can (and often do) speed up this area, but work becomes sloppy with opportunities and insights missed in the heated rush for some artificially imposed, ASAP-style deadlines.

* Time for creating precise, pixel accurate comps. Quality is key! Quality takes time. This includes fonts, grids, colors, images, etc. Diligence, judicious choices, practicing restraint, continual quality checks…all of that takes necessary time.

* Time for reflecting upon solutions to appropriately judge/evaluate which have bonafide merit. Rushing to judgment can be a mistake in the middle of the night, especially when in the morning’s hazy light that it’s clear a better solution exists. It maybe clear that last night’s rushed option is deeply flawed…

* Time for re-evaluation after the intial cut of designs, to re-interpret their value and socialize with folks. It takes valuable time to make sure relevant stakeholders understand and support design decisions accordingly.

* Time for conducting thorough user studies and truly digesting, processing the feedback, not just “court reporting” what some users have said, but actually assessing / distilling / synthesizing. And making proper judgment calls thereafter for the design.

* Time for re-visiting the solutions and adjusting, again with care & diligence to ensure the highest quality results are borne out for final production.

So yes–it takes valuable time to deliver a high-quality, well-developed design solution that is thorough, significant, and strongly defensible from any angle. The good news is this time can be compressed via talented smart designers, strong collaboration, rapid prototyping, and guerilla user studies. Yet the time for reflection, quality control, and diligence of craftsmanship cannot and should not be ignored or short-shrifted. To do so only imperils the integrity of the design solution, and implies a lack of interest in doing good design. Good design is an imperative that takes balance and compromise, back by strong principles of craft and quality. If the time frame isn’t working for your project (i.e., tomorrow ;-), then please have an honest conversation with the designer, and work out how to achieve what everyone wants: a beautiful, functional, amazing product users will love. Who doesn’t want that? It might take several versions but let’s make sure the path is set with mutual agreement.

Today I had a fabulous time presenting to approx 200 attendees at the Silicon Valley CodeCamp at Foothill College, about fundamentals of good UI design, and then also about partnering with designers to deliver great products. Thanks to all who attended, and your questions/debates! :-)

As promised I’ve posted the (sanitized) slides; I had to remove some stuff from my past clients / projects… Please see below:

(FYI, for some reason, Google Chrome doesn’t read the PDF; have to right-click and save, or use Firefox and do same thing, right-click and save the file…sorry!)

** Fundamentals of Good UI Design PDF (23 MB)

** Partnering with a Designer PDF (13 MB)

That’s what I wanted to hear when I heard the sad news. Just one more thing. That he’s not really gone. That it was just a bad hoax or incorrectly tweeted news item. Just one more tiny, fragile, ever-so-delicate hope that he did have decades more, as he reflected upon in his memorable Stanford address, to continue innovating not just “cool tech”, but upon our daily lifestyles, cultural attitudes toward technology, business models and media ecosystems. Just one more chance to push the conventional boundaries of possibility and inspire and educate us about how to breathe joy, delight, and humanity into the technologies we use. Just one more moment to hear a rousing, superlative-rich exultation of a new digital wonder beautifully and elegantly designed “for the rest of us”. Just one more spark to ignite our own desires and passions and ideas to create a better world for generations, by truly bridging the disparate but essential worlds of liberal arts & technology, as he had proven many times over. Just one more glimpse… to see this gifted visionary signal the promise of something that we will love, that we didn’t even know we needed, defying expectations and inspiring us to rise to a new challenge. And he kept raising that bar so damn high ;-)

Alas, there will no longer be “one more thing”…

Except this – One more thing, Uncle Steve. Thank you. For everything.

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!

 

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.