Take great care in adding constraints to processes to avoid doing so needlessly.
Online you will frequently find forms that have required fields that needn’t be. Certainly if you were designing with focus on what is best for customers those requirements rarely make sense. Occasionally a required field is a sensible constraint on an online form but so often they add unnecessary constraints.
I frequently find those forms even requiring a false answer since a response is required and none of the options are true. Often this is because the organization is thinking of the boxes they expect users to fit themselves into rather than thinking how to create the best user experience.
I wrote previously about a company representative that suggested a customer change their name because the computer system didn’t accept names with 2 characters. Constraints on creating a secure password are a frequent failure of web sites for the last 10 years.
Man without arms denied housing loan due to inability to provide fingerprints
because Wu Jianping has no arms, creditors claimed they could not give him a loan since he was unable to be fingerprinted.
After the case was publicized and there was a great deal of negative publicity on social media the banks modified their process and approved the loan. But your organization shouldn’t have as the mistake-proofing (obviously not mistake-proofing at all) that when the process doesn’t quite work well then rely on a massive social media outcry which is a signal to us to straighten out the issue.
Frequently I see unnecessary constraints creating the edge case excuse. By burdening your process with unnecessary constraints you create edge cases that fail and then use the excuse that each of the edge cases is rare and therefore you can’t justify the expense of fixing them.
But if you designed the process sensibly in the first place the edge case never would have failed and you wouldn’t need special work arounds for such “edge cases.” A simple example of this is unnecessarily complex web page code that fails if to submit a button without javascript. Yes, a small number of users won’t have enabled all javascript to run (today anyway) so it is an “edge case” to deal with if you don’t have the form work without javascript. But there is no decent reason to have it fail in most cases.
There may be some cases where not letting a search term be submitted without javascript but most often there isn’t. Creating an unnecessary constraint by coding it so it requires javascript and then failing and saying the failure is due to the edge case of not having javascript enabled is not a good way to look at it. The better way to look at it is our decision to create unnecessary constraints created this problem. If we avoid creating constraints without very good reasons we will eliminate many different use cases from failing.
There are good reasons to use javascript to create experiences that benefit the user. But well done code will degrade gracefully . That is it may add a constraint that in order to enhance the user experience with these extra features (perhaps auto-complete of you search based on what you have typed so far) but you don’t break the core feature from working. So the constraint is not something that blocks the process from working at all, it just might be without that constraint being satisfied the process is a bit less pleasant but it doesn’t fail.
Another similar idea is the use of flash instead of html for simple web content. Years ago many restaurants had massively complex websites for very simple content and part of that was to create a constraint for flash for their web site to work. And they could just say it was an edge case for any user without flash (and give them a link to install the security risk that is flash on their computer in order to view their menu). After Apple refused to enable flash for the iOS (for iPhones and iPads) the fallacy of creating a constraint that our website can’t be seen by those without flash installed was accepted and many places have fixed this failure (though it is still exist on many small sites).
The lifespan of technology solution is often quite long (even though it seems things are constantly being updated). When you design in constraints that are at least arguable acceptable given the state of affairs today you may well be handicapping yourself in the long term. In general, more effort should be paid to avoid adding constraints to your processes without a very good reason.
First, don’t add constraints without good reason. This seems obvious but is not followed in practice as much as it should be. If you do add constraints what happens if those cases that don’t fit the constraints you added? What about someone without arms for your new fingerprint requirement? You shouldn’t rely on social media firestorm as the only way to fix your process but it that is the way too many companies actually work. And create a culture that values customer focus by everyone in your organization (which requires giving people the authority to act sensibly at the gemba, and a system that updates the standardized process when ).
The thinking that leads to adding constraints that make problems more likely is similar to what I described previous in: Practicing Mistake-Promoting Instead of Mistake-Proofing at Apple.
Product and service design impacts the user experience. When the product is needlessly complicated that does the opposite of mistake-proofing it is mistake-promoting. In addition to mistakes extra “features” often means extra ability for companies to use those “features” against customer. So you have companies like Hewlett-Packard for example has a long history of intentionally breaking customer’s printers using “features” no customer would want.
In another example “smart TVs” provide many paths for mistakes impacting customers (security breaches, software failures, etc.) or for companies to use the “features” to degrade the user’s experience intentionally (such as Samsung injecting ads into the user’s TV experience).
Samsung is adding new obtrusive ads to your old smart TV
adding intrusive features after televisions have already been purchased, is the kind of customer-hostile behavior that consumers had to put with from PC OEMs for decades.
…
LG was experimenting with pop-up ads in 2013, and Panasonic has been using software updates to add start-up banner ads for years — and that’s just the tip of the iceberg.
Sadly today we must consider how a company will use what we buy from them against us. They create products that allow them to break what we bought if they can find a way to use that to their advantage. In this case we need to consider what constraints exists to prevent the company from abusing us in the future.
Partially consumers can protect themselves by purchasing things without “smart” features that can be used against you (“Smart” TVs seem to me to just be a bad idea). Pretty much any proprietary software integrated with a product is at risk of being abused by the company (or opening you up to risks because their product has security holes that can be used against you – or others). Mainly I think it is wise to look to the track record of the company. Buying something from Hewlett-Packard today given their decades of customer hostility to printer customers seems like an unwise risk to take. Apple isn’t perfect (their software quality the last 5 years has been lacking) but compared to many others they have a long history of being more concerned with providing users what they want and not creating needless constraints for users. Apple has a great deal of room to improve but compared to others they look pretty good.
Related: Software Supporting Processes Not the Other Way Around – Designing In Errors – Support Theatre – Making Life Difficult for Customers – Complicating Simplicity – When Companies Can Treat You Like an ATM, Many Will Do So – No Customer Focus
