Three words for 2020

I’m kickstarting a new tradition to commence this new year (2020) that’s borrowed from my master’s thesis at Carnegie Mellon — nearly 20 years ago! Instead of trying to trying to massively survey anything and everything on a topic, simply select three words as the cornerstone of analysis, the intersections of which form the basis of a theme. So instead of “resolutions” per se, which we know often fail for reasons, I’ve decided to focus on three interrelated concepts or words that pertain in various ways to my life — at home and at the office — to give me a focus for exploration and deepen understanding, or utility of them. This year I’ve selected ambiguity, synthesis, and resilience. Let me explain…

  • Ambiguity: there’s a great deal of “not knowing” or “not understanding” in the ever-changing rhythms of work and life, and thus learning how to roll with the inevitable punches (or flow with the turbulent tides) becomes vital. And in some instances, ambiguity can become a moment for creativity and resourcefulness… 
  • Synthesis: Steve Jobs famously said that creativity is simply “connecting things” — correlating moments of inspiration, data points, lessons, conversations, tools, etc. to arrive at a better understanding or informed intuition. How for can synthesis go, what are the limits, how can this become a way of navigating ambiguity perhaps?
  • Resilience: Setbacks, mistakes, failures, and just plain awkward “oops” moments are inevitable when pursuing something new or difficult (or dealing with a new thing thrown at you!) …and must be respected as such. Being able and willing to bounce back stronger and more confident. Getting comfortable with being uncomfortable is a big aspect, too. What does resilience look like, and how it can be manifest in micro and macro forms?

As events happen and situations/conditions evolve throughout the year, I’ll be applying these three words accordingly and post accordingly as to the progress of this approach. Stay tuned!

Retro classes for “classic design skills”

Recently I commented on a LinkedIn post that maybe it’s time to bring back “retro” design classes which foster what I’d term “classic design skills”.

In this era of churning out “UX Designers” through 6-week academies & online programs, there’s a vital need to fill something far more valuable then a quick easy certificate to get a UX job — a deeper understanding of visual communication with manual methods of making them, which demand patience & persistence. Not everything can be a Sketch symbol or Figma component that you copy & paste to meet your engineer’s sprint deadline — nor should they be! To be a good designer one must learn the arts of making with various materials and tools and forms, with deep appreciation for the nuances of what emerges as a result. Mastering that, while incorporating into your own process and approach is one clear indicator of being a good designer. This is especially true with visual communication and related areas, to truly round out a designer’s repertoire of technical ability (making things) and perceptive sensibility (seeing possibilities). 

Which “retro” classes am I referring to? Well, admittedly the classes I myself studied 20 years ago as a student, the benefits of which still influence my work and approaches today:

  • Scientific illustration — to help focus your attention on tiny subtle details and also reveal how looking at something at different angles alters your depiction (and understanding) of reality.
  • Figure drawing — to learn how to render human figures in space and foster a kind of empathy for people in different positions and contexts, via charcoal, graphite, crayon, etc. Truly feeling out the emotional tenor and textures of the moment, which go way beyond simply filling out some persona template!
  • Film photography — to understand how manipulating chemicals & lenses with patience over time lead to images that tell powerful stories, especially in black & white. Hey, you can’t find the perfect image on unsplash all the time!
  • 3D model making — No, not the one using software (like Alias, Maya, etc.) but actually going to the maker-shop to saw, sand, join, drill materials and shapes together to make something of practical use. Yes, it’s super scary, but a worthwhile challenge to foster profound appreciation for the complexity of manufacturing real things. We still live in a world of physical things, and relating those concepts to software UX design can shape a renewed appreciation for the complexity and difficulty of making.

One more thing… perhaps we need a class on simply whiteboard sketching & storyboarding (comic book style) to help visually communicate ideas effectively and why they matter, especially to our non-visual peers in product development who need a little help creating shared agreement on a design and its value. Especially if the root of the team’s issue is not understanding the human drama of the experience we’re trying to improve upon with a certain feature.

Maybe by going “retro” we can amplify & recapture the power we have as designers, defying the pigeonhole notion that we’re simply there to make wireframes & mockups for sprint deadlines. But instead we can help clarify, illuminate, dramatize, perceive, and animate new perspectives on a problem with multiple approaches to bring others on our journey of understanding and solving problems. This is beyond deadlines as well; these classes go a long way towards one’s own growth as a designer, which lasts a lifetime. 

The victims of velocity

Moving faster and faster and faster. That’s just the norm nowadays with software development cycles, most noticeably at startups but prevalent pretty much anywhere, as artificially self-induced pressures dominate — but that’s a whole other topic to explore 🙄🤔This self- imposed urgency to deliver more at a higher rate of velocity — being diligently measured, of course — is immensely consequential, adversely affecting many crucial elements, which I call the “victims of velocity”, many of which ring true for designers striving to deliver “good design” to their customers amid rushed cycles. 😣#SorryCustomers

Quality of product

Craftsmanship — Pixel perfection & precision, consistency of foundational elements: color, grids, fonts, icons, terminology, etc. Craft matters in reinforcing the notion that this multi-million dollar product is worthy of the price paid, not something that looks shoddy or thrown together, thus eroding trust and goodwill.

Forethought — Dependencies & relationships across screens + flows, this often leads to broken navigation, dead-ends, weird loops or side-alley paths are forgotten. It takes time to think through all the paths & journeys & taskflows…and yes, also the edge-cases!

Errors/warnings — What’s the language conveyed, with supportive recovery actions to be taken if user does X instead of Y, or the system doesn’t accept input Z? Often it’s hastily done by QA or Front-End Eng at the last minute, which never ends well for our hapless, frustrated customers!😞

Onboarding & transitions — Yay the feature shipped! Umm, how does someone actually know about it and learn how to use it? This is an especially critical issue if it’s replacing a previous feature or method the user was already habitually doing. How do we transition them to the “new way” graciously? This is often a last-second item, again at the customer’s loss. 😒

Validating actual value / utility — So, did anyone actually verify if this feature is one that customers will truly value in their daily workflow? Are we building to ship just to make the PM happy, or building to empower customers to become a better version of themselves, that they personally appreciate? 🤔🙄

So those are aspects of the product itself being impacted adversely. It’s also worth noting other victims of velocity, which are inherent to the designers’ ongoing cycles of creativity and innovation:

Rituals of design

Daydreaming — Sometimes you need that empty whitespace of time & activity to let the brain do its thing, marinating and meditating on concepts, just wandering the forest of reverberating notions and see what resonates and emerges. Not something that can be rushed or done “on demand”. 

Serendipity — The wonderful happy accidents of colliding ideas, synchronous conversations with peers struggling with the same problem, experimental models & sketches. Again, not something forced or rushed.

Empathy — This takes time and is cultivated over time through direct and indirect contacts with customers, at multiple evolving levels of understanding. Threads of observations and insights emerge through anecdotes, conversations, and so forth…

Designers know deep down that imagination, empathy, and serendipity play vital, if subtle, roles in discovering & enabling a compelling aesthetic experience, even potentially a breakthrough product that reshapes an industry. But how can we preserve those qualities amid increasing demands for moving faster at higher cycles/rates of velocity, shipping features and code that meet internal process targets… but not actual human needs or desires? How do we ensure humanistic aspects essential to what is good & beautiful don’t become “victims of velocity” per artificially induced pressures? 🤔😬 It’s an ongoing conversation, and battle we must all fight. 💪🏽🔥

Storyboarding out the human drama within

It’s typical in product development to write “user stories” & “use cases” based upon a self-identifying rubric meant to suggest a whiff of empathy: “As a geologist analyzing rock patterns, I need…” Of course it’s a pale shade of what true empathy means, codified into a simplistic formula to crank out at rapid pace & high volume use cases to fill up engineering backlogs — idle hands are wasting investor dollars, amiright?! 🙄😝

But what’s truly needed is a way to visually dramatize the dynamics of people in their contexts using diverse tools to accomplish their goals. Yes, inviting non-UX peers to join site visits is one way that helps vivify what’s really happening in a user’s life. But that’s not always practical or feasible (it’s a bit impolite to have 5-7 people ganging up on the unwitting user at their office!) so another approach is storyboarding — just like comic book style drawing, actually illustrating out the scenarios for everyone to see…and understand. This, of course, is nothing new…

I’ve lately been re-training myself to get back into storyboarding, inspired by fantastic work done by a very talented colleague. Her drawings sparked productive dialogues with Product & UX leadership about the nature of the feature, how to validate its purpose, and plans for evolving the overall direction (basically, a roadmap). So, how does one get started? 🤔

My process goes something like this:

  • Study & internalize research (first or second hand) about users, contexts, tools, problems — as much relevant info gleaned from Product, UX, Marketing. Talk it out where possible to get more understanding as to what’s happening, and fill-in missing gaps. 
  • Ponder the human drama — what’s the conflict, frustration, un-met need, and emotional vibe. Who else is involved? Where are they located? How are they communicating? 🎭
  • Outline a quick narrative, in text; I typically long-form write it out on stickies or in my notebook. 📒✍🏽
    • That narrative should capture a specific “vignette” of activity, maybe a specific task or two.
  • Start roughing out (pen on paper, or on whiteboard) that sequence of panels — again, comic book style — that reflect your narrative. 
    • There’s no need to be fancy — you’re not trying to re-create Frank Miller’s Dark Knight Returns here. Focus on blocking out key scenes, characters, emotions, basic actions. 
  • Over time, keep iterating & evolving as you develop a better sense for that human drama, the real issues that need to be resolved by your feature / product / service. Toggle back & forth among the research and narrative. This is truly the key point of UX storyboarding, to actualize empathy with illustrative abstraction (a bit of a contradiction, perhaps) — but it’s not fictional; it must be based upon real research findings: observations, anecdotes, etc. 🤓
  • Draw a cleaned up final version that can be shown to your stakeholders (**Note: I didn’t say “pretty” — that’s not the goal) My colleague had printed it out large to put up on a wall to allow for shared discussion among stakeholders in a conf room. I’ve used mine in PPT slides as well.

Either way, the subsequent discussion with stakeholders should highlight what the key scenes & emotional aspects mean for the opportunity to help resolve them, to improve the scenario. What I’ve witnessed is increased understanding by Product and UX leaders once seeing the storyboards, connecting them back to the more technical requirements of what to build. Storyboards deepen the appreciation for why…and “what else we need to be aware of”, the peripheral stuff that also matters.

Give all stakeholders stickies + markers so they can capture doubts or areas of further research. The result is an improved sense for how a presumed feature or product could better address user needs — but in a highly visual manner that gets everyone outside of JIRA or Word docs, which tend to drive thinking down a certain road. Instead, storyboards expand our interpretations of what’s possible or necessary, due to illustrating the human drama of conflict, emotion, and communication. Then those hastily cranked out “user stories” for the backlog can take on a more momentous sense of urgency and importance they’re actually due! 🤠👍🏽

Sketch to explore, not solve

Sketching is quite simply the essential skill for any designer at any level. This is a definitive point of fact. And yet, lately I’ve noticed an odd reluctance to sketch out ideas, particularly among candidates we have been interviewing to join our UX team, for which I serve as UX Architect.

I wonder if this reluctance is due to an unfortunate prevailing presumption that “sketching = solving”, as if putting pen to whiteboard means one has the right answer. Far from it! Sketching is more often about probing & exploring a problem space visually. This includes a re-articulation of the problem statement, usually as a re-confirmation of what was heard or interpreted from the Product Manager or Engineer. This goes right at the fundamental irony/contradiction/tension of designing: in order to understand the problem, you need to create something suggestive of potential solutions — which are knowingly “wrong” — yet they help suss out latent constraints, unrealized patterns, hidden relationships, and even surprising opportunities. To break out of the prison of “analysis paralysis” — and I’ve seen candidates do this, writing gobs of words all over the whiteboard, spinning in circles — you gotta start sketching something, which will activate other parts of your mind & senses. You might discover something new that re-frames your understanding of the problem! Therein lies the profound power & benefit of sketching to explore, not just solve a problem.

And, taking it a step further, there’s the collaborative (or more precisely, coconstructive) nature of sketching on a whiteboard in real-time with cross-functional colleagues. The sketching activity encourages a dynamic of quickly thinking, judging, assessing, filtering collectively, sparking additive notions or supplemental considerations from multiple perspectives. That’s a very good thing! Hopefully others will jump up, and in that moment will take a pen to sketch out something that builds upon what you just drew. Or offer something that’s a contrasting idea. The meeting then becomes less of a “what’s the answer” face-off, and more of a group journey of achieving shared understanding, with assorted epiphanies visually sparked along the way.