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.No comments
Is it a product, an experiment, or a demo? Let me explain with a brief anecdote…
Recently a routine project status meeting (snoozer, right?) rapidly escalated into a contentious spat, with accusations flying about “lack of support” and “not valuing the results”. Whoa! Stepping back from the unexpectedly flared tempers I asked the Dev and PM leads a simple question: “So what exactly are we building here?” Because it had become sorely apparent there was a crucial, unstated misunderstanding which had led to this moment of tension. Ascertaining what exactly we’re building (and thus, for which purpose) would clarify practical concerns and prepare the team for what needs to be done next. Unfortunately, this project had been running along on so many parallel tracks with missed chances for clear communications, due to false assumptions all along. Whew.
But I digress. So, what exactly were we building? And what are the implications for each option? Seems there were three basic paths overlapping yet at odds with each other:
a) A product: This implies building a fully-formed, self-sufficient entity with proper data, networking, API hooks all set up for actual usage by a particular customer for achieving certain tasks. There’s a resolved & integrated sense of brand, features, utility, and style that feels complete and ready for public release. The goal here is delivering a wholly formed object or service of tangible value for business gain, and customer satisfaction!
b) An experiment: Following popular “start-up” and “lean” thinking, this implies creating something that is narrowly scoped, based upon an hypothesis, to help achieve proper product-market fit downstream. The goal here is minimizing risk, maximizing learning, and doing so with efficiency. The audience is limited, with clear expectations set about what to expect. Usually it’s a rough prototype of limited capability, with parts not functioning or simply hinting at future utility, as prompts for user feedback. And the expectation here is that it could all totally fail, as any experiment!
c) A demo: The reality for enterprise software is that there is a structured sales pipeline and customer engagement practice including wooing market analysts and vendors via exclusive previews or demos of what’s next. And yes…sometimes you have to design for the demo, to tell a certain kind of story that addressees marketing or sales goals. Demos can be simply “smoke and mirrors” or more robustly defined, but regardless, are tuned for a highly calibrated messaging purpose to stoke customer interest (although not necessarily feedback).
It should be apparent that each path involves a different approach to resourcing and leveraging the design process accordingly. A product is a full-blown, complex, multi-party coordinated effort with critical dependencies spanning divisions. You need a fully coordinated design team effort, from concept to delivery, with every potential bug closed or gap sealed. An experiment is far more scoped down and thus forgiving with direct impacts on specific engineering and design needs—in the words of Herb Simon, “do what’s necessary yet sufficient” to be expedient. And a demo is a wholly different affair, with closer coordination with marketing and sales strategy members, that can be a tightly limited, even isolated, exercise, with zero impact on real engineering. The application and distribution of resources can vary, and it’s important to note the differences, as they impact the use of designers & researchers too.
(You could certainly serve multiple purposes, but it’s sensible to have a main target to strive towards, to keep everyone focused. Anything incidentally supported becomes a secondary benefit, that’s welcomed but not a distraction. That expectation must be firmly conveyed!)
Getting back to my situation, those accusations of “lack of support” or “lack of interest” in the results, well…they were suitably corrected by clarifying what we need to support for, and what kind of results we’re all expecting to strive for. While a sparkling demo is important to impress future customers, a diligently fleshed out product for customer usage is arguably more valuable with significant efforts needed to enable market success. Understanding this difference can help a team ascertain their true goal and set proper expectations, across the board for everyone.No comments
No doubt 2013 worked out to be another incredible year of inspiring conversations, insightful engagements, and cool opportunities! For that I’m extremely grateful to my friends & colleagues at work and within the broader UX/Design community. It is only through such relationships I’ve actually made it this far :-)
So, I want to briefly highlight my top personal accomplishments and valuable lessons learned for 2013, to hopefully serve as inspiration for others.
What did I do this year? A few items of note:
* Participated with top execs at annual Citrix Think Tank, to deliver a beautiful next-gen concept for a intelligent, contextual “agent” that enables work-life balance, cheekily codenamed “Gini” (combo of Siri + Google Now ;-)
* Delivered innovation with Citrix Labs on multiple fronts (and with multiple trips to Sydney ;-) including a concept for multi-device, multi-touch communication codenamed “Crystal Palace”, resulting in some patent filings too! True design + tech collaboration via Lean UX model of experimentation and customer feedback, in a big way.
* Continued partnerships in design education, via General Assembly (lectures and hosted studio tours) & CCA’s DMBA Design Strategy programs. This fall I helped lead Citrix’s sponsorship of Nathan Shedroff’s Experience Design studio, with some inspiring results! Great stuff.
* Got involved with startups! This was a big year for me, via Citrix Startup Accelerator (running design sessions, scorecard reviews, office hours), Kleiner Perkins Design Council, and others too. Fascinating world of design opportunity!
* Mentored interns – yay :-) It’s always an honor–and a pure delight–to support our annual Citrix Design internship program via mentoring and networking events. Met some truly wonderful, emerging design stars!
<< Big thanks to my peers & leaders at Citrix for enabling such great stuff this year! Truly a team effort. >>
So, what did I learn from all that (and more)? Just a few things:
* Be adaptive to unexpected change–it’s essential: This is particularly true with constant organizational changes, departures, team evolutions, role changes, etc. It’s never personal but purely transactional, business-driven motive, what’s best for the Company. This can be hard to understand when emotional attachments to projects and teams form; just remember there’s an underlying strategy and being adaptive keeps you flexible– and optimistic! Plus, new opportunities almost always appear when you least expect it, from such changes. Which leads to…
* Be selfish–for your career: When great opportunities present themselves, go grab them! Don’t feel guilty about it. Sounds cut throat, but it’s not–it’s simply business! Nobody cares more about your career than you. And if you’re that fire-starter, provocative type of designer (umm, ahem, like me ;-) you kinda have to promote yourself through self-directed actions and relationships, so take advantage accordingly. However, always remember to…
* Be generous–for your team: The flip side is being truly generous with the opportunities you partake, sharing all benefits/results/takeaways with your teams, both peers and superiors alike! The karmic cycle of virtuous giving prevails, always. Pay it forward! This suggests a symbiotic relationship with your peers & superiors, for a productive healthy dynamic at work.
* Everything is political–gotta learn “quiet influence”: It’s simply human nature! This is true at the highest levels of leadership, where egos, domains, structures, and roles clash… along with typical conflicts over resources. Not fun! However, the ability to subtly detect various weak & strong political ties (see Dave Gray’s “The Connected Company”) with influence patterns is vital, while persuasively (and persistently) pushing the “quiet influence” of your ideas. Not easy at all. But through confidence, conviction, and respectful “crucial conversations” you can thrive.
* Scaling is really hard–it’s OK to ask for help!: Scaling from a team of 10 to a team of 175+ worldwide creates a variety of challenges (with 200+ “catalysts” too), including how to share/communicate/learn and keep everyone inspired with new ideas. I’ve learned to focus on local areas of impact, support small activities (weekly sharing sessions and such) and how to delegate, grooming others to be your rep in other Geos (“site primes”).
* Virtual teams are great, but innovation needs presence: Having worked on a long-term innovation project with a team based in Sydney, I’ve got firsthand experience with this :-) Every trip to Sydney proved to be a catalytic event, accelerating understanding, creating novel ideas, and overcoming engineering issues. There’s something about “being there” that can’t be replicated (yet) with today’s comm tools. Design matters, but presence really matters a lot, to get designs delivered.