I recently talked to my friend and mentor about a problem I previously had about misalignment on requirements which you can read the whole story here. Essentially the problem was that I had been going back and forth on making changes to my designs because there had been miscommunication on what we needed to have in the product before launching it. I have solved the issue by explaining this situation to my teammates and consolidating meetings, but when I explained the situation to my mentor, a question he asked me was:
What does success mean to you?
I had an idea about what success meant at the moment, so I said, albeit seemingly unsure as I started with lots of “I think” statements (note to self: you know what you are doing), was success means finishing mocks and getting feedback that I was going in the right direction. My mentor explained that this kind of success isn’t the kind of success designers should be thinking about. The kind of success we need to be thinking about is how it can support business and user objectives and it’s something which can be measured.
Success could mean something like time on task and adoption. For my product, success could mean integration and efficiency. Integration from the business perspective of gaining more partners, user perspective of streamlining existing processes of doing a task. For efficiency, from the business perspective, this can mean gaining more users based on ease of use and from the user perspective, this means less friction and less time to achieve tasks. As you can see, the way a designer views success should align with what the team believes to be success, which is based on metrics and impact of how it is perceived and used by the world, not just delivering pretty design artifacts.
Based on what I learned, defining success is crucial to the success of a product and how a team works.
Teams need to be aligned on success or there is else lots of churn or no thinking around meeting core objectives.
A team needs success metrics or else metrics affect your day to day work. Without metrics, there is lots of churn and not thinking about meeting core objectives. Also without a core objective, the small tasks wouldn’t matter because the metrics that would achieve a core objective wouldn’t be existent.
There are two types of metrics to determine success: short term and long term metrics, and a vision statement to ensure everyone is on the same page with what success means as a team.
Vision Statement: The core goal of your product and how it helps users accomplish their goals (Creating new ways to enable communication for everyone)
Short-Term Metric: Make very clear towards vision (efficiency during onboarding, completion of task).
Long-Term Metric: What could this directly affect? (i.e. Development tools from (name of product) will help 20% of partners onboard and create (outcome) in the beginning 2019 (aka adoption), Serve NBU customers in three countries on x).
If we are talking about short term and long term metrics in the form of OKRs, short term metrics are typically a P0 or P1 task. long term metrics are most likely not achievable in one quarter so they are P3 or P4 tasks. P meaning priority and the numerical value representing importance and what is achievable now.
Design is supposed to support an objective based on customer and business goals.
It can be so easy to get wrapped around the concept of shipping features in a big company that you forget to think about what a design is supposed to achieve.
Objectives (success metrics) and outcomes > Features
This is something that had been happening to me. My mind had been so preoccupied with requirements and doing something because it was a requirement, that I hadn’t thought about how it contributed to the user experience of the product and how it aligned with the existing success metrics of the product. It doesn’t matter about the amount or power of features you add to a product. If they don’t contribute to helping the user meet their goals, it’s essentially useless.
Ask questions around how a process can help us get to our outcome
Success isn’t designing mocks, it’s about designing solutions that meet the needs of our users and satisfy the business’s bottom line. Designers can enable the process that allows others to understand what those things are and use mocks as a way to visually convey objectives.
When having meetings, we have the ability to guide these conversations toward user objectives and understand the kind of metrics we are using to gather data that would determine the product’s success. These conversations should be framed around what what does a button enable the user to do instead of where should we put the button or what color should this button be. It is our job to decide placement and visuals while the goal of a feature that achieves a success objective is something everyone needs to decide on.
Source: uxplanet.org
Author: Tiffany Eaton
