Goals, not features are the key to product success

First, let’s agree that:

Goals, not features are the key to product success.

The following diagram illustrates the product design process under ideal circumstances.

It starts with goals and desired outcomes

For any given project, initiative or UX engagement there exists goals and desired outcomes. These define what we’re looking to accomplish with our design work — because one does not simply “design.”

I prefer to phrase goals plainly and literally for example;

• “Make it easier to estimate wait times at the DMV,”
• “Support improved skill-assessment”
• “Make pay-by-text as a payment method more discoverable”
• “Educate learners on AI and its capabilities”
• “Make API-related permission configuration more understandable”
• “Provide cross-service visibility on patient care journey”
• “Enable patient meal-ordering”

Goals can be oriented around known problems or strategic business objectives. They can be broad and aspirational, or narrow and extremely specific. I don’t usually argue this, whatever the goals are, I align my work activities and design process accordingly.

I also don’t usually expect stakeholders to be able to articulate goals outright, in my experience people don’t always know how to describe what they want in a way that’s actionable for design and that’s ok. I’m able to infer what the goals are during an honest open conversation.

I can determine design needs by referring to goals

Goals determine what skills (research, UI design, information architecture, strategy) I need to apply to support its desired outcomes.

Some goals are better met with something digital (a web app, a mobile app, a website, etc) or a beautifully crafted visual (an icon, a logo, carefully chosen color or font) others are better served with thoughtful process re-engineering (when and how food is delivered to patient rooms to reduce waste, when and what system state is conveyed to a student using a cloud-hosted coding environment to support continuous learning).

In a SAAS based product context, design work mainly falls into 2 categories:

• An enhancement to an existing system or,
• Development of a new one.

If there are unknows, uncertainties or if the work carries a lot of risk, I do research.

In my experience, it is rare that a project or ux engagement is “kicked off” with all critical information readily available. This is information that covers everything we need to know that would inform design decisions, priorities or strategy.

When this information is missing, and there is a lot of risk to us getting things wrong, (e.g building or delivering the wrong thing the wrong way) I do research.

The type of research I do depends on the needs of the project, but generally:

• I do interviews to learn what people have to say about something and what they think I need to know, what they believe is important. (see mental models)
• I do observation when I’m interested in how people do something; how they perform a task, how they actually follow a process, specific behaviors or workarounds they wouldn’t know to describe verbally.
• I do literature review (also called documentation review, both internal and external) to understand a process or concept that’s (ideally) already well documented.

Once I’ve uncovered what is needed, I’d typically document the knowledge/understanding in an easily accessible format so that it can inform my and others’ decision making. Depending on the nature of the research, it usually helps decide whether a project will be successful, whether it’s worth the business investment, or — should we decide to proceed with it — the critical considerations and implications that should be factored.

For SAAS we write…requirements.

Requirements?! Yes, requirements. Clear and descriptive definition for what needs to enabled — the set of system behaviors, capabilities or functionalities that must be available to support the desired product experience. Here’s an example of how that can look.

There are various ways to format (bullet list in a google doc, digital whiteboard with an infinite canvas, etc), describe (user stories, Jobs to be done – JTBDs, use cases and scenarios) and even classify requirements (functional, non-functional, business, UX, design, etc).

For the most part, I’m mainly interested in getting them written down, plainly, directly and with enough detail to understand why it’s useful, who needs it and how it relates to any other requirements.

Writing them down is a way to formalize them — to make them official. This allows me and anyone I work with to easily review and reference them. Requirements also help us determine scope of work.

Requirements are ideally informed by research, and the research is ideally conducted systematically.

While it is typical to have a Product Manager or business analyst write them, on various occasions, depending on circumstances, I’ll write them myself in collaboration with whomever I’m working with — typically a Product Manager in a SAAS based product context. Sometimes a lead engineer, sometimes another designer.

I also prefer to analyze requirements for completeness and clarity

This is something I prefer to do for complex projects. Especially for highly technical domains (Financial technology, developer tooling, enterprise software etc). It involves critically examining written requirements to determine if they make sense, how they relate, and their dependencies.

In my experience, requirement gathering and definition expertise varies greatly by environment and by individual — Some people are naturally better at it. (see bad requirements)

Then comes concept/solution definition.

More definition?! well…yes and no, let me explain. Solutions relate to problems, and if I have clear (well-defined) problems to solve, then I’ll devise solutions to address them. If instead I have open ended product or business requirements, then I’ll come up with design concepts to meet them.

Without getting too pedantic with the language here, let me state that, to me, a solution can be concept and vice versa.

Design theory is one thing and practice in a business context is another, and I’ve found that most of the time, terms get misused and misappropriated…a lot (affordances vs indicators). Regardless, I strongly believe in “Connect before you correct — if it matters.” (See UX vs UI)

A flow map, a wireframe, a live interactive prototype; I deliver whatever best conveys the concept or solution.

Before COVID (2019), I conveyed design intent by sketching flows and visualizing my thinking on a whiteboard while working through key considerations (both technical and non-technical) with a room of engineers.

Today, I adapt my artifacts (Wireframes, flow maps, prototypes) based on the needs of a project, the cultural environment and stakeholder preferences.

In most cases there’s a review process.

This allows stakeholders to offer feedback and input on the design intent which typically covers desired UI states, system behaviors and functionalities for digital SAAS based product work.

I’ve presented designs to senior executives at some companies for their awareness and approval and have also casually discussed major process changes with peers that were implemented over lunch. From an autocratic bureaucracy to consensus-based decision making, what works varies by environment and company culture.

In some cases there’s concept testing step (or phase)

In some cases I am able to test my concepts with a representative target audience or the intended end-users directly. In my experience though, stakeholders are typically tracking tight release schedules which tends to leave little room to conduct in-depth concept and usability testing. This means, we’re sometimes racing to build based on unverified assumptions. Ask me about this, I’m happy to share a few radical perspectives on this reality and the risks associated with it.

You can find examples of my deliverables throughout my case studies, here’s a few I particularly liked:

Preparing deliverables for handoff and implementation

When I work with developers on digital products, I typically put together detailed specifications and documentation of design intent which covers flows, interactions, edge cases and (where applicable) feedback mechanisms including desired motion/animations.

Here’s an example of how that looks:

…

Monitoring implementation progress and answering clarifying questions as needed

My work continues even after deliverables are formally handed off for code implementation. It involves being present however is most convenient for my product and engineering partners (Slack, Teams, the development team’s weekly standup, 1:1s, etc) to provide clarifying detail and answer pertinent questions as they come up.

This allows me to not only ensure successful design implementation, but to also build relationships with cross-functional stakeholders as well as any individual impacted by my design decision.

I’ve built relationships with team members from various departments and functions including legal & compliance, procurement, analytics, marketing and more by simply being present and making myself the go-to source of all user impacting decision making of a project or product domain I owned.