mostly money, Those sometimes it is also OSHA or, ironically, user experience. Some people who are required to use the equipment that you are hoping to streamline are too honestly stupid to be able to get Around needing those extra steps. i’ve seen this in my own workplace where The real winners at my job seem to find someway to make it that much harder on themselves even when I repeatedly show them a better way to get the job done.
True and I’d say accurate. There are many other factors and reasons. Money is the big one in a catch all- not even exactly always the cost of changes- but CIO Bill or CSO Jane and all these people pushed hard and worked people and tied up all this money in a project they pushed or President Jane called this the “next revolution..” and after all the hype and resources it would clown a bunch of people to launch and admit you didn’t hit the target. That’s the culture many places. Not all but many. The project is a success even if it fails because of it isn’t a success that means the people behind it failed. It isn’t just that big wigs want to keep the board happy or get promotions or keep face- shit rolls down hill so as they look for people to blame the ace can swing down the line, and politics. Bill may not get fired and if he doesn’t and you didn’t back him- you’re on his list maybe. Things like that.
But there is also the case that depending on your users and use case you can’t win. Let’s say Apple ditched their entire interface system and style and went to something new that was objectively better or suited market research on users. You’re going to have a lot of users who hate it. Now, many users who like the new interface probably weren’t going to leave apple of you kept the old one. It’s questionable how many android users Apple would convert with a new interface. Those people who hate the new interface though- they might just say screw it. If I have to learn something new I don’t like I may as well buy something cheaper… etc.
and let’s say that 9/10 users by volume have a certain use case for a program. So you might feel pretty safe to change your interface. Well….maybe not so safe.
If you have a program used by consumers and enterprises- you may have a case where “most of your users” are using the program for a specific commercial job. That use case may vary widely from general public use. If your corporate customers use your program because it is free as a bundle to some hardware they buy and is good enough that paying for another program wouldn’t be worth it for the improved user experience to them- you have an almost guaranteed customer anyway- but your retail customers who pay for the software aren’t captive in the same way. So in that case you might be wiser to design for the 10% of users vs. the 90%. We can explore all manner of pocket cases like that- but the idea is that for whatever reasons users can be “weighted” differently. Essentially there are some users that the business side doesn’t really care much about or cares less than other users.
Asides OSHA, general policy or compliance are other reasons. If your job is to make professional software- a POS system for a store chain, accounting or purchasing software etc. you are probably designing to certain criteria. Now, generally speaking “IT” is its own organization- department. Some large companies may have each department have dedicated developers and such in the department, usually developers are outside the company or part of their own department. So sales requests a new program to increase sales and it gets a green light. IT builds it. Sales is losing money. Blame is coming. Why after the new program is sales losing money? Oh. Things are being shipped to the wrong addresses? Why? Oh. The new program has a giant list of ALL addresses and not just the customer who the account is for? Who did that?
Did IT not have a spec and not consult sales and decide to do that as a design choice, or was it mandated by sales because they have some use case where they wanted that? If IT makes the design decision IT screwed up. If sales requested it be that way, sales is messing up- it’s training or worker issues inside sales.
That impacts whose budget pays the fix and who gets fired or loses bonuses or gets a “black eye” and is undermined etc.
but often times IT builds to user spec based on their requests and policies- so the UI design has to reflect those policies.
That’s where UI/UX get sticky. You can “lock down” a program. This is common in point of sale systems or warehouse systems and in jobs done by “gig contractors” but you see it other places. You design a very simple interface that can ONLY be used a specific way and has almost no flexibility.
Prices all have to come from a list, discounts must use a scanned code, products have a button or must be scanned in. The problem with that is for example- if your employees can’t change prices or manually input discounts you reduce the odds of then stealing or making mistakes. You also get rid of “work arounds” like- “oh yeah- if they are on a promo there is an entire separate menu to ring that up (because you’re tracking promo purchases etc..) but we don’t do that, the promo just gives 15% off so we just key it in as 15% off…” there are all sorts of math and process changes that can make a BIG difference in things like profits or accounting or back end systems. So locking the system down tight makes it so almost any moron can use it and not mess up and the smart ones can’t “game” the system by finding clever ways to cheat or steal etc.
Where the problem enters is that if the system is that restrictive- it can’t handle anything you didn’t anticipate. Discounts must be scanned- what do you do if the scan doesn’t work? Employees can’t choose an address that isn’t on a list- so if the customer changed address or there was a mistake made adding them to the list, if the employee can’t update the list, to make a purchase the customer has to wait while the employee tries to solve the problem. Those are silly little examples but a lot of those stuff gets REALLY subtle and complex when you start dealing with international laws and shipping and high level logistics and inventory programs and accounting and purchasing and project tracking and what not. An overly restrictive system can prevent people from doing their jobs, but the less restrictive the system is the more the individual user has discretion to use the system other than designed or circumventing policies etc.
Sometimes there is a wink and a nod in there. The design team built a system a certain way for legal or political or policy or other reasons… but if you the worker HAPPEN to decide to use it this other way that makes your life 10x easier than the suits who laid out the “vision” intended… wellll…. So there is some of that too.
In the end though- your end user is smarter and dumber than you can ever imagine. Outside of critical type projects- there isn’t going to generally be this period where a dedicated team of the best and brightest developers and testers spend 3 years beating the software down and finding every loop hole and optimizing everything. For most software that makes no sense. It isn’t that serious and delaying it and adding cost to treat it like your app that lets you preview AR hair cuts is the control unit for a Martian habitat or a hypersonic airliner is daffy. You do as much research and thinking and testing as suits you and then you rip it.
You do this because…. The control unit for a Martian habitat above all must do its job and it must do it reliably. If the interface is a little bleh but causes no pro work asides being less than award winning- the people breathing air on mars don’t care. Better than than it be beautiful and enjoyable to use but sometimes the air turns off for a while. Your dating app can have bugs as long as people like it. If you’re making money and not losing users the bugs are bugs and the issues are issues but they aren’t costing you money and thusly may not be worth spending money to fix versus focusing on things like new features or things people are complaining about vocally.
The big take away there though is that it doesn’t matter. If you spend as much relative time and effort and money to create the next social media app as was spent to reach the moon, you’ve designed and anticipated the optimal UI/UX and squished every bug… your users will STILL request changes. They will STILL come up with use cases and workflows you never thought of or are confused how or why anyone would do that. They’ll do something that you couldn’t foresee any human every doing and there will be some bug there you didn’t Squish because why would you even have looked there…? So if you drop this thing and people are using it in unanticipated ways and so you change it to cater to that, they’re just going to do it again.
To the example of the picture- you have a park. You build a path. People cut across the grass instead. You build a path through the grass. People cut across the grass between the paths to get from path A to B midway through. You add a path… keep that up and you won’t have a park, just a giant concrete square. You give them a path, if you take it away and say: “ok, you wanted walk on the left so we removed the path on the right and made one on the left..” people will complain they can’t use the right. Leave both open people will complain there isn’t enough grass or it’s too confusing to have to pick which path to take.
So there are all these factors that weight in- and if we have a very good corporate culture and there aren’t politics or the blame game and we remove these other factors and we just take a simple stance that we want to build the best product and the best user experience and we say we can make everyone or most people happy the same way etc- well….
Resources. Not money. Different thing. If you’re walking in the deep isolated and remote desert and dehydrated and someone is selling the only water anywhere in the desert for $100 a glass the only reason not to buy is money. That sucks, but if there is NO ONE selling water and NO water- that sucks more because sometimes you just can’t realistically get what you need with money. If the water is $100 a glass but you only have $20- that’s the same as there being no water (if you can’t steal etc..)
So this company might have 300+ workers but have 4-10 people who can work on software projects. They need lots of warehouse workers and they maybe need engineers to design product the software runs, sakes people, marketing, Human Resources, customer support and tech support, etc etc.
so that team- whatever the size- that’s who they have and they may not be able to afford a larger team, not that they don’t want to pay- they can’t afford it or budget for it.
Ok. So they’re making some techno gadget like an app enabled Wi-Fi spoon or whatever crap people buy. It’s sold at Target and Best Buy and online etc. so this 300 person company might have 100,000 customers.
Bugs with the product are being reported and you need developers and QA etc. to fix those bugs. Customers, leadership, sales, product or marketing teams are asking for improvements, new features, UI changes etc.
another company has entered the Wi-Fi spoon market and they are adding features and such and to be competitive
You have to decide wether you want to focus on adding similar features so your product compares well on the box to consumers reading what it can do, or focus on quality and reliability instead of features.
Oh- and there is a new Wi-Fi standard coming in 12 months you’ll need to make a software change so that all current and future models can connect to devices on the new standards and the biggest trade magazine is alerting everyone that “Java.snusnu” which you and most other companies use in your software- has a critical security flaw and hackers can steal user data if it isn’t patched. Oops. Forgot to mention. Your spoon is 3 years old- so you’re also working on spoon 2.0- the next Gen product that you’ll need to stay competitive in the future and you want to beat your rivals to market AND make it in time for the big spoon buying season.
Ok- so what’s more important? Do you focus on your existing customers and the spoon 1.0 experience or do you put your resources into the future
and try to make spoon 2.0 everything it can be and make the big deadline? But… if you focus on spoon 1.0- what do you do? Add the feature marketing wants? Add the feature product wants? Fix some of those bugs? What about that security vulnerability? They can get used data but only about their spoon using habits- but if people find out you knew and didn’t fix it they still may lose confidence in your company or be upset… but it won’t matter much if your spoons can’t connect to network because you didn’t upgrade the Wi-Fi for the new standard right?
You only have X developers/programmers and X QA and so forth- and oh yeah. Customer support escalated problems they can’t solve to your tech teams so you also need to factor in the time and people needed to continue to support your customer team…
So often times it’s less precise to say “money” and more precise to say “resources.” You have many areas on the current product that need maintenance, then areas for improvement, then you have future product and plans, deadlines and priorities and brand image and competitiveness and such… but you don’t have unlimited resources to put time and attention and such to each and every one at once. So you have to make decisions on where to put your resources for the best business decisions or best choices.
So let’s say that you spend 12 months making the program and UI and you launch and everyone is using it in a way you didn’t mean. But for 12 months you’ve had most of your resources on that project building it and have been doing bare minimum on other projects and other areas. Do you open it back up and spend another 3 months for all your resources to redo the UI, or do you move on to one of the differed projects or tasks that has been waiting 12 months for resources and then work your way back around to this program when you’ve worked through the backlog and caught up to where you planned to be? And if it takes 6-12 months to get through all the other projects and have time to redo the UI, if you look into it… are people complaining? Do you NEED to redo it? After 6-13 months your users may be used to it and like it as it is even.
So we have to look at data and do some thinking. How many people are reporting dissatisfaction with how it is or asking for changes? How vocal are they? What is the “pain level” in other words. Between finding the paint color in the living room to be not your taste and having a massive infestation of termites or a toilet that shoots poop out when you flush- the later items probably would be priorities over the paint. If you live with the paint long enough you may even be Meh about it. “We can finally do the paint!”
“I always disliked it so yay!”
“Wait… but we could also change the drawer pulls in the kitchen instead..”
“Ok. Let’s do that. I hate those more…”
So many reasons you might not “fix” a UI/UX issue. Lastly- sometimes there just isn’t a better way. You know something isn’t great but the nature of things like technology or the type of information needing shown etc- there just isn’t a better way to do it and the less than great way you have is about as good as it can get. In those cases people might use the program whatever way makes it easier for them- and you go with it because there isn’t any objective better way so you let people find their subjective best and move on.
and let’s say that 9/10 users by volume have a certain use case for a program. So you might feel pretty safe to change your interface. Well….maybe not so safe.
That impacts whose budget pays the fix and who gets fired or loses bonuses or gets a “black eye” and is undermined etc.
but often times IT builds to user spec based on their requests and policies- so the UI design has to reflect those policies.
That’s where UI/UX get sticky. You can “lock down” a program. This is common in point of sale systems or warehouse systems and in jobs done by “gig contractors” but you see it other places. You design a very simple interface that can ONLY be used a specific way and has almost no flexibility.
In the end though- your end user is smarter and dumber than you can ever imagine. Outside of critical type projects- there isn’t going to generally be this period where a dedicated team of the best and brightest developers and testers spend 3 years beating the software down and finding every loop hole and optimizing everything. For most software that makes no sense. It isn’t that serious and delaying it and adding cost to treat it like your app that lets you preview AR hair cuts is the control unit for a Martian habitat or a hypersonic airliner is daffy. You do as much research and thinking and testing as suits you and then you rip it.
Resources. Not money. Different thing. If you’re walking in the deep isolated and remote desert and dehydrated and someone is selling the only water anywhere in the desert for $100 a glass the only reason not to buy is money. That sucks, but if there is NO ONE selling water and NO water- that sucks more because sometimes you just can’t realistically get what you need with money. If the water is $100 a glass but you only have $20- that’s the same as there being no water (if you can’t steal etc..)
so that team- whatever the size- that’s who they have and they may not be able to afford a larger team, not that they don’t want to pay- they can’t afford it or budget for it.
Ok. So they’re making some techno gadget like an app enabled Wi-Fi spoon or whatever crap people buy. It’s sold at Target and Best Buy and online etc. so this 300 person company might have 100,000 customers.
Bugs with the product are being reported and you need developers and QA etc. to fix those bugs. Customers, leadership, sales, product or marketing teams are asking for improvements, new features, UI changes etc.
another company has entered the Wi-Fi spoon market and they are adding features and such and to be competitive
Oh- and there is a new Wi-Fi standard coming in 12 months you’ll need to make a software change so that all current and future models can connect to devices on the new standards and the biggest trade magazine is alerting everyone that “Java.snusnu” which you and most other companies use in your software- has a critical security flaw and hackers can steal user data if it isn’t patched. Oops. Forgot to mention. Your spoon is 3 years old- so you’re also working on spoon 2.0- the next Gen product that you’ll need to stay competitive in the future and you want to beat your rivals to market AND make it in time for the big spoon buying season.
Ok- so what’s more important? Do you focus on your existing customers and the spoon 1.0 experience or do you put your resources into the future
You only have X developers/programmers and X QA and so forth- and oh yeah. Customer support escalated problems they can’t solve to your tech teams so you also need to factor in the time and people needed to continue to support your customer team…
“I always disliked it so yay!”
“Wait… but we could also change the drawer pulls in the kitchen instead..”
“Ok. Let’s do that. I hate those more…”