"The user experience is a metric." Brief high-level practical design strategy thinking and strategy by Michael Schofield.
"The user experience is a metric." Brief high-level practical design strategy thinking and strategy by Michael Schofield.
The Value of Design in Hard Times
When the market’s taken a spill, when your earned revenue is down — people aren’t leaving their homes, folks have lost work, uncertainty leads to spending scarcity - then the easiest line-items to cut are those that involve external consultants. You need to preserve your budget to take care of your colleagues, your business, your livelihoods.
But constraint, especially when that constraint is sudden, unpredictable, and symptomatic of problems widely outside of your control (or even the control of your industry, or your country) - constraint causes strategic tunnel vision focused entirely on stemming the blood flow. All the constellations in your worldview blur while you focus on a small point in the sky.
This is sane.
But one of the things you’re not doing now - or doing less of - is aggressively trying to understand how the service landscape has changed. This is the landscape where the service you provide, and your products, dot grainy plains that stretch far to the horizon. It is the landscape of your users’ journeys - all of them.
Your organization or business exists because the services you provide intercept these journeys. They do not exist for any other reason.
That landscape has changed. It has changed dramatically. What once was - let’s say - a pastoral, sprawling lawn, is now an archipelago. The journeys have been existentially upset and are newly adapting for if not survival then a new reality, like neurons branching.
If you yourself or your colleagues aren’t surveying your service landscape, then while you focus to triage the wound, you aren’t questioning - or, if you are, you can’t answer - whether your services will still be in demand. Do your users’ journeys still follow the same path?
It is not just that design is reconnaissance: design is intelligence.
How differently, then, do you value the role of service design? How differently do you prioritize your colleague, or your consultant, or the time you all allocate as a team to shift your attention to the window?
Remember: the user experience is a metric.
A heads-up about frequency of these emails and podcasts: I am going to begin publishing three times per week, starting this week 👋, and I want to be super honest about my motives. First, I think I provide a small, free, niche, useful service in these little thought blops, and I really like doing it. It scratches a super creative itch for me.
But really, in the interest of oh-shoot-look-what-the-pandemic-is-doing-to-jobs, I want to be able to better leverage some of the audience I’ve built to help sponsor Metric, find new small consulting retainers or research contracts, and suchlike. In other words, my job to be done is to find certainty in this uncertain moment.
If you would like to help “produce” Metric, which I thank you or your organization at the end of the podcast, the deets are below.
Consider liking (❤) this issue of Metric if this made you think. Please take the time. If you haven’t already, please subscribe for free. Help produce this work for $5 per month or $30 per year.
Metric is a podcast, too. Subscribe to Metric on Apple Podcasts, Google Play, Spotify, Stitcher, and all the usual places.
Photo by Tai's Captures on Unsplash
Get full access to Metric by Michael Schofield at metric.substack.com/subscribe
What is the difference between UX and CX?
Let’s be clear, many folks have thrown-in. This question has loads of answers, and this writeup will likely not make it to the top of the search engines. So, what more is there to say? This: it’s not the answer that matters so much as is the philosophy that shapes it.
The answer — and, sure, let me be so bold as to say the right answer — is this: the difference between user experience and customer experience is scope. The customer is a category of user defined by the transaction. Not all users are customers; all customers are users.*
So, how as Metricians do we understand this question?
If we start with the core practical principle that the user experience is a metric, and if we agree to agree that our metric is some fuzzy holistic math — good or bad — we work to push up and to the right, then what’s the real function of using “user” as the adjective here?
What we’re describing is the experience of a given role. Our users are people who, well, use our service. It’s an exercise in seeing just how vague we can be, but most of the time “user” works. When we’re working to understand our place in a larger ecosystem of services, imagined as a journey from a bird’s-eye view where a person moves from one service to another service to our service to another even further on in pursuit of some greater motivation, that they use our service is all we can really say for certain.
It’s only in the performance of designing for that user experience that, flying closer, we perceive the path isn’t solid but an obstacle course with touchpoints haphazardly spaced. The journey is an act not just of traversing from one to the other but the choice of how to traverse. These angles of approach — hopping, skipping, crawling, swinging — are variables in the fuzzy math that determine whether the user experience is positive or poor.
A variety of roles emerge on closer inspection, like looking at light through a prism. A single “user” early in their engagement with our service begins — let’s say — as a “subscriber,” for which we must consider the subscriber experience; they then pay to place an ad in some content, after which they become an “advertiser.” The advertiser experience includes a storefront and transaction, during which they too become a “customer.” A poor customer experience has detrimental impact on the user’s confidence in our service, part of which is defined by the quality of their experience as an advertiser. At no time, by the way, does this person stop being a subscriber.
What does it mean for the overall business when the customer experience is poor, the subscriber experience is alright, and the advertiser experience is good?
This downside-up rabbithole reality defines the UX problems inherent in news, where I presently spend the majority of my time. Ultimately, it is the “user” experience, that higher level fuzzy cumulative, that correlates with business success - but designing to keep that UX in the black is a strategic mess.
But this is true for you, too, wherever your niche. The awareness of this problem of scope is a mark of experience.
It is easy to conflate these roles I describe with personas, but they are not the same. A role in this way is defined by a job to be done that is contained within the motivating job to be done that set the user on this journey in the first place. The work is to first understand why folks use your service, then scope-in to identify the jobs within jobs: it’s how we design for those that ensure when users leave our realm for the next service on their journey that they don’t stumble on their way.
So, next time, when someone asks you the difference between UX and CX - you can now give them the choice to see how deep this rabbithole really goes.
* Some of you thinky service-design folk might write in that the one who pay
Gutenberg doesn't disrupt WordPress
Gutenberg isn’t a breakthrough innovation that made WordPress better. It’s a disruptive innovation making WordPress more affordable and accessible. — Mark Uraine, “Disrupting WordPress”
A couple weeks ago I read Mark Uraine’s writeup about the disruptive role Gutenberg — the new block-based editor (and system of editor-extensibility) — performs for WordPress, the open-source juggernaut powering a third of the web. It nails why the WordPress community has been so hyped (and it’s in a language I speak):
Why would anyone want to change this? The short answer is expressed best in the quote, “If you don’t like change, you’re going to like irrelevance even less.” Software must evolve or it becomes archaic and dies. This bring us to the concept of disruptive innovation, originally conceived by Clayton Christensen. Disruptive innovation describes the process when a more simplified product or service begins to take root in an industry and advances up the market because of its ease of use and/or less expensive entry point. … The great companies plan for this. In fact they make efforts to self-disrupt, or innovate in ways that cause their own service or product to be disrupted. … WordPress has reached this intersection.
— and for many folks, Gutenberg represents that self-disruption. It is a shot of espresso. A spurt of vitality intended to make the sluggish, successful ol’ man spry. It’s a little bit of good magic that wards off the heebie jeebies.
I think Mark’s is the best argument for Gutenberg there is.
I’m also not convinced. I want to use “Disrupting WordPress” as an opportunity to demonstrate how to think about innovation, so I am going to start by putting the kibosh on the idea that Gutenberg is the saving grace the community around it thinks.
Is Gutenberg disruptive? No - at least not like that.
Product is a window
Clay Christensen’s disruptive innovation is key to the point I want to make, and that is that we should be skeptical about the consensus assumption that what has to change about WordPress is the way content is created.
I phrase it like this because Gutenberg really is more than a UI: it represents a fairly different content model beyond just how pieces of content are chunked together by end-users, but how that content is treated in the database, and how developers interface with all that new tissue. Moreover, the ad hoc governance that has organized around Gutenberg to help ensure its inclusivity and accessibility is functionally of greater importance than the Gutenberg codebase altogether.
It makes sense that because there are plenty of usability studies betraying WordPress’s ease-of-use as a myth, that we-the-community target these usability problems with our innova-sers. Ease-of-use is a killer differentiator when you choose one product over another - but usability is flavor, not sustenance.
Disruption requires identifying a misalignment between a person’s core job-to-be-done and the service they’re provided.
The secret to winning the innovation game lies in understanding what causes customers to make choices that help them achieve progress on something they are struggling with in their lives. To get to the right answers, Christensen says, executives should be asking: What job would consumers want to hire a product to do? — Interview by Dina Gerdeman with Clay Christensen
The product — and the features of the product — don’t fundamentally matter unless the user needs something that you can provide them.
Is the WordPress user’s core job to be done to have a usable content-creation experience? No. It’s not even to create content in the first place. Rather, the core job of the WordPress user is to — for example — provide candle-junkies like me with candles, and make a living from it. “WordPress” isn’t really par
UX Design is Morally Gray
Folks tend to disagree with me whenever I say that user experience design is morally gray: there is no inherent requirement to making user experiences people like and prefer to competing experiences that leave users — morally or ethically — better off. Ethical design is a qualifier.
This is an important distinction and nuance to design work that is critical to accept if we intend to push best practice in a more deliberately ethical direction. It empowers individual designers, teams, companies, entire verticals, even disciplines to differentiate themselves by choosing to design ethically.
Assuming that good user experience design work has good intentions is dangerous — and naive.
This also means we must divorce the relationship by what we do (design to improve the user experience) from how we do it (ethically, or not). It means that to be ethical we must choose to be so at each step of the design process, at each touchpoint between conception and performance of a service.
To frame ethical user experience design like this make it easier to appreciate how difficult it is to create an ethical product or service. Perhaps not by intent — we all think we’re the heroes of our own story — but because the design of a thing is the culmination of a hundred decisions, hard ones. The CEO in the business of providing an ethical service might fail because of decisions made in engineering, or because they chose to design to optimize a conversion metric instead of some other made-up number.
It is for this reason we need to make time and resources available to design the design process, creating systems of checks and balances not just for quality assurance that a button can be pressed, but for ethical stresses.
Liking (❤) this issue of Metric helps signal to the great algorithms in the sky that this writeup is worth your time. Please take the time. If you haven’t already, please subscribe.
Metric is a podcast, too, which includes audio versions of these writeups and other chats. Look for Metric UX in your favorite podcatcher.
Remember that the user experience is a metric.
Get full access to Metric by Michael Schofield at metric.substack.com/subscribe
Can jobs-to-be-done replace "Front End Developer"?
Our understanding of the front end as a place no longer holds up to scrutiny. We cannot define it by a specific suite of tools, a kind of user expertise, or even that — if anything — front end development requires a browser.
If we talk about the front end in terms of distance from a user, the “front” specifically being the interface between the user and the service provided, then we ought to accept that voice user interfaces (among other examples) challenge the notion that the front end has any tangible component at all.
Even here, we are cherry-picking a particular kind of user, one that is at the tail-end of a complex service provision - presumably outside the “provision” circle of the Venn Diagram altogether. We’ll call this person “end user.” But again, using “front end” as a descriptor of that distance from a user — while accepting there are no constraints on technology or medium (like a browser) — should be applicable to the RESTful API that I design for consumption by a variety of user interfaces. The consumer is my end user. When I design the interface for that user, am I performing “front end development?”
What I am trying to illustrate is that when we are thinking about user experience and service design, paradigms like “front end” and “back end” no longer align with an understanding of service clusters, ecosystems, or - frankly - users. These kind of identifiers are ephemeral and, as such, pose a problem to companies who organize themselves around these concepts.
You long time Metric readers and listeners — “Metricians?” — might find this latter concern familiar. The practice of thinking in services reveals that same ephemeral nature around the product itself, given that the product is just a tool in a larger service provision, it is thus — like a tool — replaceable. Choosing to design organizations around products will shape the way in which said organizations develop, which is probably against the grain of good service design. Hot take, I know.
So, practically, as service providers who make products that require engineers, how do we hire after we thought-spiral ourselves away from terms like “front end developer?”
I think there is an implied solution. In 2017, Rob Schade at Strategyn suggested a new kind of role called the “Job Manager” in “Product Managers are Obsolete; focus on the Job-to-be-Done.” As an alternative to a Product Manager, the Job Manager focused on the design and development of solutions for a given job-to-be-done.
If you need a refresher, a job-to-be-done describes a task where the user has a demonstrable need for the solution you provide. That is, if I need talk shop and further develop my own thinking about service design, a company like Substack provides a solution for my shop-talking need. The product — the newsletter editor and mailer that Substack provides — is a means to an end, not the end, and not necessarily crucial to my job to be done.
In this example, rather than there being a Product Manager in charge of the newsletter editor, there would be a Job Manager overseeing the entire service Substack provides
The Temporal Midpoint of the Sprint
The two-week sprint is totally arbitrary. We adopt the convention without really questioning the wisdom, but by such dogma of what’s-good-for-the-gander bake someone else’s practice into our organizational infrastructure. The thinking is that two weeks is just about the right time to prototype, test, scrutinize, and deliver a feature. But, is it?
All it took was David Grant raising that question as part of the Facebook Journalism Accelerator about this time last year for those of us at WhereBy.Us to concede the point and, within a week or two, consolidate to one-week sprints. Basecamp, just being Basecamp, shrugs the sprint convention all together, and just published a book that largely makes it clear we’re all just navel-gazing guppies trying to emulate other startups.
Shape Up, that book ☝️, made me question what practical reason do we actually need backlogs, or sprints, which was a refreshing reality check. I admit I find doing away with the backlog compelling - but that’s another writeup. Sprints, though?
While reading about Basecamp’s six-week cycles, it dawned on me that the key feature of the sprint is its temporal midpoint. That is, given any deadline, your activity declines until you’re midway through a milestone before climbing. Why? You realize time is running out.
This is described by Daniel H. Pink as the “Uh-oh Effect” in When: The Scientific Secrets of Perfect Timing:
After the first meeting there is a period of prolonged inertia, then a sudden transition followed by a new, more productive direction.
Human culture is organized around temporal milestones — the beginnings, middles, and ends of things — and so, subsequently, are our moods, hopes, productivity, and the like.
The sprint is an arbitrary division of time we tend to conflate with the timeline of a deliverable, but after about a year of one-week sprints I argue the deliverable is the least important aspect. Rather, the sprint is a structure for sustainably pacing our team’s movement through a service provision by placing temporal milestones at advantageous points.
Beginning: the beginning of the sprint is a fresh start. It’s like New Year’s Day. We make good initial progress keeping our resolutions. We’re hopeful.
Midpoint: the midpoint of the sprint is the ticking clock. It is, no lie, a stressor. It’s designed to make you go oh, shoot, and be honest with yourself and your squad about your progress.
Ending: the ending of the sprint is the dropping of the curtain. Time’s up, we touch base, we fist bump, we move on.
Temporal milestones have different emotional tones and the midpoint tends to be the more anxious. Knowing this, however, allows you to design for those emotions, providing another project management tool for templating a mentally healthy sprint.
For instance, if the anxiety of the temporal midpoint is related to the build-up of to-do items you scramble get on top of, what if we just reduce the number of to-do items? Without reducing velocity, if you cut the sprint in half — from two weeks to one week — you move-up the temporal midpoint significantly, which not only reduces the number of to-do items that got away, but literally reduces the stress period between midpoint and temporal ending.
This is anecdotal but I’ll make a note to check the numbers, but I believe the temporal boon of the one-week sprint is a factor behind the increased “greenness” of the company’s team health. At a glance this feels counter intuitive, because surely one-week sprints equate to higher stress, but the reality is that in that same two-week period we have twice the emotional highs (beginning and ending milestones), and our milestone-related emotional lows are much briefer.
Liking (❤) this issue of Metric is a super way to brighten my day. It helps signal to the great algorithms in the sky tha