Ghost in the Pixel

One thing I’ve quickly realized while leading design in a dynamic start-up context is that I need to let go of the pressure of being the “answer guy” with the “right” answer to every single question asked or issue raised…Indeed, I was hired for my range of expertise, both tactical execution and strategy insight…and also my ability to facilitate, educate, and evangelize, as someone leading teammates towards some positive outcome or decision-point. Accordingly, my value as a leader is being developed and recognized (implicitly) in a variety of ways already:

* Providing immediate near-term design “fixes” and tangible outputs for delivery to the engineering team (i.e., UI specs and assets) to prove I can deliver gritty details, thus earning trust capital. (Besides, how can you lead the design function for a company if you can’t, you know, actually design?? ;-)

* Directing productive dialogues around the product UX (via an extensive UX Audit, for example) and the customer (via discussions around personas/scenarios) where I’m mostly extracting prior knowledge and back-stories from everyone.

* Raising critical questions about the nature of  design strategy, process, and principles through ongoing discovery about the product functionality—even playing the role of the “naive” student, innocently asking some “why not” questions!

* And lots of plain old active listening! Truly absorb what folks are saying are the high-priority issues and opportunities and then just mull over the responses. Take notes and follow-up with deeper dives or brainstorm sessions, accordingly. Often just being that listening agent provides ample comfort and calming assurance to the team, that “someone” (clearly qualified, of course!) is taking care of this.

I’ve said many times before that a big part of being a designer is simply functioning as a “therapist” of sorts, not always jumping to quick answers, but offering that supportive voice and mindful presence that someone is focused on these tough UX issues—and expressing the captured listenings in some form: sketches, diagrams, stories, etc. I think that’s even more true at a leadership level, where your presence is the signifier that someone is taking command, with facilitative guidance backed by bonafide execution.

No, I’m not complaining about the vapid vanity encouraged by social media sites—while that is a problem worthy of its own post, maybe one day! Instead, I’m referring to the typical refrain heard amongst product teams when debating a proposed design: “I like this…” or “I don’t like this…” Sigh! And how exactly is the designer responsible for the decision (and defending strong criticism) supposed to respond? Of course, with tact and gravitas ;-) But such phrasings place the designer in a tenuous spot of contending with a colleague’s impromptu opinion while arriving at an appropriate, meaningful solution.

When you look closer, “I Like” shifts a user-centered design problem into one of personal preference, becoming a debate of opinions via personality and authority, which isn’t the best battle to wage. Emotions and egos can cloud important concerns around risks and trade-offs, with their consequences for the product (or business) distracted. Instead, I kindly suggest transcending this language…

1) Instead of saying “I” in design discussions, depersonalize by saying “It” or “This” (preferably while pointing at the element :-) This is also useful in explaining abstract principles or other general design statements, like “It helps users to have clear feedback”, not “I want users to have clear feedback.” Again, remove yourself and the implied ego aspect from the discussion, to re-focus the team’s attention on the element and situation at hand—with all their implied merits—not who said what.

(Corollary: Try to avoid saying “For me” or “myself” too. More useful to refer by name to any pre-defined personas or actual users, to frame issues via their perspective.)

2) Ban the word “Like” in design discussions. Period. “Like” is simply not a design word, but one of personal preference suitable for food or movies. Instead, encourage teammates to say “In this case, the icon might work because” or “The icon doesn’t seem to work because”. Notice the main word here: WORK. The idea is to shift the discussion towards the functional nature of the design elements, or the “job to be done” by the color, font, layout, icon, transition, etc. rather than any personal preference. 

And if someone still says “Like”, then force the necessary “Why” question to ascertain the rationale from that person, thus inviting a reasoned, objective debate, rather than a personality battle. 

** Note: When it comes to visual design style—always a lightning rod for personal opinion–there is a functional nature as well, in support of brand principles. As in, “Does this style enhance or detract our company’s brand image and the message our product is trying to communicate?”. And always remember, product managers and engineers are not art directors! 

After successfully wrapping up my first week at a software start-up, I wanted to briefly reflect and share some insights gained while diving into the fire and making some progress as a new designer on this small but passionate team. 

In a recent interview with TIME magazine, Apple’s legendary head of design Jony Ive was quoted as saying this, when it comes to designing a new product: 

Objects and their manufacture are inseparable. You understand a product if you understand how it’s made. I want to know what things are for, how they work, what they can or should be made of, before I even begin to think what they should look like.

Exactly. This statement wholly captures my design attitude as I insert myself into a start-up context as the main, and—for now—solo designer. For me to be a successful designer impacting the product (a web-based SaaS application for IT Admins) in a significant way, I can’t simply jump to visual styles to beautify—as tempting as it may be! I’ve got to fundamentally understand the product purpose (why it exists and for whom it provides value), the product mechanics (how it all works, as a Big Data analytics tool for IT Datacenters) which means diving into some fairly demanding technical concepts around datacenter operations, and the product manufacture—indeed, how it all gets coded up! What is the actual code construction process in terms of tools used and frameworks applied, for the front-end (like angular.js or CSS3) and back-end (leveraging AWS servers). The more complete my understanding of the product, then the more effective and influential I can be as a designer shaping a bonafide experience that respects the product’s essence. And then…I can amplify the product to the next level via beautiful and rigorous design. Designing a software experience implies knowing how it’s constructed, to have maximum impact.

As I prepare for my new UX Director role with the big data analytics start-up Cloud Physics, there is a range of categories of knowledge I’ve been rapidly absorbing (i.e., cramming ;-) so I can hit the ground… umm, sprinting, as it is!

Below is is a brief summary of what I’ve been refreshing myself on over the past several days:

** Customer-oriented metrics: Being a data-driven start-up, I need to gain maximum understanding of key concepts around customer engagement, adoption, retention and satisfaction (Google’s HEART framework with GSM, in particular), including NPS and other useful metrics for driving not just design decisions but also supporting business goals. Keying up for A/B testing is a necessary part of this, irrespective of my own personal disliking ;-) 

** Business model canvas: Oosterwalder and team have created the ultimate tool for applying designerly approaches to shaping a business. The critical elements that comprise that business and how they interact with each other—that’s something to constantly keep in my mind as we evolve the business and product offerings this year.

** Visual production & UI prototyping tools: There is simply no way around this, I’ve got to roll-up my sleeves and dive heartily into design production, at least initially, before my team is formed. Gotta deliver immediate results to help establish credibility and value, right? And there is no shortage of tools, particularly non-Adobe tools that are free or inexpensive ;-) Being cost-efficient while “satisficing” is a virtue in a start-up context.

** Lean & Agile processes: These methodologies and philosophies have become a simple fact of life for any start-up today, so I’ve got to understand the pitfalls and opportunities inherent to them, as well as anticipate ways to creatively blend them with design-led processes. 

** Big Data concepts: Well, of course! After spending four years dabbling in cloud and virtualization tech, along with multi-touch mobile UX, it’s now time to shift gears, and dive into the concepts and terms that constitute “big data”, beyond buzzwords. How do velocity, variety, volume, and veracity (the Four Vs) impact the data’s expression and interaction within an interface? Hmm!

Finally, I am casually revisiting various favorite design books that have become my “Go to” resource stack, including Microinteractions, Envisioning Information, Designing Visual Interfaces, and so forth…to help with priming the mind for design leadership!