Yeah, companies would get entire studies done to determine what sort of UI should be used, for what reasons, etc.
A few years ago I was working at a company where they still use software that originated in the 90s. This is in an industrial setting where all sorts of information is displayed to operators on clusters of screens. What amazed me the most is when I came across a binder which contained the 5th revision of what effectively did describe the entire UI language of that application. In detail it told about all the elements, where they should be used, where they shouldn't be used. Not only that, for each decision it had citations pointing to various other research by universities but also Microsoft and other software companies.
Basically think the material design website: https://m3.material.io/components but then on steroids. Now, this was in a highly critical environment where it is critical that operators cannot get confused. But it is telling that when I was there, it seems that most people had forgotten about that document and the design lessons gained over time. So at some point they needed a new bit of functionality, and it got a random icon, no justification and of course during testing it became very clear that it stood out for all the wrong reasons.
It does indeed look like there has been a shift in regard to how UI is thought about. From where I am standing, the focus these days on that it needs to "feel right" first. Where in the early 2000s the joke was that you shouldn't have designers make interfaces, exemplified by very pretty elaborate flash driven websites from those designs that looked pretty but a nightmare to navigate. It seems to me that in the modern era they have gained more ground.
Which in itself wouldn't be that bad. If they also had not thrown out all the
Oh man, it has been a while since I have seen it. But yeah, I think that is at least one of the documents (or similar) that was cited as part of the background research for the document I mentioned.
What's telling is that this is the guide made available to software developers looking to create software for Windows. So this isn't some internal document either.
This guide is intended for those who are designing and developing Windows-based software. It may also be appropriate for those interested in a better understanding of the Windows environment and the human-computer interface principles it supports.
This section in particular is interesting:
# How to Apply the Guidelines
This guide promotes visual and functional consistency within and across the Windows operating system. Although following these guidelines is encouraged, you are free to adopt the guidelines that best suit your software.
However, you and your customers will benefit if, by following these guidelines, you enable users to transfer their skills and experience from one task to the next and to learn new tasks easily. The datacentered design environment begins to break down the lines between traditional application domains.
Inconsistencies in the interface become more obvious and more distracting to users. Conversely, adhering to the design guidelines does not guarantee usability. The guidelines are valuable tools, but they must be combined with other factors as part of an effective software design process, such factors as application of design principles, task analysis, prototyping, and usability evaluation.
You may extend these guidelines, provided that you do so in the spirit of the principles on which they are based, and maintain a reasonable level of consistency with the visual and behavioral aspects of the Windows interface. In general, avoid adding new elements or behaviors unless the interface does not otherwise support them. More importantly, avoid changing an existing behavior for common elements. A user builds up expectations about the workings of an interface
We are talking about a document that is over 300 pages long here. I suppose that if I had to let the cynic in me answer the question about what happened, the answer will probably be costs.
Comments
Yeah, companies would get entire studies done to determine what sort of UI should be used, for what reasons, etc.
A few years ago I was working at a company where they still use software that originated in the 90s. This is in an industrial setting where all sorts of information is displayed to operators on clusters of screens. What amazed me the most is when I came across a binder which contained the 5th revision of what effectively did describe the entire UI language of that application. In detail it told about all the elements, where they should be used, where they shouldn't be used. Not only that, for each decision it had citations pointing to various other research by universities but also Microsoft and other software companies.
Basically think the material design website: https://m3.material.io/components but then on steroids. Now, this was in a highly critical environment where it is critical that operators cannot get confused. But it is telling that when I was there, it seems that most people had forgotten about that document and the design lessons gained over time. So at some point they needed a new bit of functionality, and it got a random icon, no justification and of course during testing it became very clear that it stood out for all the wrong reasons.
It does indeed look like there has been a shift in regard to how UI is thought about. From where I am standing, the focus these days on that it needs to "feel right" first. Where in the early 2000s the joke was that you shouldn't have designers make interfaces, exemplified by very pretty elaborate flash driven websites from those designs that looked pretty but a nightmare to navigate. It seems to me that in the modern era they have gained more ground.
Which in itself wouldn't be that bad. If they also had not thrown out all the
Not sure if you've seen this already but you might like it: https://ics.uci.edu/~kobsa/courses/ICS104/course-notes/Micro...
Oh man, it has been a while since I have seen it. But yeah, I think that is at least one of the documents (or similar) that was cited as part of the background research for the document I mentioned.
What's telling is that this is the guide made available to software developers looking to create software for Windows. So this isn't some internal document either.
This section in particular is interesting:
We are talking about a document that is over 300 pages long here. I suppose that if I had to let the cynic in me answer the question about what happened, the answer will probably be costs.