|
UI/UX "designing" is arcane magic.
The following rules apply:
1. Recognize that you haven't a clue what the user actually wants. Learn what their standard processes are (when things go smoothly) and learn what they do when things don't go smoothly. The UI/UX must handle the latter.
2. Recognize that the user doesn't have a clue either, because they are stuck in their old (often paper, yes still in this age) workflows and want the UI/UX to replicate their existing workflows which is so wrong for a UI.
3. Identify the vital (buzzword: "mission critical") information that must be present
4. Research how the users actually need that information visualized. Managers want pretty graphs, the clerk wants numbers and text.
5. Don't hide things behind context menus or other right-click processes. People should be able to see what their options are. Read the thread below about the context menu in W11.
6. Anticipate stupidity. We had a customer call customer support to ask "where is the 'any' key" just a couple days ago because of the message "Press any key to continue." I kid you not.
7. A UX needs to accommodate helping the user, step by step, go through a workflow, as well as the expert user that doesn't need hand-holding.
8. A UI needs to accommodate nuances in the data, including no data, large data, small and large values (particularly when dealing with text), formatting, etc.
9. Everything, and I mean EVERYTHING, should be validated on the front-end with informative messages as to why the "inputs" are wrong and how to fix them.
10. Don't write the application in VB. I can tell a VB application instantly because VB programmers love to make their UI look like a Disneyland flowerbed.
11. Bonus: Make the UI/UX as configurable with metadata as possible. Ideally consider that the goal is that each user can customize the UI/UX for their individual skill level and needs.
That should get you started. 
|
|
|
|
|
Sounds a lot like the discussion I had with her before posting.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
No no no number 11 is a horror of the first degree!
Bild in a configurable UI
User 1 changes every possible option.
User 1 quits/gets promoted/sacked or just moves on
User 2 bitches to you the developer that nothing matches the doco
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Keep a "Reset UI" functionality at hand at all times. Some IDEs have it, gods bless them.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Good answer and I largely agree, but have a few differences in opinion. First, who are you designing for? "Expert Systems" are a different breed than general public. It modifies some of your points if you are designing expert systems.
For example:
#2 The UI/UX is wrapped around the process/workflow. We may not like it, and may be able to create a better UX, but often the processes are a requirement of the design. There's a chance you can improve workflows, but not unusual to be stuck with it.
#5 Again, context menus can be very effective in a business system. The only need is to know what should be in them and also have an alternative available.
#7 This is highly variable depending on the design case. I've sat next to users having to click through seven screens, due to a forced workflow, for something that should have been one-click.
#10 I'd venture that is experience rather than IDE choice. I can create bad UIs in any language, lol. Good ones as well.
I'd also tack on "don't do it because you can". It might be more of a web UI thing, but I've seen some very impractical uses of technology that take away from the UX. And work both top down and bottom up unless you are starting from scratch. Often, the data IS the data, period.
|
|
|
|
|
"Press any key" was dangerous, and now even more dangerous. Even with power keys died off from the keyboards.
Users love corner keys like ctrl, shift, esc, to name a few. Then the local menu key. Then the F keys. Now they are often worse than F keys on new laptops.
|
|
|
|
|
Somehow, I often end up with customers who say to me, "I won't know what I want until I see it." How the heck are you supposed to deal with that? Well, there are many options one could take. When possible I choose the option where I make everything configurable and adjust it until they are happy or until I am tired of it, which ever comes first. Sometimes I tire quickly and tell the customer, "here you go - you can do what ever you want with it," and let them deal with it. They usually get much more accommodating when I tell them to do it themself.
That approach is often not an available option and when it isn't I find it is best to make things a flexible as you can possibly make them so you make changes quickly. That is, if you are so inclined. Sometimes I have no patience and just say, "here it is and you are going to like it. Or not. Regardless, here it is."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Good, old Itsy Bitsy Machines had the opposite problem a generation ago:
They had developed a super-great UI prototyping system (written in APL!). The salesman could sit in a dialog with a customer, and modify the UI there, on the spot, to the customer's wishes, and the customer could take the UI prototype home to present to his co-workers/co-users. Setting up stub functions to deliver/accept data was trivial: The prototype could display not just static screen dumps, but a lot of dynamic behavior as well.
The problem was that the prototypes were so complete that the customer said: "This is great. I'll take it!", not fully realizing that it was a mock-up, of nothing like production quality, and with functional stubs. So the IBM salespeople had to learn to make incomplete mock-ups, to keep customers from running away with the prototype, not wanting to pay for development of the production version.
My approach to your problem: UI development is not me telling a customer how I think that his problem can be solved. It is him telling me how he sees his problem. Not the solution, but the problem. What does he see as elements of the problem, how they relate. How his work procedures are. Have him teach me his professional terminology. I write down my understanding of everything he explains to me, and let him correct and augment my notes.
Then I go home and make a very first UI prototype, modeled after the customer's concepts, established terminology and work methods - obviously following UI platform standards. Before the customer gets to try the prototype, I can explain to him - on a whiteboard, not in computer terms - the way I have been thinking to solve his problem, how I group data, what operations should be provided and which effect they will have on different data groups. Maybe the user has so many objections that I have to go back and change the conceptual solution before showing any UI prototype makes sense. When the customer has agreed to a conceptual solution outline, the feedback on a UI prototype is usually quite productive.
My impression is that software developers should spend far more time, especially in the early project phases, listening to the customer's view on the problem and possible solutions, and certainly not just for politeness, but in order to get to know the problem domain, understand the customer's viewpoint. We are much more eager to focus on our domain, rather than the problem domain. Start by listening. Agree on a conceptual problem solution. Then design a UI according to that.
|
|
|
|
|
This is what I started on, more or less:
https://www.amazon.ca/About-Face-Essentials-Interaction-Design/dp/1118766571
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Programming & UX are two different topics. My company works with a design bureau right now. The guys I'm talking to (I'm the programmer in this equation) got literally no idea about anything programming (except HTML, but that's not a programming language, they don't even work in it, merely export in it) but they're really great at what they're doing, namely UX design.
So are you talking about programming or about UX design?
|
|
|
|
|
That sounds awkward to me. You really need an SA that can look at both sides. In many cases, the data and needed workflows have to drive the UI to create the UX. My preference is bottom up while keeping the top-down in my thoughts at all times. Then turn it over to the make pretty group and tell them if they touch the code flow, I'll break their fingers. Not really of course, but work together to come up with the best UX possible given the required criteria. It's an agile give and take through the entire development track.
|
|
|
|
|
Very much true, the work-/dataflow has to drive the UI. That's why we're designing the UX according to the workflow while I (the dev) sit in the meeting, making sure my backend fulfills the use case requirements (work-/dataflow) and answer questions in the likes of "can we do that". When you're designing for end-users, that's a hella great methodic.
|
|
|
|
|
There is a book, not specifically about UI/UX or even programming in general, but it is about design. What makes a good design good? I think everyone who designs anything for human use should read it: The Design Of Everyday Things
After that, everything is just a smop.
|
|
|
|
|
Hi. I think you can start with Google courses. It helps you to understand every basic subject and maybe helps you to improve to midlevel one. Then you can recognize who is right by yourself.
|
|
|
|
|
As always happens when companies get too big or too successful for their own good, and employ too many people looking to justify their own existence Microsoft's products now insult and harass their users.
This is the natural evolution of a company. I accept that Microsoft is going to suck. They are just at that point in their lifecycle when they're the drunk uncle that nobody wants at the wedding.
All that said, it used to take me two clicks to open a folder with VS Code under Windows 10.
Now it takes me 3, because somebody stupid and nevertheless employed thought it would a great idea to hide all of the context menu additions I explicitly installed behind a "show all options" menu.
How do I turn off this "feature?"
To err is human. Fortune favors the monsters.
|
|
|
|
|
|
|
So coders will start using the new way Real Soon Now... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
As I do with anything new from MS I'll delay updating as long as possible. I have tried it on a non work box and I didn't like what I saw.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
I delayed it, but then i nuked something on my old install that prevented me from programming raspberry pi picos.
At all on my system.
Seriously.
Zadig installed drivers that then went into limbo and therefore could not be uninstalled and were preventing the proper handshaking when you plugged the boards in via USB.
So since i had to do a fresh install anyway I figured I may as well go all the way and upgrade. Saves me doing a fresh install later.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: As always happens when companies get too big or too successful
... or try to imitate what Apple did 10 years ago...
|
|
|
|
|
My observation: as companies approach the size of the government (pick a large one), they achieve the same efficiency.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
I'd forgotten this one. It was my biggest  after switching to Windows 11.
|
|
|
|
|
Still remember the ribbon. Just a fancy toolbar, and it is not like the menu has disappeared in the rest of the world. Even see menus used in web pages. And still have that miserable "Modify Style" that uses that miserable Format button at the bottom. Has Microsoft not heard of the tab control. Office applications have had minimal evolution, and Microsoft has not fixed the ability to program office applications. Outlook has changed very little from 1995. What exactly has Microsoft been doing for the last 20 years. Have to say that the Visual Studio team has made enhancements but why did it take so long to get to 64bit? And I understand that SQL server is good also. But I go and use control-F and it does not work the same, and control + and Control - do not work like in the browsers. Guess Microsoft never learns how important UX is and consistency between applications. Microsoft seems to already be very much like IBM.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
