Keep asking the "basic" user experience questions

Over the last few months, we’ve been focusing a lot of our work on ensuring we’re telling end to end stories. These end to end stories focus on a specific outcome that a specific persona, or set of personas, want to achieve.

In a big company, specifically, end to end stories are essential to drive an understanding of the user story beyond the mockups. End to end stories drive the scenario by which the north star is defined. As we spent more time focusing on these end to end stories, we started learning more about the necessary questions designers needed to focus on and keep asking. A part of our effort also included end to end story reviews that I conduct regularly alongside our design leadership team. I’ll write more in the future about what the process looks like in the near future.

A core element to that process, however, has been pretty simple. In every end to end story, we expect a product designer to come prepared with the answers to a set of very simple questions:

1. Who is the persona or set of personas we’re building this for?
2. What are they trying to achieve?
3. What are their current pain points and goals?
4. How do they solve this problem today?
5. How are they going to solve this problem moving forward?
6. What value does this provide to them?
7. How does this fit within the context of the VMware market story.

These seem like simple questions oriented around the value of what we’re about to ship. They are.

Here’s the reality though, these are some of the hardest questions to answer, especially in a sentence or two. These are the type of questions that you can only answer when you have the clarity of vision and user research needed to actually execute.

Also, these are the questions that sometimes change as execution moves forward without anybody noticing. If you've ever worked on a project where the user value was something at the beginning of the project and ended up being something else at the end when it was delivered, you know what I am talking about.

Most designers come to these reviews prepared. However, as we start discussing deeper and ask questions behind the questions, many start realizing where their gaps in knowledge rely.

With a fast-paced environment and a lot of focus on the end result (most of the time, the mockup), teams spend less time getting very familiar with the business, the product, and the actual user value provided within the context of the market solutions available. In these reviews, we also include PMs and engineering architects working on these stories. The goal is to ensure the answer to these questions is common across everyone on the team. The goal is to ensure everybody is working from the same script. We really write it like a script.

So far, this has been one of the most effective and easiest ways to ensure teams are on the same page within the context of the user with a clear understanding of the business and product.

In fact, most designers who‘ve been through a review (and these reviews get deeper and more interesting as we go through the project) leave with a clearer understanding of their own project, a clear understanding of similar stories that we’ve seen across the organization that they need to look at, and with a clearer understanding of next steps. They also leave with a clearer understanding of the VMware business objectives and how their own story links up to them. The discussion around these questions is as valuable as answering them.

Ask the “basic questions”, keep asking them, write them down, ensure you’re on the same page with your cross-functional partners, and then keep iterating. Many times, you assume you’re on the same page and things sound similar that you think they’re the same. Don’t fall for it.