Ghost in the Pixel

For just over 4+ years I had arguably what some may consider to be the “dream job” in software design: serving in a largely self-defined Principal level role for a revolutionary team ushering “Design Thinking” into a 25 year old enterprise technology firm, Citrix—with 100% executive support from our CEO and SVP of Customer Experience. I worked on initiatives that combined my talent and energy: Driving visionary concepts, leading design evangelism, delivering innovation with the Citrix Labs team, coaching startups at the Startup Accelerator, and running a successful design speakers’ series, plus countless other activities that were fun, rewarding, and impactful. In a rare situation where I helped shaped design vision and culture—with executive visibility and trust— I also learned a great deal about what it means to foster a corporate design team’s success (witnessing its rapid growth to over 120 people!), and what it means to be a design leader (not for the faint of heart!)…with all the inherent challenges, frustrations, and anxieties ;-) It has been an amazing journey.

And in the end, I did everything I sought out to do…and more, with opportunities I never imagined possible. I can say with sincere gratitude and profound awe: “Mission Accomplished”.

So, what’s next? How does one transcend such a uniquely compelling situation? What comes after the “dream job”? 

Now, it’s time to disrupt. In tech circles, this is has become a trite buzzword implying some game-changing invention that radically alters convention (usually along with some wild-eyed multi-billion dollar valuation ;-) However, for a designer— a fundamentally creative individual, who constantly evolves, seeks stimulus for personal and professional growth— once awhile you need to pursue that risky, uncommon opportunity, a catalytic event to shift your whole perspective and approach, taking things to the next level. To learn something completely different and push your own limits. Sometimes, you just need to disrupt yourself. 

And what better way to do that than by joining an exciting 20+ person start-up called Cloud Physics, as their Director of UX, charged with bringing beauty & soul to “Big Data” analytics? :-) While I’ve been in Silicon Valley for 12+ years, to the surprise of many I’ve actually never worked at a start-up before (ironically, perhaps). So let’s take a leap—into a wholly new role, company, and environment with a compelling focus and critical impact upon design strategy & vision. There is no textbook or class syllabus for something like this—improvisation will be key! I’ll be taking a different approach from “big corporate” Customer Experience, emphasizing a Lean, Navy SEAL, craftsperson approach to delivering design excellence. I might even learn to code, just a little bit ;-) It’s both exciting and daunting, with plenty of worthy challenges ahead. I look forward to sharing lessons and insights from “start-up land” in the coming weeks. Stay tuned!

Inherent to the design process, “the user” is regarded as the prime source of necessary, valuable, actionable information for making sensible design decisions, captured in a variety of forms, from A/B tests to in-context interviews. However, we should be careful in assuming that users have all the answers or, to put it bluntly, know what’s best. Before we appoint “the user” to the holy pedestal of infallibility, it’s worth remembering the following:

* Users (i.e., humans ;-) are contradictory, messy, emotional beings with hidden motives and desires, and often have difficulty articulating them accurately. They may have an instinctive sense for something being “not quite right” or “just spot on”, but often have a very hard time expressing it in a way that product decision-makers can act on it effectively. This includes the lack of proper language to convey it well (“Make the button red and flashing” is usually code for “this button is very important”, not actually put burning flames on it.)

* Users usually only know their current situation—thus, can helpfully itemize all the perceived problems from their POV. However, they may not have a sense for how to improve things in a significantly useful or novel way. that “connects the dots”.  This requires stepping outside of themselves to spot opportunities they might be blind to.

* Users are quite good at local tweaking, optimization of their specific tasks against known or perceived problems, of some tangible factor. But not necessarily global, architectural, flow-level issues of coherence, integration, aggregation, of the entire ecosystem, since many rarely experience or see the total system. 

* Users aren’t empowered to make tradeoffs and compromises impacting the final product or service delivery—which might effect other users beyond themselves! The product team has that responsibility. Users don’t need to know all the inside baseball that goes on, of course, but designers do and that necessarily impacts what’s possible, viable, feasible just as much as what the user needs.

Ultimately, users are not designers. I know it’s obvious, but it’s true and often has to be stated. That’s why well-trained and educated designers are hired, for their ability to interpret and transfer user-oriented findings into strategic and tactical, well-considered, decisions around affordances, semantics, task flow, visual style, and functional value. Users are essential to that process but not sole bearer of all the answers, for a good reason!

While throwing a prototype on the table with little to no preamble to solicit feedback might make for a thoroughly fascinating observational study and examination of human reaction (loaded with critical cultural theory, no doubt), it’s actually not very helpful for the designer trying to ascertain clarity about which direction to pursue. The fact is everyone approaches something with some background knowledge and expectations shaped by culture, language, metaphors, prior experience and learned skills. What is that basis? That’s the real trick and challenge of designing for your intended market, to make your product seem “intuitive”, which is to say, mapping to inherent and acquired patterns of use. I realize this might rankle veteran researchers in the field, but here’s what I’ve learned and realized about prototype testing:

A user feedback session is really a mediated dialogue. We’ve all heard the refrain, “we’re not testing you, we’re testing the product.” That’s actually bullshit. You’re totally testing the user to see if they are grasping the presented concepts. Instead, we should be saying, “We want to learn from you if this concept is successful, and if not, how we can best improve it. Let’s have a dialogue, using this prototype.” 

Prompt their “think aloud” approach with why and what if. Yes, let them struggle but also help them be successful. Probe with specifics without the anxiety or fear of “giving it all away”. I understand the fear of introducing bias, but honestly…get over it! The fact is in the real-world a user approaches a product already having been biased by the advertising, branding, social marketing, contextual framing that’s latently happening all around. Attitudes and impressions have been or are being formed already—so deal with it! :-)

You need to frame up the scene and addressed problems or foreseeable opportunities. Having the user assume a particular role and use case helps greatly. Is this an app to be used while commuting from home to work on trains and subways, or in the privacy of your own car? Suggest issues that might arise, like loss of wireless network, or limited data plans, or forgotten charger. How would the user react to these moments, in light of the app or device being designed for? You need to prompt such considerations to enable that mediated dialogue.

I realize this flies in the face of most research protocols but you really need to coach and guide a user through what it is their interacting with. You can’t simply throw down a paper prototype of a phone app UI without telling them, it’s a Phone App UI and expect effectively applicable inputs. Even basic framing of what it is, the context and device, is essential. Else you will waste the user’s (and designer’s) time with puzzling poking around, which isn’t helpful information to make a decision that will move the product forward.

 

 

This is a personal “working theory”, arising from various situations with virtual and local teams over the past few years, around the notion of “collaboration”…

While collaboration is heavily championed as vital for team and company success, I really see it as just ONE part of a dynamic continuum of team-based social interactions of varying degrees, each with their own benefits for different contexts or purposes. And I’d suggest there’s something more valuable than “collaboration”—it’s something called “partnership”, whereby a solidly mutual, integrative relationship of interdependent success / failure is deeply seeded in the values, attitudes, statements, and actions of the partners. Everyone is in it together, hell or high water, so to speak :-) Committed to the end, period.

If you think about it, there’s a continuum of design relationships that emerges over time with peer teams (engineering, marketing, etc.). The success factors that define that relationship include (among other things) — shared goals, level of trust, types of engagement, contextual factors such as virtual vs on-site, critical dependencies (tasks vs knowledge), and even financial incentives. These factors determine whether your team is enjoying basic coordination, cooperation towards a purpose, collaboration on outcomes, or partnership for lasting value. Let’s take a closer look…

Coordination: This implies a time-based choreography of isolated activities, to ensure dependencies are satisfied and the “critical path” of meeting a deadline is secured. Truly, the basics of project management, representing the lowest bar of team capability to work together.  

Cooperation: This suggests another basic level of team engagement, with minimal viable trust and respect to ensure accountable accurate delivery of artifacts for similarly valued goals.This involves at minimum information sharing & access, leveraging files/content across sources, and fostering feedback and inputs from other people in a respectful, beneficial manner.  

Collaboration: Ah, the golden sweet spot per mass business literature ;-)  This is where everyone is working together in real-time, real-space (virtual/physical), co-location/co-temporal, sharing, discussing, interacting, fully present and committed to the project goals for mutual success. There is indeed a shared bond of “co-creation” and supporting each other with healthy team dynamics, with good conflict and positive argument, whereby team learning and growing transpires.

Partnership: This is the “advanced” level, truly involving a long-term, strategic, values-driven shared mutually dependent understanding of collective success and risk-taking. Decision-making is fully transparent and informed with full recognition of every members’ due value. Co-creation, co-planning, co-interpretation of results for strategizing the next round…this is what it means to be partners, with maximum investment of time and energy for mutually assured sustainable success. 

There is one more thing…Camaraderie maybe that invisible glue (aka “secret sauce”) required for a certain degree of hospitable engagement. Not being “friends” per se, but more about enjoying the presence of others, taking energy from it, giving it back in a virtuous cycle of building a professional, beneficial rapport, with constructive inputs/supportive outputs, Of course, mutual trust and respect are big parts of this, latent concepts made apparent in the actions and results of people involved in the team, bounded by the constraints of time/money/tools/requirements, which shape the relationship, as much as the product development results themselves.

Now, I realize this all might seem like semantic hair-splitting to some. I believe that having nuanced degrees of understanding can help suss out any underlying issues adversely impacting a team’s dynamic. It’s all about clarity—what stage of relationship are you really having and is everyone aware and in agreement about it? Otherwise, a host of unstated assumptions and expectations silently churn in everyone’s minds, leading to unnecessary friction and eventual blow-ups. 

Finally, just a small caveat… This continuum framework implies that partnership is the highest level to achieve, but it not be ideal for every situation! After all, the pragmatics of building relationships does involve varying & limited resources of people, time, and energy. Not everything can, nor should be, a beautiful wondrous partnership. The more transient and ephemeral the results, the more it leans towards basic coordination and cooperation. The more legacy level impact of broad impact, deeply affecting goals and values of a process, team, or culture…even the attitudes of an entire market or customer base, then the more a partnership is sought. It comes back to what’s the level of impact and value, and is it receiving the appropriate level of engagement from the team members involved? Hopefully this working theory offers a structure and language to think through such an important question.