Recently I’ve been involved in a few rather vague, open-ended conceptual projects at Citrix. Hey, it’s fun stuff for sure and certainly quite challenging. But what I keep coming back to is the structured manner in which I strive to collaborate with my non-design peers presenting this mothball of ambiguity for me to tackle. How do I go about dealing with all that fuzziness, as they unravel, in such a way that it doesn’t become overwhelming and confusing, thus getting lost in the process?
For the last decade I’ve frequently referred to Vogel/Cagan’s “Creating Breakthrough Products” for guidance on tackling what they authors call “the fuzzy front-end” of product development–trying to identify the core market, business value prop, and guiding design principles, to help ascertain a specific direction with certainty. It’s a great starting point and the advice has been valuable in giving backbone to my own assertions and decisions with skeptical devs/PMs at the office.
Lately, however I’ve evolved my own set of questions and approaches for tackling this fuzziness, in conjunction with the project leads from non-design domains. That’s what I’d like to share here briefly :-)
The key thing is what I’ve previously referred to as “3-in-a-box” partnership with the key leads representing UX, Engineering, and Management (or whatever labels may be applied). This is necessary for sustaining ongoing discussions, building rapport/trust, and ensuring efficient impactful communications towards resolution and planning for what’s next, post-ship.
With all the players in the room or studio together, then it’s really a matter of continual deep questioning and discussion with the designer serving as a therapist or facilitator ;-) For instance…
* What’s the premise? Summarize in a nutshell, short pithy phrase what’s your product/service about? Why should someone care at all?
* What’s the problem and/or opportunity at stake? It important to define specifically what is being addressed by what is being proposed. Is it compensating for some existing problem? Or is it anticipating an unmet need, a missed opportunity on the horizon?
These two initial questions are about the “Why“â€¦as Simon Sinek famously extolled, you gotta start with “Why” first, before feature lists and use case inventories. Why would anyone, engineer and customer alike, even care?
Then from there, moving into:
– Who’s the primary user and market target? What’s their composition in terms of skills, experience, goals, fears, anxieties, dislikes, motivators, and worries. Draft out a persona that captures the essence. (maybe multiple personas, as needed) and capture specific “POV statement” (Actor needs X because of Y in order to achieve/fulfill/satisfy Z) which will help anchor and guide design solution iterations and evaluations.
– What are the key assumptions, dependencies, and expectations in terms of the user, devices, software, hardware, contexts, activities, and related elements? Draft these out and draw connections via insightful analysis and real observations in the wild (or on-site interviews). Too often we make unsaid assumptions that color our perceptions of what users truly want. Get all that out in the open! Debate and prioritize and clarify into a tidy list.
– List out the core use cases per market and design research (or at least an initial baseline via personal observations) and use them to literally write out a story/scenario that captures the actor, scenes, objects, actions, responses, and sequencing/frequency clearly.
– Consider the critical moments of device or UI interaction–what are the triggers, affordances, signals, feedbacks, and flows & errors? Illustrate them into “comic book” storyboards with notes about objects & actions accordingly. Call out special attention to potential problems and annoyances.
– Dive deeper into the possible interfaces for those key momentsâ€¦break them out into lots and lots of sketches of possibilities: patterns, layouts, widgets, behaviors. All at high-level sketches, not pixels ;-)
– Reference back to your user/persona profiles and their “POV statement” of what they need to accomplish or support deeper motives/goals given a particular context. This will help ascertain which interface sketches make sense and are deemed “viable” vs “delightful” vs “breakthrough” (as basic criteria for selection)
Using this approach you can at least cut through some of the initial fogginess of a new conceptual project in a structured manner, avoiding lots of vague hand-wavy awkwardness of “what do we do” :-) Also ideally these steps should be reinforced with effective and constant user research based upon direct observation in the filed, as well as surveys, interviews, lab studies, etc. Always be learning and applying those findings to your ongoing design investigations to make forward progress through the conceptual fuzziness.