We Are Not Masters of Our Design Destinies

We have a lot of clocks around the house. Not entirely sure why. Partly because we like knowing the time. I think partly because we love little decorative items, but try not to clutter up the place too much. Clocks are functional, so it’s okay.

Here’s a not-untypical one.

If you didn’t know, most clock (and watch) makers don’t make the movement, or the actual clock part anymore. They buy that part from a handful of specialist makers.

And for many clocks, the specialist maker moved the factory, outsourced, or went out of business decades ago. There are for many of these sorts of products a tiny number of gigantic manufacturers, so you are left with little choice of who to deal with.

For clocks, the back of many of our decorative ones look like this:

The same one, in white or black and no other color, for all of them. Why does that matter? Because it’s a bit awful.

Battery change requires a tool, but I have never found a truly suitable one. There ARE labels there, but can you see them? It’s not the photo. They are unreadable, by anyone, in any lighting conditions. Setting the clock is a nightmare.


In the old days a business made things. A few of my clients still do this, for hardware at least. Metal comes in, they forge and machine and assemble a product, stuff it in a box and ship it. If the customer complains, they find the problem and fix it, often upgrading all their processes so it cannot happen again. Slightly more recently—or for a few businesses—even when outsourcing, they run their supply chain tightly, and vendor solutions are built to exactly their specifications.

But more recently, we’ve moved to everything being a commodity. Hardly any end manufacturer specifies clock movements, fasteners, or motors. Instead, you have to buy what’s on the open market, what is already built by some factory in—probably—China.

I am not sure that the vendors are evil per se, but they are insulated from the consequences of their decisions. They get good feedback from their customers who buy based on price, and they never have any reason to talk to end users. End users don’t give them money anyway, so who cares?


The digital world is much the same. In the old days I worked on a lot of projects where we built stuff from the ground up.

But very, very little code is written anymore. Not just turnkey libraries, but services. My corporate clients don’t make authentication tools, sales tools, video or sharing functionality, set up email servers, or anything. They contract with vendors, and we do what the vendor tool can do.

And that’s the critical part.

So I agree that we should do this or that and get out of some awful practice proven to be bad for users, to be dangerous. Say, passwords, and questions for recovery. But no matter what I do, I have no ability to change it. Because some business guy picked a vendor. A vendor who doesn’t have to deal with end users, just customers.

And UI integration aside, the vendor simply does not offer simplified, NIST-compliant password rules. They don’t offer out-of-band recovery methods, so we’re stuck with questions and answers. They certainly don’t offer no-password (all unlock code) systems, PIN or biometric unlocks or any other modern solutions.


Want another case? I have lately had to add the actual words “Sign Out” to an app I designed. It took some gymnastics to make a function that made any sense out of this, and took a number of meetings to get the project team on board with it. Because the requirement didn’t come from the product owner, from the business, or even really from the corporate technical security guys but from IBM AppScan.

The client uses this tool to “validate” app security. Which means, at least the way they use it, there’s no human logic, and they’ve outsourced their requirements to a vendor. My redesign is approved by everyone, but it “has to pass AppScan.” If it doesn’t then we do this all again.

My experience designing mobile apps for the better part of two decades is that Log Off types of functions don’t make any sense to most users, and aren’t used by anyone but engineerds even on websites. But who cares what the project team, UX, or even users think now? Because we have a vendor tool that dictates what we do now.


We’re not all masters of our destiny, and saying we must do or stop doing this or that is not productive to a lot of designers. We need to find the half dozen people who are in charge of making each critical tool, and find a way to make them understand why improving their products is critical.

I try, I really do, but there’s a very solid limit on what a UX team (or even worse: a UX vendor!) can do to make a vendor change. They take direction from business, and business wants to check the box and hit timelines.

Show your support

Clapping shows how much you appreciated steven hoober’s story.