In my experience, the software development profession could spend a long, long time doing some self-reflection about this one. It's eloquently stated, and something a lot of developers could learn. Too many times, I've seen overly restrictive inputs cause users to hate and distrust the software. Ironically, overly restrictive inputs cause users to think that the software doesn't properly understand the domain, which is the root of mistrust.
We should be very liberal with accepted inputs. I call them "Fuck It Buttons." There are lots of cases where you want a "Fuck It" button to just go around all the data entry and get an answer or move on with minimum info. Warn that the data isn't complete and we're using defaults, and don't just make output look the same as a complete workflow, but let them go through, nonetheless. Health care is just one example, but "Fuck It" comes up in every industry.
This is the UI/UX equivalent of knowing which hills to die on.
I highly doubt the developers have anything to do with this in this case. The people requiring the inputs are managers who are responding to regulators and insurers. They're not going to buy software that has a Fuck It Button that allows workers to skip data entry that could cost them money, time, or lawsuits.
At Epic there aren't really product managers. The devs mostly set the projects, design, scope with input from clinicals/sales (a very small group).
So it is interesting to me because most of the design choices - both good and bad - are made by the devs themselves with input from area experts in the aforementioned group, QA, and customer implementation/support.
Some might argue there would be better results with someone who is not the dev managing the product more. But there are pros as well as cons.
> Ironically, overly restrictive inputs cause users to think that the software doesn't properly understand the domain, which is the root of mistrust.
Well, they're quite likely right! I freely admit that as a developer, I don't understand the domain remotely as well as the people working in it (construction workers in my case). The reason there's still a decent market for custom software and that the likes of Epic haven't gobbled up everything, is that every so often a construction worker, dentist, nurse or whatever picks up enough programming to actually make something that suits them, and they manage to bypass the administrators addicted to sales dazzle.
At our company we came to the same conclusion. We have a DSL that is essentially a programmable schema to describe the shape of the data (more specifically a contract) you want to capture as well as how answers and decisions are derived from it. The only hard validation we have are types, eg. you can't put letters in a box that captures a number type. Other than types the rest is soft-validation which means that you can input anything, even if it is partial or not quite correct, and the system will do its best with what it has. In tandem, at any point in time you can ask the system to tell you what is missing and/or incorrect. All this then affects the lifecycle of the information, ie. you can't move past certain checkpoints in the workflow if the information is not in the required shape. In the context of a medical software imagine you can fill in just the things that will get you back meaningful answers to help you treat someone and you can deal with the rest after to make the case complete.
Like with most things, it depends! Maybe it's a default value; maybe it's a null; maybe it's a special value that triggers a workflow on insert. I'm an evangelist for RDBMSes, and they can do so much, so let them help you!
Maybe you have a state column that's derived that you cannot move to another step in the workflow until all nulls are filled in, but you've let the UI save what data it knows about and move on. It totally depends on what the user is doing and why we're skipping steps/data.
Honestly this sort of deferred validation exists as a standard feature of certain modes of data intake that are often criticized for same, for example paper forms (the "required" fields can be left blank), or creating support tickets via email (required fields stay null until an agent updates the ticket via web UI). At some point additional round trips may occur to pay back this debt, but debt is a powerful tool for that person in the field who needs to move onto other things until the dust settles and they can pay it back.
Paper forms can be filled in by different people with different roles at different times. Customers can fill in their personal data and possibly leave blank something they don't understand. A clerk can review the form, ask the right question and fill in the missing field plus the remaining ones.
"Fill in what you know and leave the rest to us" is a simple and cheap to implement GUI compared to a full fledged workflow. It could bootstrap a process quickly at the cost of some extra labor in the customer facing department. Maybe they have that extra bandwidth and the sw developers don't.
We should be very liberal with accepted inputs. I call them "Fuck It Buttons." There are lots of cases where you want a "Fuck It" button to just go around all the data entry and get an answer or move on with minimum info. Warn that the data isn't complete and we're using defaults, and don't just make output look the same as a complete workflow, but let them go through, nonetheless. Health care is just one example, but "Fuck It" comes up in every industry.
This is the UI/UX equivalent of knowing which hills to die on.