Why I added dignity to my design framework

I have four words in my quality framework. Clarity, Correctness, Coherence, Dignity.

The first three nobody questions. They nod, they agree, they move on. The fourth one always gets a pause. Sometimes a raised eyebrow. Dignity? In a design framework? For enterprise software?

Yes. Especially for enterprise software.

Here is what I mean. Think about the last time a product made you feel stupid. Not broken, not buggy, just indifferent. An error message that told you something went wrong but had absolutely nothing to say about what to do next. A form that rejected your input without explaining why. A workflow that assumed you would always take the perfect path and had zero grace for the moment you did not.

That is not a usability failure. That is a dignity failure. The system worked exactly as designed. It just did not care about you while doing it.

Enterprise software is full of this. And I get why. These products are bought by procurement teams, evaluated by IT, rolled out by admins. The person actually using it, the employee trying to raise a request on a bad day, the new joiner who cannot figure out where to begin, the contractor waiting on an approval that has been stuck for two weeks, that person is often the last one the product was designed for.

I saw this up close with Legal Service Delivery at ServiceNow. Early incubation days, no dedicated content design support, a team heads down building workflow after workflow. The in-product content was a nightmare. System logic exposed directly in the UI. Raw table names. Hardcore legal jargon sitting where plain language should have been. The kind of messaging that made complete sense to the engineers who wrote it and zero sense to the legal professional trying to follow a process they had never seen before.

The team was not being careless. They were being fast. But fast without content rigour in a legal product is a particular kind of problem. Legal workflows do not have much tolerance for ambiguity. If someone misreads a status, misunderstands a next step, or cannot tell whether their request is stuck or just processing, things go wrong in ways that are hard to unpick later.

It made me deeply uncomfortable. Not in a precious design way. In a this is going to cost us significantly way.

So we flagged it. Did a heuristic across the product, mapped every place where poor messaging could break a workflow or mislead a user. Once we could show the scale of it, alignment was not hard to get. What followed was a multi-release content initiative, audit, fixes, patterns, execution across three releases covering various legal apps. A proper content design team involved. A plan that actually held.

Customer support tickets dropped 20% after. A lot of the bulk complaints, context issues, confusion, workflows appearing stuck, simply stopped coming in. We also killed a patch-fixing pipeline that had been running every release just to clean up the mess that poor content kept creating.

The edges of a product are not edge cases. They are the job. The empty state, the error screen, the ambiguous label that someone will misread at 11pm when they are stressed and just trying to get something done, that is where the product either treats a person like a person or it does not.

Everything in the middle is easy. Being decent when the happy path is working costs nothing. Dignity is what you build into the hard parts. The moments where the system has to say I cannot help you right now, and still finds a way to say it without making the person feel small.

It is not a feature. You will not find it on a roadmap. But users feel its presence or its absence every single time.

Most frameworks do not have a word for it.

That is exactly why I put it in mine.