How I work

Overview

I work in a omni-dirctional Macro | Medium | Micro methodology similar to the Double Diamond model, taking in data, working from broad strokes to more focused and detailed artifacts, testing and iterating. However, I find there’s no one-size-fits-all solution for process, as features may range in scope from minutes-to-solve to months-to-solve. That variance requires flexibility.

As context grows, the needs of the feature may change and with it, what I build. I may jump from honing a critical moment in a user journey, to making a key interaction feel amazing, to prototyping the whole flow, to re-examining the merit of goals and KPIs as the need may require.

What I or my team make depends on the state of the problem set. There is, however one key question that informs this: What will most effectively bring us closer to completing the feature successfully?

My process loosely follows this sequence:

💛 Guiding Principals
- Building features
- Uplifting teams
🔭 Assessing scale & scope
- Aligning success/fail conditions
- Identify the time-frame, team composition, and resources
- Assess the value proposition of the feature within the release
✒️ Introspection & artifacting
- Build early artifacts to come to shared understanding
- Get the team to think critically about the problem space
📊 Data collection & analysis
- Assess appeal with internal team
- Examine the discourse on social media
- Collect and analyze qualitative and quantitative data
🪴 Collaborative synthesis
- Leverage the team’s collective insights work-shopping
- Delegate chunks to team members
- Define IA, Flow, and other more macro artifacts
📱 Wireframing, Prototyping, Visual Design, & Re-framing
- Flesh out various parts in greater detail
🧪 Testing and iteration
- Get the product in peoples hands
- Capture and triage feedback
➰ Jump to any other step as needed

Guiding Principals

I prefer to explore & express (driven by principals), over following or upholding a strict process. Indeed process, design systems, and structure all fill critical functions as servants of the end product, bringing consistency and reliability to users and the team. But not the other way of around; upholding a process or system without nuance will erode end quality for the user and product; It doesn’t matter how elegant a system is, the end product must function in the user’s hands.

Here are some of the principals which I employ to guide my work and that of my team when I’m in a position of leadership. They have been informed by years of working with teams large and small, lots of books on UX & product design, many successes and failures over the years. They have helped me to grow leaders from ICs, ship incredible products, and maintain team morale through challenging times.

Assessing Logistical Details

What does shape of the problem look like?

Before I dive into the creative parts of the work I like to familiarize myself and the team with the practical constraints. Questions about time, resources, and any relevant history or interested stakeholders are essential to answer at this point.

🤷‍♂️ Why are we doing this?
- What problems are we hoping to solve
- Is this intended driving engagement, revenue, retention, attachment, conversion
- Where does this fit in the broader product strategy or company-wide roadmap?
- What are our KPIs, success fail criteria?
✅ What’s been done so far?
- Do we have rituals, group chats, checkpoints setup?
- Has this formally been kicked off yet?
⌚ How much time do we have?
- Is this feature or product needed tomorrow or in 6 months?
- What does our sprint cadence look like?
👨🏿‍💻 How many people?
- Is it my team that I’ve been working with for years?
- Do I need to drive teams I haven’t worked with before?
- What kind of UR, Analytics, Production, PM, support can I expect
- What can I delegate?

👴🏼 What’s the history?
- Have we attempted this or something similar before?
- What was the outcome?
- If it failed to bear fruit, why?
🚗 What’s the roadmap look like?
- What other teams might be involved?
- Whom else do we need to coordinate with?
- What tech are we using, do we require new tech?
- What other features are being build along side or may be more critical than this?
- What’s the level of confidence in this?
- What’s the target quality we need to hit?
👩 Who’s driving, stakeholders?
- For which parts am I or my team responsible?
- We do we need which artifacts by?
- What kind of support do they need from my team or me?
- What’s the approval and communication chain look like?

Introspection & artifacting

I like to make stuff early and often…

Once I understand the shape of the the problem I like to start making things. An artifact, a crude prototype, or a prose that tells a story from a specific point of view, can provide immense initial value and shared understanding. I’ll often begin with writing from the perspective of a few base “human condition” cohorts.

👶 An oblivious new user
🤨 A cynical lapsed user
🧓 An engaged old timer

Apart from fulfilling stated business objectives, there are a number of sentiment issues which are critical even at this early phase and without knowing the target demographics. A strong empathetic approach can telegraph many user needs before they’re captured in data. We just have to think sequentially and keep track what our user knows and when.

Authentic personas

If I’m starting with prose, It’s critical to avoid painting a naive picture of the user. Authenticity and brutal honesty about user behavior is key. I’m talking Jonathan-Franzen-authentic, with depth and flaws. The assumption of an understanding, malleable user is all too prevalent in case studies I read. “John” will delightedly click through popups and reflect mindfully on the need to generate add revenue for the product as they sit through an ad for an AI slop game. These “stock photo” personas should have no place in your prose. Unchecked, they will kill the product for its lack of insight and relatability.

Real users may be busy, or burnt out. They will likely range from oblivious and quick to atrit to jaded, sophisticated, vocal critics of software products. They may carry an innate distaste for the product simply due to the the company that makes it, or deeply held cynical worldviews along with financial struggles, health problems, or mental health issues. This isn’t so much about accessibility at this point, rather examining a genuine portrait of the human condition.

I push myself and my colleagues to accept that, and build personas and artifacts that are authentic.

Product Vs human relationships

Like any relationship, a product must be an inherent fit for the user. If it isn’t, it must win them over. This requires overcoming inherent biases. These biases can range from skepticism, to doubt, to mistrust for the the platform or genre or our organization. Once the basic framework for a relationship is met, it must continue to present itself favorably.

Consider you have two friends, both are equally funny and fun. But one is a flake or brings the annoying third wheel every time you hang out. How is it spending time with them compared to the reliable friend who’s there when you need them and attentive to you?

Tho fictional, the character arc between Luke and R2 in A New Hope is hopefully a relatable example. Luke needed droids to fill specific needs. C3P0 was able to talk to moisture farming machines, R2 could repair stuff. To Luke, they were tools. If they failed in their basic function, trust would have been destroyed, and the relationship would have taken a different turn.

Over time and many cycles of use, Luke came to appreciate them and the relationship changed. They offered enough of what he needed or desired for him to overlook their shortcomings. I look for ways for software products to behave similarly.

Identifying the user’s inherent need is so critical from this product perspective. If there is no genuine need, we don’t need the service. The authenticity of our personas will dictate the authenticity of the need.

Respecting Boundaries

Once we favorably attract the user’s attention, we have to keep interactions positive. Below are a few questions that I keep in mind when attempting to form and maintain this relationship.

While it is possible and often necessary to condition an emotional response or a desired behavior in the user (i.e. “getting them to eat their vegetables”), it’s much faster if we can hot-wire their brain with some applied Social Learning Theory. Some of the questions I’m asking as I write a prose may include the following:

Does it respect the user boundaries of time or attention?
Is it in their face and shrill or is it chill and accommodating?
Does it express their aesthetic and personal values?
Are they able to envision the value naturally?
Does it reflect something that users frequently request?
Is the user’s privacy and comfort respected?
Will it become familiar and comfortable to use? How long?
Does it need to feel novel and exciting or should it be invisible?

Other Artifacts

At this early phase I’m not necessarily trying to fully model the user or the experience, which will later be informed by data. Depending on the problem, however, I may start building any number of artifacts that illustrate the problem in some illuminating way, providing a unique perspective. I continually am making these artifacts as I attempt to understand and bring the group into greater understanding.

User Stories
& Anti Stories

Swim lanes
& User journeys

Behavior
requisite chains

Multi-Cohort
Temporal Heat map

Sub-feature weighted
Radar Graphs

data collection & analysis

Taking data in from all sources

From social media, to internal UR, to formal user segmentation studies and modeled cohorts, I like to look at all the data. Each source may serve a roll in my analysis depending on the scope of the problem. Each source of data may provide something unique, valuable, or timely. If we handle that data with respect it can prove invaluable. the challenge is that we often need to start solving a problem without having full context. To address this, I collect and review data in three-ish waves.

💬 Social Media & Content
🎮 Internal UR & Playtests
🧪 External UR & Analytics

A. Social media & Content: the canary in the mine

Reddit, X, TikTok, Instagram, Threads, etc. paint a preview the product impact KPIs in 6 months to a year. If player sentiment is toxic, it bodes poorly for product performance. I like to look at “why.” What are users complaining
Typically social media and Net Promoter Scores (NPS) are near echoes of one another, with internal NPS studies trailing behind about a month or two. I’m sure there are PMs who can school me on this. But it’s an anecdotal observation. regardless of the accuracy, I find it’s a pretty good idea to listen to how players say they feel.
In games, players tend to be a hyper-sophisticated consumer group. They understand design intent, see through attempts to obfuscate engagement, business, and monetization goals, and they provide well-reasoned (tho often economically unfeasible) suggestions to known design problems.
There’s a old adage which is that “Players can tell you what’s wrong, but they can’t tell you how to fix it.” Thinking like this can kill your business. Players on social media exhibit keen attention to game design principals and process.
If we’re working on an entirely new product, there won’t be any discussion. Comparative or competitive products can provide insights into the needs of our product as well.

B. Internal UR & Playtests: the subject matter experts in the mine

I oft hear the Henry Ford quote about people wanting faster horses used as a pejorative for the consumer’s ability to self diagnose and as a foil against collecting insights from rank in file devs. Implicit is that they don’t have the insight to match the all seeing all knowing eye. But I have seen this tank products over and over and it’s inverse, proactive delegation, ship incredible successes
One of the saddest things I’ve seen in my professional life was an entire team that disliked what they were working on and had little faith in the direction. They didn’t believe in the product vision statement, subject matter experts knew it was pointless, and users hated it in retail.
In larger organizations, development staff can be one of the greatest assets in that, in aggregate they can anticipate how a feature or product will land with retail consumers. This state can be ephemeral, as they devote more energy to the work, the less objective they become (per some key tenets of Cognitive Dissonance Theory).
If staff are engaged users, they bring keen insights to bear offering up a credible set of desires from real hours spent, unique perspective from their craft, and a desire to seize agency and ownership over their part.

C. External UR, PMs, and Analytics: Applying scientific rigor to creative decision making

As designers, we hope to have a keen instinct for usability, accessibility, cognition, and user needs. But we still need to validate our assumptions. Our efficacy is defined by how consistently we predict these things, but, inevitably what is intuitive to us may not be intuitive to the user. As much as I hold social media and internal teams in esteem, they do not necessarily paint the full picture. for this I look to professional data.

Working with UR
- As soon as UR has cycles I like to start validation the design and will continue to do so as long as they have time assuming I have legitimate inquiries. If I don’t have testable artifacts I’ll make some.
- Targeting specific problems and avoiding sprawl
  - specific player behavior
- Collaborating on artifacts – I find it’s helpful to have a few conversations with UR leading up to a playtest that uses my prototypes
- effective methodology
  - avoiding subjective questions
  - defining success/failure standards honestly
  - Task, request, propose methodology
    - Ask the user to preform tasks that reflect tasks that users may perform in the wild. they don’t need to be 100% accurate, but must test the user’s ability to find specific parts of the UI
    - Ask them to make independent suggestions
    - Show prototypes that solve anticipated user suggestions
- I try to observing user testing whenever possible. Watching a user’s inputs, hearing the nuance and inflection in their responses, can yield subtle insights into how they may engage with the product in the wild.
Working with Analytics
- Paint an early picture of the feature
- Getting engineers planning early
- Pair technical experts on analytics and dev teams
- Making and maintaining useful dashboards
Working with PMs
- Understanding the decision-making structure
- Supporting PMs with leadership
- Target audiences and cohorts
  - The problem with a snapshot of motivations
  - Look good on paper
  - may not reflect actual behavior
  - self reporting

Leveraging collective instinct: Too many cooks is bad right?

Maybe, yet getting a bunch of people to taste your food and offer feedback will make you a better chef. So we need to make a distinction between collecting and analyzing the feedback necessary for effective, iterative product design and the clarity required to prevent teams from spinning out. The consequences of failing to do so are catastrophic:

Design by Committee: Deciders hold misaligned goals, but wield similar authority over the direction. This can force the product into a direction that doesn’t satisfy a valid cohort need. If we’re designing for 12 board members, are we satisfying for the user? Are we writing authentic personas, drafting realistic user stories?
Stagnant Teams: creative teams don’t have clear drivers, direction, or decision-making structures leading to apathy, disengagement, low agency, low output, poor quality, low morale. this can ruin products in so many ways. But, in my experience, you want your staff caring about and engaged in their work.

Tautologically, groups of people, consumers, do things in groups, with aggregate behavior landing somewhere on a continuum of nobody-is doing-the-thing to everyone-is-doing-the-thing.

With commercial products, we aim for as large of a group of people doing-the-thing as possible in order to grows the business. Duh. In software and games on tight deadlines, though, this poses as an existential problem…

On one hand, it’s extremely difficult to get predictive data from based on product goals from consumer focus groups and external surveys. If it was easy, there would be more successful teams, but we see the vast majority of game products failing. On the other hand, by the time something is functionally testable, there may be little time to meaningfully address the concern. In games especially (due to the complexity, timelines, and subjectivity of the feature), huge strategic bets fail to align with yet-to-form user sentiment in s future launch window. How could they?

This is doubly a risk when PMs are out-leveraged by data averse leadership. In these cases, it can be impossible get strong, data-informed direction approved. Additionally the scientific nature analytics and UR can lead to softer recommendations in the interest of unbiased modelling. This is a ticking time-bomb. Product Managers do their utmost to recommend modeled direction, but if senior leadership doesn’t see PMs as credible drivers of the product strategy and hold fast to their own direction, it’s curtains for the team.

So how do we reliably synthesize this?

Though imperfect and susceptible to groupthink, groups are excellent at predicting and estimating outcomes. While a misaligned committee or a stagnant team can kill a feature or product, large groups of passionate, concerned, invested professionals can have the opposite effect, reliably predicting retail consumer patterns at scale. Indeed, like any data source, sample size and methodology are critical and having the data doesn’t necessarily mean we must follow it, but it can act as an initial preview, which can be generated from a handfull of devs under the right conditions.

But why internal teams? Time, personal investment, and expertise:

Internal workshops and surveys are much faster and cheaper to setup
Vetted groups of internal participants remain vetted and accessible for recurring sessions
They may be closer to the target user segment demographic
Research can be conducted without a dedicated test site
Devs often have workstations and tools setup to playtest WIP builds
The outcome of the product or feature may directly impact their livelihood
Consequently the depth of reasoning may be more complete
In some cases, they may have spent years thinking about the problems space
They understand how difficult or easy it will be to implement and what technical hurtles lie in wait
They’re familiar with the team composition and who’s most effective in each role
They know the history of the product and may have considered unexpected solves to a specific goal
They may have alternatives to stated goals, which more effectively strengthen the business
Facilitator can easily follow up, asking additional questions
Telemetry in sentiment can be tracked on the same individual
They will see the product as their own and worth pushing for success

I can go on and I understand there are shortcomings to devs as UR participants as well, but the goal isn’t perfectly modeled data, it’s an early foretelling of the appeal of the product in the retails space.

Back to the stupid Henry Ford “Faster horses” quote (misquote?), I’m skeptical that anyone from that era would have actually picked a horse that’s merely faster horse over a mode of transportation that can hold multiple passengers, protects them from rain, don’t (literally) poop, never bites or kicks, don’t need to be fed or brushed daily, cant’ get parasites, won’t autonomously escape from their pens and damage crops, has built in electric lights, etc.

It’s a foolish argument, made doubly strange in its invocation as it’s attributed to an antisemitic weirdo. It has been used to justify a century of dead-on-arrival products, which, if practitioners of that thinking, would just… ask staff “Do you want this?”… could have been avoided.

The times when my features have achieved the highest level of success, we’ve followed a process resembling this process:

🏆 Draft goals or a high level product vision
❓ Survey or workshop with the team to determine:
- Base appeal of each goal – How strongly did they want this or not?
- T-Shirt cost to execute – How costly did they think it would be to build?
- Risk assessment- What might go wrong with this?
- Latent desires – What did they want to see in the product not included in the goals?
🐮 Methodology should guard against herd mentality
👩‍⚖️ Weigh the data based on respondent criteria
- A track record of predicting consumer outcomes
- Level of engagement with product
- Familiarity with the problem space
- Professional acumen or expertise
- Technical expertise (weighs more heavily in technical risk assessment)
👀 Process & Analyze the data…
- 🤮 If the base appeal of a goal is low, it is much more likely difficult sell to the public.
  - Low installs
  - Low retention
  - Low conversion
  - High attrition
  - Low NPS
  - Damage to the reputation of the business
  - Damage to the reputation of the product
- 💸 If the cost to execute a goal is high, it will be high and one or more of the following will occur:
  - Your team will crunch
  - The product will be buggy, broken, security vulnerabilities
  - There will be delays
- 🤕 If the risk assessment is high, those risks are likely to plague development
  - Cuts will be required
  - The team will resent the lack of foresight
💡 If there is a lot of repetition in the latent desires, consider pivoting toward them.
🔁 Repeat as needed

collaborative synthesis

More Coming Soon…

Leveraging expertise
Distributed ownership
growing leaders
ensuring product success
asking the right questions
connecting ICs
Empathy and support for all
accessibility as a central tenet
breaking down the work
comfortable with tools and dev client
building the backlog

Prototyping & Reframing

More Coming Soon

Broad to detailed
It’s never too early to see something tangible
- Creating emotional moments
approximating the platform
The impact of additional information
creating shared understanding

Testing & Iteration