Ghost in the Pixel

Uday Gajendar's musings on interaction design

Aligning value prop & customer goals

An immensely valuable discussion to hold with your key product stakeholders (like the Product, Sales, and Marketing leaders) involves a critical assessment of two essential ingredients of ascertaining your product/market fit: the product “value proposition” and the customer’s goals. Alignment between these two increases the likelihood of achieving a fit that enables business success (hey, there’s no guarantees!) but how to get there? First, ask basic questions among your stakeholders, all together if possible, for full transparency.

a) What is the product’s value prop…and how is that being messaged in the corporate website, as well as in the current application interface? Just jot down a key phrase or two, not some long-winded Dilbertian mission statement full of buzzwords! This is about the product’s purpose, raison d’être if you will. Chances are, various members of the product & company leadership team have varying perspectives…which is fine, as that speaks to a range of potential, but need to find the focus and identify any divergence or contradictions.

b) What are the customer’s goals? Actually, the antecedent assumption to this is identifying who exactly is the targeted customer per utility and revenue. Perhaps there’s a range or a single target—just be clear and fully in agreement. Then, via the devices of user profiles, contextual analyses, and personas, ascertain the aspirations and goals sought from using this product. What lifestyle qualities are enhanced? Which emotions are evoked and sustained? Who else benefits in terms of the “social life of information” extending from the product itself, but the broader ecosystem?

Capturing the responses to these basic yet critical questions will help determine if there’s mutual inter-dependence or crucial conflict in arriving at an appropriate product satisfying customers and driving business value.

No comments

Reactive to proactive designing

In dealing with the perpetual quick-fire nature of a start-up, I’ve begun to develop and apply a useful approach to help manage the swirl of seemingly random chatter and work streams—and when you’re the sole person in charge of UX, it comes in fast! In particular is a mental model for handling the intensely reactive mode of “fix this UI problem” requests per some pre-determined project schedule. Instead of simply indulging in the face-value request of “fixing” a screen for an arbitrary deadline, I’m cultivating a more proactive approach, which hopefully demonstrates “good behavior” for non-designers on the team. There is a series of questions structured in the following manner:

* What appears to be the actual problem? Let’s frame and phrase it not in terms of “I don’t like” but in terms of the issue and consequence. Focus on the (de)merits that negatively impact the user’s task outcomes.

* Who will benefit the most from fixing this problem? The company? A buyer? A user? A middle tier partner or reseller? Let’s be clear about who’s really impacted here.

* What is the impact if this is not fixed? This will help prioritize and get a sanity check. Focus on facts (or reason, at least), not fears! This also shapes a dialogue around perceived needs and goals.

* What is the probability of this problem actually happening to the identified target? Is this really more of an edge case vs a frequent issue? Under what contexts or conditions does this problem occur?

* Is this problem entirely preventable via some other method or approach of changing various controls or options or wizard steps, etc.? This forces deeper look at how this problem is triggered in first place.

* Any other prior issues or precedents within the product related to this? This helps uncover broader thematic issues beyond this problem, expanding the scope of insight and looking a range of considerations, towards a more strategic outlook.

No comments

It’s not about “having the answers”…

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 comments

Going beyond “I like”…

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! 

No comments

First week “start-up insights”

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. 

** Start with the product, to understand the customer and the business: The product is the central tangible embodiment of various aspects of the company like the brand, technology, value prop, founders’ vision and philosophy, etc. As Jony Ive said in a recent TIME magazine interview, you’ve got to deeply understand the product’s purpose and construction to design well for it. And the product is that gateway to the path of understanding the customer (needs & goals) and the business (revenue model, roadmap and strategy). Also, as a device to help mitigate the tremendous “fire hydrant” flow of information, the “Product / Customer / Business” model keeps your focus on what is most important, helping to filter / triage data streams accordingly, so you can preserve your sanity too ;-) 
** The product is a system, so don’t chase Band-Aids: It’s important to realize that any product has multiple parts that coalesce into a “customer experience” that the intended target needs to engage with at various levels. All those pieces simply must come together in a cohesive, coordinated, disciplined, consistent manner particularly if there’s a website, email, desktop app, and other components across platforms and devices. Indeed, the product is a system of elements at the front-end UI level, as well as the back-end data services level. Chasing isolated Band-Aid improvements for immediate releases only perpetuates a vicious cycle of broken UX rife with inconsistency, and doesn’t support a systematic approach of defining a language and patternized model. 
** “Design is code”: This phrase came up the other day over lunch, which I think nicely captures the spirit of the symbiotic relationship between engineers and designers working together. Indeed, a well-formed, good product cannot exist without one or the other—gotta have both! The design informs the code to be delivered to users, and thus their experience and outcome of that. Also this highlights the partnership aspect of being part of a team that respects and values design as integral, not simply a hasty after-thought.
No comments

« Previous PageNext Page »