The Miscellany of Stewart McCoy

#research

“The UX team is constantly interviewing and interacting with our users, so they generate a lot of hypotheses which we investigate using our data. The UX team, because their insight is built quickly from human interactions, can flit from thought to thought and project to project; when they think they’re onto something good, they kick the research idea to the lumbering beast that is the data science team. We can comb through our billions of records of sends, clicks, opens, http requests, user and campaign metadata, purchase data, etc. to quantitatively back or dismiss their new thinking.”

Data Story: John Foreman of MailChimp on the Data Science Behind Emails

Design with trust, ask questions

The most important lesson I learned this past year is that when I don’t understand something, I need to ask questions. I’ve found that overcoming any embarrassment, shame, pride, or ego, and pushing myself to ask seemingly ignorant or naive questions is actually my responsibility as a professional. Having the courage to acknowledge my own lack of understanding and relying on my teammates and other involved subject matter experts has created trust between us and lead to more successful outcomes in my work. I wish I’d learned this lesson early on in high school—I might have done better in algebra.

Learning the importance of asking clarifying questions has helped me develop a general framework for my design process:

  • Determine the design problem
  • Ask clarifying questions of subject matter experts
  • Restate and confirm the design problem
  • Draft and critique a design solution
  • Iterate on the design solution
  • Present the solution to users
  • Iterate
  • Launch
  • Support and iterate

My framework assumes that I’m working in a product environment in which I have design ownership, rather than a consulting environment in which project delivery is the goal.

Day to day, I work with product managers, engineers, marketing and analytics specialists, and regulatory and policy strategists, which all have their own vocabulary and assumptions about our products and services. I often find that our vocabularies and assumptions don’t overlap, so I ask a lot of questions. Doing so has helped me broaden my vocabulary and tease out my co-workers’ and clients’ assumptions.

I’ve also found that when I don’t fully grasp a problem, neither do the people I’m working with; they have their own knowledge gaps, and questioning helps expose what is not fully understood, allowing us to acknowledge and resolve those gaps. Going through this process together often makes design solutions clear to everybody involved, allowing me to document a solution for a design problem that already has the support of major stakeholders.

As a user experience designer, my job is to provide people with a coherent dialogical framework. Because products are relationships, and my top priority with every project is to provide the easiest way possible for clear back-and-forth communication. To do that, I need to fully comprehend the problem, which means synthesizing the knowledge of all the business and technical contributors to the project, and determining the form and content that I think will best resonate with our users. Which is with whom the line of questioning continues, because my design work is always a best guess, and presenting that work to users will further expose assumptions my team could not have known about. It is only by embracing this approach that we can design for those short falls and continue doing our best possible work.

“Too many Product Managers that I know build products how they think others will want them. Therein lies the problem – not putting the necessary effort upfront and determining what problems users are having and which of those you can solve. In fact, I think this problem extends to many entrepreneurs as well. Many build a product how they would like it to be for a specific problem that they are looking to have solved. As Seth so eloquently ended his blog post: “The next time you’re puzzled by the behavior of a colleague or prospect, consider the reason might have nothing to do with the situation and everything to do with who is making the decision and what they bring to it.” Instead of building products that few will use or do not solve a problem, let’s commit to spending the time (and money) to figuring out the problem and then determining the requirements and technology to solve that problem.”

Product Management & Empathy » Jeffrey Vocell