When you work for your software instead of your software working for you

How user experience suffers when companies put their needs above yours.

Christian Cantrell
UX Collective

--

A collage of mobile and desktop update and feedback notifications.

Have you noticed that your devices have become needy, insecure, boastful children constantly vying for your attention and desperately seeking praise and approval?

Welcome to the age of growth hacking and data-driven product development.

It used to be that, once we paid for a piece of software, it toiled for us endlessly and unconditionally. Increasingly, applications are demanding more in return for the privilege of their service. And although this newly defined and rapidly evolving relationship costs all of us in time, focus, and productivity, we are being assured that it is for our own good.

When product and science collide

Here’s something you might not know about yourself: At some point in your life, as part of a cross-functional, multi-stakeholder growth initiative, and in an attempt to validate an actionable hypothesis around reducing churn by increasing stickiness using a minimal viable product, you began a customer journey when you were acquired by entering a marketing funnel after which you were segmented into a cohort as you were on-boarded, seamlessly engaged by multiple touch points, and ultimately retained through variable rewards leading to habit formation in order to maximize your customer lifetime value.

Which, despite sounding vaguely nauseating, was probably a good thing. Now that the product development lifecycle has been supercharged by the power of data and the scientific method (books like The Lean Startup and Hooked are to product development what Moneyball was to America’s favorite pastime), customers are probably getting more value out of their purchases than ever.

Fandango email campaign offering a $5 coupon.
One of several emails (which cannot be opted out of) you can expect from Fandango every time you use their service to purchase a movie ticket. This campaign is specifically designed to engage customers within a critical window of time in an attempt to establish regular purchasing habits.

But like all tectonic paradigm shifts, much of the good has been sacrificed along with the bad. And at some point, brave bands of product managers, designers, and engineers will need to venture back and attempt to recover some of what was lost in order to shore up the critically damaged foundations of today’s user experiences.

Auto update: the gift that keeps on giving

As someone deeply invested in the web platform, I was ecstatic when auto update became the default across browsers. Web browsers are perfect auto-update use cases. Because the majority of browser behavior is defined by open standards, most updates mean security patches, bug fixes, optimizations, and access to progressively enhanced functionality. For the most part, we can all allow our browsers to be automatically updated and be assured that, upon relaunch, we can get right back to work, and if we notice any difference at all, it will almost certainly be positive.

Unfortunately, the same cannot be said of most other kinds of software updates. With the exception of security patches (which, no matter how frequent or inconvenient, should always be prominently surfaced and swiftly applied), software updates often feel less like Christmas morning and more like your in-laws coming to visit.

The macOS update window promoting an update to Catalina over security patches.
I’m not a fan of how Apple hides important security patches behind major OS updates. While I might not have the time to update to Catalina (nor, frankly, the desire), I always have time for security.

Taking the time to finally pay down your update debt could mean any combination of:

  • Up to 50 minutes of waiting. (Never do an OS update at the beginning of a busy day.)
  • One or more unplanned reboots.
  • Setting up a device as though it were new. (Every time you do a major iOS or iPadOS update, expect the Spanish Inquisition.)
  • Having to log back in. (Credentials and authentication tokens are frequently and inexplicably blown away during updates.)
  • Incompatibilities with extensions, utilities, or perhaps entire applications that you or your workforce may rely on.
  • UI modifications that a) force you to reorient; b) often do not markedly improve the user experience; and c) might even conflict with years of muscle memory.
  • An all new batch of bugs to replace the ones you’d already learned how to work around.
  • Being greeted by a succession of coachmarks, callouts, beacons, or whatever your design-system-of-choice calls attention-grabbing UI designed to inform you of things at precisely the wrong moments.
  • Saving files in a new format which, the moment you attempt to collaborate, forces others to endure the same update process, thus spreading unproductivity throughout your organization like norovirus on a cruise ship.

Some or all of the above would be worth it if the tradeoff were significant optimizations or productivity gains — if using freshly updated software felt like being clad in a brand new Iron Man suit with a slick, edgy paint job after an intense and exhilarating Tony Stark montage. But all too often, after spending anywhere from several minutes to an hour scrolling on your phone while watching a lethargic progress bar out of your peripheral vision, you are way behind on work and therefore find it difficult to share in the unbridled enthusiasm of the on-boarding tutorials that always seem to be standing between you and whatever it is you need to get done.

The Microsoft AutoUpdate window showing several pending updates.
Since the Microsoft Office AutoUpdate app doesn’t concern itself with your “Do Not Disturb” preferences, it can descend upon you at any moment whether you’re painfully birthing the final passage of your latest novel or about to deliver the kicker while presenting to the CEO. I have resorted to unchecking that little box at the bottom which means, in Microsoft’s enthusiasm to keep my software up to date, they have instead succeeded in forcing me to turn updates off all together. (Note that the first update listed is an update for the updater itself, no doubt initiating some kind of nightmarish, recursive, Inception-like orgy of never-ending software updates.)

To be clear, if you’re a professional or power user, you may look forward to your favorite ecosystem’s version of “patch Tuesday” as though it were the next Avengers movie. But if you are a more casual user, the amount of time you spend updating relative to the amount of time you spend getting value from a particular application may feel disproportionate.

Product people: The biggest problem many of your users have may not be that they have done everything there is to do with your software and are dying to get their greedy little mouse pointers on new features; it is that they are either still struggling to realize the full potential of what might feel to them like a moving target, or that they have carved out their safe and familiar workflows and may prefer stability and predictability over what product managers think of as continuously delivered value.

Microsoft Office error dialog boxes.
A couple of surprises waiting for me after a recent Office update. The promise of auto-update is more robust software, but we all know it doesn’t always work out that way. For several days, every time I put something on my calendar, I got the notification on the bottom and had to restart Outlook. If there was any value to be had from this update, it was lost on me. (Look closely, and you’ll see that there are bugs on top of bugs here: Somehow the “Placeholder” text did not make it into the top error dialog. I will forever wonder what additional insight I might have gained.)

If, like carbon emissions, we could somehow magically freeze software update rates at today’s levels and make incremental improvements to user experience, I’m sure most of us would endure the hardships to come and live to see a reimagined technological utopia. But given that software has been eating the world since at least 2011 when Marc Andreessen famously declared it to be so, and that we are still probably in the very early stages of humanity’s digital transformation, it’s hard to argue the sustainability of our current course.

Hot or not

When modern applications aren’t imploring you to update them with all of the fervency of the One Ring beckoning Gollum, they are not-so-subtly soliciting your esteemed endorsement. It’s easy to declare utter bewilderment at how emboldened applications have gotten about saddling users with the burden of feedback, but the truth is, it shouldn’t surprise anyone.

BlueJeans soliciting feedback after every meeting.
After every single session, the enterprise video conferencing application BlueJeans prompts users for feedback. For me, that’s an average of 35 times per week (the technical term for the number of meetings I attend daily is “fuckton”). This information is passed along to administrators so they can intervene early if network or hardware issues arise. Everyone’s intentions here are good, but the solution is undeniably kludgy and heavy-handed.

User interaction patterns — even gray or dark ones — get that way because they achieve the intended results. When you prompt anywhere from thousands to millions of users to do something in an intrusive, invasive, and persistent enough manner, it turns out that a non-trivial percentage of them will do it — even if the vast majority do not, and even if a significant percentage find the disruption objectionable. But in today’s metrics-driven climate, the need for data supersedes almost everything else.

Mobile Outlook inbox with a feedback banner embedded.
Outlook brazenly soliciting feedback right from my corporate inbox. Keep in mind that this is an enterprise context — not a free application or service. So much for that “Focused” toggle at the top.

In the context of “free applications” (so quoted because I know that, ultimately, there is no such thing) I consider the practice of repeatedly prompting for feedback obnoxious and distasteful, though perhaps not quite an uninstallable offence. However, we often see the very same patterns applied to paid and even enterprise applications with no way to opt out. And rather than actions like “No thanks” or “Do not prompt me again,” we are sometimes insulted by options like “Not now” or “Remind me later” which feel to me like they were plucked directly from George Orwell’s Guide to Content Strategy.

When you cannot even pay money for a user experience that is predictable, consistent, frictionless, and that prioritizes productivity above all else, I think it’s fair to say that the contract between software vendor and customer needs renegotiating. I’m not asking for a button labeled “Go fuck yourself” that, whenever clicked, automatically delivers an electric shock to the responsible product manager. But a polite “No thank you” that opts me out of all future prompts doesn’t seem like too much to ask.

The CapitalOne Eno chrome extension soliciting feedback after a transaction.
If you’re going to ask for feedback, do it directly after you’ve provided your customers with clear value — or even better, right after delighting them — like the Capital One Eno Chrome extension. Great user experiences may not be the first thing that comes to mind when you think of Capital One, but they know what they’re doing these days. Banks know data, and increasingly, data drives user experiences.

Defaulting to distraction

In my experience, the most obnoxious aspect of setting up a new device is not the part where you summarily open all of your apps one-by-one and re-authenticate (secure password management has, thankfully, made this much less painful); it’s the fact that my notification preferences usually aren’t stored in the cloud which means, for the next several days, I find myself inundated with inane interruptions which I already explicitly opted out of — usually multiple times.

Side-by-side comparisons of eBay on two different phones.
On the left, we see that I’ve opted out of most eBay notifications. On the right, we see the same preference screen on another phone (after logging in). eBay records everything about the way I use their marketplace except my repeatedly stated desire to not be constantly nagged. (Honestly, this one’s probably on me for still using eBay.)

Interesting that the commodification of cloud storage has enabled companies to reap the rewards of big data, and that, for all intents and purposes, every single digital interaction on the planet is recorded somewhere by someone for the purposes of marketing, metrics, or machine-learning, yet a single boolean — one tiny bit of information indicating my notification preferences out of all of those petabytes of customer data — somehow remains perpetually out of scope.

To be clear, this is not a benign oversight, or simply the result of saturated product roadmaps. This user story (the unit of work used by most modern product and engineering teams — in this case: “As a user, I’d like my notification preferences to persist across installations”) simply does not exist in most product backlogs (the place where user stories are stashed until they are prioritized). That’s because notifications are critical to engagement, engagement (especially within a limited window of time) is critical to habit formation, and habit formation is critical to revenue. What no longer appears to be critical in today’s data-driven product development environment is a little common sense, respect for customers’ time and attention, and a positive and conscientious user experience.

Technology has evolved such that distraction is the default. Out of the box, apps and devices are maximally permissive about notifications, alerts, and other forms of interruptions. In fact, notifications (usually better characterized as distractions) have become so pervasive and ubiquitous that it takes significant, explicit, and repeated effort to escape them. Not only do you need to activate “Do Not Disturb” on your phone, but on your desktop, watch, and whatever physical manifestation of virtual assistant lurks within earshot.

An Outlook calendar notification reminding the user of Office Yoga in 15 minutes.
Calendar notifications on the Mac version of Outlook do not use the macOS notification API and therefore do not respect your “Do Not Disturb” settings. While I suspect this is intended as a feature to ensure that you never miss a meeting, the reality is that our calendars are full of events that do not merit disruption. That means if you really don’t want to be disturbed, in addition to silencing all your devices, you also have to remember to close Outlook, and if you don’t remember to open it again later, you might miss notifications you actually did want to see.

And don’t forget to close apps that don’t use the OS notification API (I’m looking at you, Outlook-on-Mac) since they will blithely distract you — despite notifications being turned off — with such urgent and essential alerts as a coworker you don’t even know being on jury duty, or the yoga class your local site leader keeps putting on your calendar (which you have zero intention of ever attending) is starting in 15 minutes. Finally, if you’re a Mac user, you’ll need to turn “Do Not Disturb” back on again tomorrow since macOS does you the dubious favor of resetting your notification preferences every morning which means, just as you sit down with a hot cup of coffee ready to apply yourself to the challenges of the day, you are usually met with your scheduled allotment of update reminders. (The alternative is to schedule “Do Not Disturb”; to learn how, and for tips on how to make toggling “Do Not Disturb” on your Mac much more immediate and fluid, see this blog post.)

Lest you think I’m some sort of luddite, technophobe, or Linux-wielding, neckbearded curmudgeon, I am as enamored with technology and constant connectivity as anyone (here I must confess to having no fewer than three phones — and that’s the result of exercising painstaking restraint). But when distraction becomes the default — and when it becomes a concerted effort to disconnect so that you can focus on your work, a meeting, your children, or simply your surroundings — it’s clear that we have lost our collective way.

Operating system or ecosystem?

Operating systems were once relatively open software platforms that largely existed for the purposes of either generating revenue directly or selling hardware. Increasingly, they are being recast into vast, cavernous portals reverberating with the siren songs of ecosystem lock-in and recurring service revenue.

While I will stop short of appealing to some mythical, halcyon age of moral technological superiority, I will point out that the very same anti-competitive tactics that famously landed Microsoft in court in 2001 are now commonplace across the software industry (e.g., Microsoft now uses the Office 365 enterprise installer to surreptitiously switch users’ default search engine in Chrome from Google to Bing). The principal difference is that exclusionary, anti-competitive behavior today is generally not paired with Windows-level market dominance. But that doesn’t mean we get to opt out of vendor coercion; it just means we have more choice as to which ecosystems we get locked into.

Windows 10 and macOS dialog boxes.
It seems insane to me that there is code inside of operating systems designed to prevent users from switching to their browser of choice. Of course, to a product manager with KPIs around customer acquisition and retention, it would seem equally insane not to. I would argue that the disconnect lies in what I consider to be misguided KPIs.

Combing through Windows, macOS, iOS, iPadOS, and Android in order to document all the ways each respective platform tips as many scales as possible in its own favor is far beyond the scope of this humble commentary. But I think it’s safe to say that platforms have increasingly become expressions of incredibly rich and diverse ecosystems, and that hardware — while still representing extremely attractive margins in most cases — is just the terminal through which additional revenue is meant to flow.

You know how cutting the cord was supposed to lead to a broadband-fueled renaissance of à la carte content, but has instead resulted in unpresented fragmentation across disparate streaming bundles which, combined, add up to more than your old cable bill? Bloatware has similarly been reincarnated as pre-installed, first-party applications and operating system “features” which hold both the full potential of our devices — and sometimes even our focus and productivity — hostage until we finally pay up. We used to call this type of market strategy “double dipping”; now we refer to it using vaguely complementary terms like “full-stack.”

Screenshot of an iPad trying to get the user to set up Apple Pay.
If you don’t opt into all of the services Apple wants you to early on, you will receive a persistent notification imploring you to “Finish Setting Up Your iPad.” In this case, Apple would like me to set up Apple Pay (which I just opted out of) on my 12.9" iPad Pro — quite possibly the most cumbersome and least convenient contactless payment device ever manufactured.

Ask long-time Mac users which OS update was their favorite, and they will inevitably tell you Snow Leopard. To us, Snow Leopard represented the pinnacle of what was then called OS X — the perfect balance between the power and stability of a UNIX-based OS with all (nay: more) of the usability of a Windows PC. The best feature of Snow Leopard was that it contained very few new features, focusing primarily on performance and other optimizations like allowing users to reclaim up to 6GB of disk space (which, when adjusted for storage inflation, would be the equivalent of something like 24GB today).

Photo of a WWDC presentation with the text “0 New Features” on the slide.
Bertrand Serlet during the 2008 WWDC Mac OS X State of the Union general session famously declaring that Snow Leopard had 0 new features. That was an exaggeration, of course (10.6 contained Exchange support), but the message resonated in a way that I don’t think even Apple anticipated.

I remember driving half an hour to what was then the closest Apple Store, happily paying $29, and keeping my Snow Leopard disk in a secure, undisclosed location while holding out on subsequent updates for as long as I possibly could (which was exactly as long as my Mac lasted before I finally needed to replace it).

Over a decade later, I would happily pay significantly more than $29 to have features removed from my most frequently used applications and devices if it meant reclaiming storage space, and that I would have to deal with fewer bugs, security vulnerabilities, performance issues, notifications, and constant updates to features I never wanted in the first place.

The iOS “TV Provider” selection screen showing every possible TV provider.
iOS and iPadOS now have settings for your TV provider (independent of Apple TV settings). An app that can play content from your TV provider sounds like fun. An operating system that concerns itself with your TV provider sounds bloated.

Course correction

Just as benevolent attempts to democratize information and make the sum total of human knowledge instantly accessible to the world’s population has inadvertently resulted in the annihilation of anonymity and privacy, the subversion of liberal democracies, and the rise of dystopian surveillance states (Oops! Our bad!), attempts by the software industry to provide more customer value and reduce product friction has inadvertently resulted in devices that, every time you look at them, behave like a newly hatched brood of gaping nestlings the moment their mother alights ready to regurgitate a bellyful of partially digested insects.

But some 2,500 words into this article, you may be surprised to hear that I am sensitive to the needs of software vendors — that, as someone who has been in the industry for over twenty years as an engineer, engineering manager, technology evangelist, prototyper, product manager, and now Director of Experience Design at Adobe, I have to own up to being part of the problem. Perhaps as a form of absolution, therefore, I’d like to propose some solutions.

Product people, if I may be so bold…

1. Modularize all the things

Part of the reason software and user experience has reached this point has to do with the fact that business models have evolved faster than application architectures. More than likely, you are paying for at least some of your software through one or more subscriptions at this point which means you are entitled to ever-increasing value. Unfortunately, most code bases were not architected such that features could be added (or removed) through the discrete hot loading or unloading of modules. Therefore, to get new functionality, you may need to download and install entire applications which means waiting for monolithic binaries to cross the wire, closing applications, restarting them, and being assaulted with calls to action reminiscent of low-budget commercials for local used car lots — not necessarily because you’re excited to try new features, but because your will to resist the constant beseeching and imploring has finally been sufficiently eroded.

What would the user experience look like if application architectures and business models had been co-developed in such a way as to compliment one another?

What would the user experience look like if application architectures and business models had been co-developed in such a way as to compliment one another? Most well-established applications out there support some form of extensibility, but imagine an alternate reality where just about every feature of an application was implemented as a module. That would mean users could select from a menu of features, adding or removing them as their needs, workflows, and skills evolved. Both first- and third-party modular functionality could be surfaced in a more contextual and relevant manner — at moments when users were far more receptive. Application configurations could be stored in the cloud so that future installations would consist of a relatively small bootstrapper followed by a list of modules (and, seamlessly, their dependencies). And core application updates could be handled separately from feature updates so that users could install security patches and performance optimizations without the risk of their apps and workflows changing in ways they do not want or need.

Applications could have default configurations that correspond to users’ specific, intent-based tasks. I would argue that such workflows should err on the side of simplicity and sparsity, allowing users to score quick and early wins. Complexity should only be added when and if necessary, and only at the rate at which users’ skills improve.

2. Rediscover the web

The web is like an omniscient and immortal deity in an ancient parable wherein mortals are constantly straying from it, but it is always willing to embrace their eventual, repentant return. Even as we are seduced by mobile, IoT, chatbots, voice assistants, and augmented reality, the web continues to be one of the most efficient and frictionless ways to quickly deliver value to customers.

Whenever there is some question as to how a solution should be implemented and delivered to customers, the web should be granted the right of first refusal.

Maybe the number of years I’ve spent working with web technologies has etched a permanent bias in my mind, but anytime I can avoid downloading and installing an application, commiting to constantly updating it, and having to worry about the security and privacy implications of giving it full access to my device, I tend to opt for web-based solutions. Of course there are myriad exceptions which prevent me from declaring “web first” to be the cardinal rule of product development, but in my opinion, whenever there is some question as to how a solution should be implemented and delivered to customers, the web should be granted the right of first refusal.

Time spent downloading and installing updates is time not spent learning about and exploring them.

I’ve found myself much more open to tutorials and new feature orientations in the context of web apps than native (locally installed) apps. Although I haven’t conducted a proper user test on myself, my working hypothesis is that it is not so much that I am perpetually uninterested in new application functionality; rather, time spent downloading and installing updates is time not spent learning about and exploring them. Given that time is every professional’s most precious resource, having instant access to new features and functionality — as one generally does in the context of web apps — may increase the likelihood that users are willing to engage with them.

3. Your app is a thirsty bitch

Your cat constantly trying to take a nap on your laptop is adorable. Your app constantly asking me to rate it is not.

Anytime you ask users to do something that is in your best interests rather than their own, either reward them, provide them with a way to opt out, or preferably, both. In an ideal world, things like the collection of detailed usage statistics and the solicitation of application feedback would be strictly opt-in, but I’m trying to remain at least partially grounded in reality here. If you’re not going to go the opt-in route (and let’s be honest here — you’re not), at least show your users that you appreciate their contributions, and that you respect their time.

Losing sight of the fact that your customers are people rather than data is modern product development gone awry.

Data-driven product development is a wonderful thing, but like all wonderful things (gin martinis, for example), only in moderation. Product development is at its best when it is driven by verifiable metrics rather than the confidently stated but ultimately subjective opinion of the senior-most contributor in the room. But losing sight of the fact that your customers are people rather than data is modern product development gone awry.

4. Notification elation

Allowing users to opt out of all notifications in an easily discoverable, expedient manner is absolute table stakes here. In fact, it’s immensely discouraging that I even had to take the time to type out that sentence, and that you had to waste a second or two of your life that you will never get back reading it. Yet here we both are.

The right way to do notification preferences is to make them part of the authentication or account creation workflow. A polite “Welcome, Christian! We’d like to send you notifications from time-to-time to let you know about promotions and other limited-time offers. Are you in?” is not such a hard thing to do, and it will automatically earn you a net promoter score of 10 rather than the 0 you will get when you distract me with irrelevant and unsolicited notifications.

You’re already storing everything else about your customers; why not store a few bits of additional information that might actually benefit them rather than just satisfy this quarter’s KPIs?

Additionally, store and sync your users’ notification preferences so they only have to communicate them to you once. You’re already storing everything else about your customers; why not store a few bits of additional information that might actually benefit them rather than just satisfy this quarter’s KPIs?

The fact that app-specific notification throttling is being built in at the OS level is all the evidence we need to both accuse and condemn product managers the world over for lacking sufficient empathy for their customers, and for putting their needs above those of their users.

The macOS notification configuration window.
I love that all modern operating systems allow you to throttle notifications at the level of individual applications. What I don’t love is that we live in a world where this is necessary.

5. Stop super-gluing your Legos

Probably because of the indelible impression they made on our young minds, software developers and designers never tire of Lego metaphors. So if you will indulge me, here’s one more.

At some point, platforms that are epoxied together such that they cannot be sufficiently customized or personalized stop qualifying as platforms at all.

I don’t have a problem with platforms that are designed to be assembled in a certain way. I don’t even have a problem with platforms that come prebuilt. But at some point, platforms that are epoxied together such that they cannot be sufficiently customized or personalized stop qualifying as platforms at all.

I think it’s perfectly justifiable — even mutually beneficial — for companies like Apple to sell its customers comprehensive, end-to-end, “full-stack” solutions. But to restrict the ways in which users can subsequently choose to customize their experiences and workflows — after paying a premium for hardware that, let’s be clear, was not remotely subsidized by said services — is nothing less than committing the sin of super-gluing your Legos.

6. No app is an island

Applications, not unlike children, have a tendency to be narcissistic — to embrace a sort of geocentric worldview where they are at the center of everything that matters. The difference is that most children grow out of this misperception as they mature while software just seems to lean further into it.

Painful as it may be to admit, the user journey neither begins nor ends with your product.

While the behavior of most applications may not be unforgivably egregious in isolation, contrary to what most designers, developers, and product managers seem to believe, their applications or ecosystems are not the only ones their users engage with. You may not think a handful of updates, an unsolicited notification here and there, and the odd feedback prompt is all that big of a deal, but everyone else is thinking the same thing. And just like the noise level in an elementary school cafeteria self-perpetuates, competition for users’ time and attention is similarly escalating.

Painful as it may be to admit, the user journey neither begins nor ends with your product.

The upshot

It would take an article far more ambitious than this one to unearth and illuminate all the ways user experience suffers when software vendors put their needs above those of their customers (notice how I’ve deftly avoided directly confronting the issue of user tracking?). But in many ways, the debate around how prescriptive, intrusive, and restrictive user experiences should be is not all that complicated.

  • If you are a designer, product manager, or a developer, don’t just declare yourself design-driven, or user-experience obsessed, or a disciple of whatever methodology it has become fashionable to lay claim to, but prove it through the rigorous and critical evaluation of the solutions you deliver.
  • Call your colleagues out — peers and superiors — when you see them putting the needs of the business above those of your customers (you’ll find that most people in the room agree with you even if they aren’t comfortable speaking out), and promote models where the business benefits in proportion to the customer.
  • Follow every shot of quantitative research with a qualitative chaser.
  • Do not design, develop, or approve any user experience for your customers that would not delight you, your friends, and your family. (If you are not proud to claim and evangelize your own work, something is probably wrong.)
  • Resist pursuing new functionality until existing features are finalized, optimized, and refined. Finish what you start.

And above all else, when contemplating a business decision that will manifest itself through user experience, try not to think of your customers exclusively as data or cohorts or a Total Addressable Market. They are professionals, hobbyists, educators, and students who have put their time, money, and faith in your product or service, and who in return deserve more thoughtful and respectful user experiences than we are giving them today.

--

--

Creative writer and coder. Formerly Director of Design Prototyping at Adobe.