Archive for the 'General Stuff' Category
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!No comments
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