Homework : help with web UX guidelines

Questions
,
#1

Anyone got a oven-ready “guide” to ensure your web app works slick? Basically a do my homework for me question, since I’m quite fresh at web apps. A bit of background, the application is actually at least 2 apps, but both live underneath Vue framework, and were built by 3 different teams. I have a chance to workflow some of the navigation and UI styling that is already in place. Were can I start?

  • Submit buttons on all forms are disabled until the form is ready/filled sufficiently
  • Tab key moves to next field
  • Enter key defaults to the submit button
  • Make all controls and forms have unique ID’s using a pretty naming scheme to make Selenium less painful (currently I am fixing these one at a time)
  • Make sure every place the user will see an error that we use “red” text next to the error area in question
  • Make sure the “confirm” dialogs only interrupt the workflow and only appear when the user is about to do something irreversible
  • Don’t ever show dialogs with just an “OK, was done successfully” when the server completes an action, instead only stop the flow when errors occur.
  • Button shape standard?
  • Spinner and progress consistency standard?

etc. Or am I stating the obvious, or rather simply missing a few key ones. Also keen to slip a few “accessibility” guidance point in here too, but I need to run a trial using Lighthouse for chrome to see what it flushes out most on.

Thanks in advance, homework due date is probably 2 weeks away.

1 Like
#2

Bumping this, surprised more UX specialty folk have not pushed in, been finding this a useful place to get tips, for example this discussion on drop-lists is fascinating https://uxdesign.cc/ui-cheat-sheet-dropdown-field-a30025c0f432

It recommends 4 items to be visible in drop-lists, but I prefer more like having around 8 items visible in a list because “menus” are often that deep anyway.

1 Like
#3

Hiya, I’ve got a talk on a guide to usability that I did for ministry of testing. I can give you a summary if you don’t have time to watch it. It sounds like you’re on the right track with what you are doing though.

1 Like
#4

The reason you should have 4 is down to memorability and learning. I would consider reducing it from 8.

#5

I am watching the DOJO videos binge style lately, I’ll have to search for your talk. This one ? A Guide to Usability - Melissa Fisher | MoT

#6

Yup that’s it! I’ll digest what you’ve put above some more and see if there’s any other suggestions I can provide.

1 Like
#7

I’m talking about a drop-list for search results, much like a google search shows, where the list populates as you type. Google show 9 or 10 hits, which in reality is a bit OTT, most of us ignore the bottom ones.

Imagine a list of like 10000 computers, so the live filter needs to show you the top relevant matches. But I think I was silly to ask for a deeper list, because only power users want everything on screen at one time, so I’m going to change my guidance to just 4 or 5 visible items.

1 Like
#8

In summary though these buckets are good, Navigation, Feedback, Performance, Memorability, Learnability, Affordances and Error Messages.

Styling and consistency is another good one that you have stated

1 Like
#9

Thanks yeah, looking forward to the DOJO session watching… grabs some coffee. I really wanted to get a guide together for my team that helps us to get structure together quickly and not fuss over artwork.
When the “artwork” person watches in late in the day usually and asks us to change the colours, icons and shapes and so on, that needs to be quick and easy stylesheet work. So long as colours chosen are safe, and our plans to work well in dark mode (every website needs a dark mode plan in my opinion) are not scuppered, they can change CSS happily.

That is a better list of buckets than the draft I posted on the work wiki yesterday, I’m stealing those. You are the boss @melissafisher !

1 Like
#10

Can you message me your email and I’ll dig out some guidelines to send over? I just remembered I created some awhile ago.

^^ scrap that, i’ll message you via MoT :slight_smile:

1 Like
#11

This is considered bad form (excuse the pun). Countless usability studies have shown that disabling submit buttons puts the onus on users to figure out why they can’t proceed and often they assume the page is broken. Better to use a permissive button and draw the user’s attention to the missing or erroneous input via a modal.

1 Like
#12

Well spotted, I’ll focus on this one in my guide to the team. I want us to do this by using an accent on fields that are mandatory , in some guides this is by placing a * next to the needed field, but in some UX, this is by adding a extra bold border to mandatory fields and controls. This gets tricky to show well with radio buttons , hence the need to go bold for mandatory inputs feels better?

Keeping the amount of stuff on a page small gets super important when you do this, because if a form is large, and a user clicks the button, the form must never scroll back to the first input that they missed. Especially if they are using your app on a phone, Bleeeegh. Flashing a missing input is an option, and this is kind of why I asked about this as a “home work question”. I’m a developer-turned-tester and so all this UX stuff is totally overwhelming, and threatens to almost eat into my real bug-detection time. Very good points to bring in, thanks @gingerbbm

#13

I assume you’re after only low-level UX type stuff and not higher-level UX stuff. By that, I mean the UX stuff that’s closest to UI design, rather than the more abstract stuff. So you’re not testing how well the system matches up with the user’s mental models and goals, it doesn’t matter about how the tool fits in with a bigger flow (as in customer journey mapping) etc.

Sorry if this is already covered by what e.g. Melissa says in her talk (which I haven’t seen). On top of what people have already said here, I would add minimising user work. So, if there is only one option for a parameter (when sometimes there can be > 1), don’t force the user to pick that one thing from a list. Instead, pick it for them. And, more generally, if there are sensible defaults you should use them. If you happen to know what the majority of users will want to pick, consider picking those (while still making it easy to change away from the defaults).

Make it easy for the user to change their mind. Make it easy for the user to know where they are, both in a static sense (I’m on page X, which is part of section Y, and from here I can easily go to related places A, B and C), but also in a dynamic sense (I’m on step 3 of 5 in some process). When there is a multi-page process, to borrow programming terms, you want loose coupling between pages and high cohesion within pages. I.e. the break between one page and the next should correspond to stages in the problem as defined by the user rather than falling in the middle of one mental chunk (so the user doesn’t get confused why they have to click Next / Submit), and everything on a page should feel like it belongs with everything else on that page (so the user isn’t confused when searching for stuff on the page).

1 Like
#14

The asterisk is the de-facto standard for signifying a mandatory field, although personally I think it’s ugly and meaningless if you’ve never seen the pattern before. In my practice I’ve found that it’s usually the optional fields in a form that are fewer in number, so better to call those out (with an “(optional)” in the label) rather than scattergun asterisks.

I don’t think I’ve ever seen the use of a thicker border to denote mandatory fields, or if I have I didn’t twig the significance!

In all the above I’m talking about default form state, not error states.

The gov.uk website is a great example of forms done well: they use very brief steps and don’t mind about numerous steps in a flow. Try the passport application, for instance. This makes handling of errors easier, but they don’t scrimp on that interaction design either. It’s inspirational.

1 Like
#15

Will definitely have a run through the .gov.uk site for good examples, I hate the asterisks way of denoting mandatory, and saw in one place someone using colour to denote mandatory fields. But since I don’t think colour is a good way of doing that I was guessing at going with bold borders instead, but

(optional)

Is just so much neater, and friendlier, friendly tone is important I believe.

@bobs Yes Melissa does touch on “minimising” work for users, but not on the pick lists and defaults thing. I’m probably going to try going through and test a lot of this manually I guess.
Wizards and pages are hard to get right, these days designs all tend towards as little as possible on each page as possible. So that’s another goal to aspire to. This idea of loose coupling and high cohesiveness sounds like something to grasp and understand at a higher level as I progress more on the journey to get this to work. Want to get that right early to prevent having to rewrite flows.

#16

Sorry not to explain myself better, and Melissa is the expert here so please go with what she says :slight_smile: .

Cohesion and coupling are good tools for working out where to draw boundaries between lumps of code e.g. methods, packages, micro-services. Cohesion refers to what’s inside a single lump of code. Coupling refers to how one lump relates to other lumps.

If a method is a dumping ground for assorted stuff that doesn’t belong together, then that method has low cohesion. It doesn’t have a single purpose or identity, which makes it harder to understand, gives it more reasons to change (due to any of its many purposes changing) etc. Low cohesion suggests that the method should be split up into bits, with each bit having a stronger identity and one purpose i.e. higher cohesion.

Coupling is how much is one method tied to others. If the inner details of one method changing forces another method to change, then they are tightly coupled. It’s better if a method depends on only the interface of other methods - as long as the interfaces don’t change, then the first method shouldn’t have to change.

I was using them as metaphors to describe wizards etc. One problem is that one stage of a wizard is a random assortment of fields, with little that ties them together. The user will find it hard to understand the purpose of this stage. Can you put a single title on the page that represents everything on the page? I was calling this low cohesion.

Another problem is that a user fills in thing A on one screen, clicks Next, and tries to fill in thing B on the next page. But A and B are very related, so seeing the answer to A might help with the answer to B. Or the user might want to change their answer to A based on the options available for B etc. I was calling this a tight coupling between A and B / the two pages. It suggests that A and B should be on the same page, or something else done to address how strongly related A and B are.

1 Like
#17

Just to weigh in on this: colour alone is never a good way to denote anything in the UI for reasons of accessibility. As soon as a colourblind person comes along, all bets are off. That’s why error messages are often in red but also have some kind of accompanying iconography. We call this approach redundancy.

2 Likes
#18

Yes @gingerbbm redundancy. I saw that used in something recently and it looked cute, but now it makes much more sense to use icons as well as colour.

@bobs As for experts, well I suspect my fear is that you only become an expert at what your customers are doing when you have metrics to support and real observations to support design changes. Will have to run a few in-house sessions with non-engineers in the company to find out what the user experience really works out or not. I think when it comes to UI, the cohesion of the code can sometimes prevent code re-use for UI flows that are similar enough to share code or at least to share pattern.
I don’t think that code coupling problems map into the user experience directly, but it has a chance of doing so. And as such I’m more keen to jump to keeping the UI as low on coupling as possible while making it look cohesive to the user really. Only user feedback is going to tell me if I’m driving in the right direction.

1 Like
#19

I’ve just looked at our product, at a wizard with 3 stages and each stage has about a dozen fields. (It’s an editor for admin users, rather than something that a casual user might use only rarely, so the many things per page isn’t so bad.)

I’ve noticed that related things are grouped together with a heading and sections within the page are separated with horizontal lines. The various sections make sense to go together (although they could in theory be split into different pages).

I don’t think it’s often the case that someone creates a new page or entire flow with bad cohesion or coupling, but it can be an instance of ‘death by a thousand cuts’. People have repeatedly added ‘just’ one more field here and there, without reviewing how the whole thing works. E.g. new fields could be added to the bottom of the page because that’s easiest, rather than existing things shuffled about to give a proper home for the new thing.

Also, my point wasn’t actually about the code - it’s using code properties as a metaphor for UX properties. I’m aware that this is moving up the levels of UX away from important details such as how mandatory / optional is communicated. The key thing is the user, their needs, their mental models etc. Does the UX map to those. Anything else is just a means to an end. So (as you say) to know if you’re doing it right, you need to talk to users, ask them what they’re trying to do, watch them use the product to see where it does and doesn’t fit well etc.

1 Like