The problem with GroupCollect’s announcement form (perhaps you can redesign it?)


GroupCollect helps tour operators organise trips for groups.

Their biggest market is school trips.

The form below allows tour operators to send announcements to parents to chase late payment or tell them about a change to the itinerary:

On the face of it, the form looks straightforward:

  1. The trip name, date and location appears at the top for context
  2. The h1 heading clearly explains the purpose of the form
  3. The fields look like fields (with clear borders all around)
  4. The submit button is aligned to the left edge of the last input (where users expect to find it)

So that’s good.

But as you look more closely things unravel.

For example, take a look at the radio buttons for “Communication method”:

There are three main issues with this field:

Issue #1: The radio buttons use ticks for the selected state

Radio buttons and checkboxes are different.

Only one radio button can be selected and that’s indicated with a filled dot.

Multiple checkboxes can be selected and that’s indicated with a tick.

This is not just conventionally the right thing to do - it gives users the ability to quickly understand the difference between the two controls.

As it is, users might think that they can select multiple options. And when they’re unable to, it’ll be frustrating and confusing.

Issue #2: The radio buttons are laid out horizontally

This is problematic because:

  1. They’re harder to scan and compare
  2. Some of the options are more likely to be missed, especially for users who zoom in with a screen magnifier
  3. Even if the user realises they need to pan across, it‘s more effort to do so
  4. You can’t lay them out like this on small screens, which unnecessarily makes the experience inconsistent across screen sizes

Laying them out vertically addresses these issues.

Issue #3: The question asks for two answers at the same time

The question doesn’t just ask about how to contact people, it also asks about who to contact.

The options are also an incomplete mix of the two. For example, you can email and text account holders but you can only text passengers.

It gets more confusing when you select “Text passengers” because a line suddenly appears below to say:

“Non travelling trip leaders can only receive email notifications.”

The first thing I’d do is split the question into two because:

Two easy questions are quicker to fill out than one hard question.

But to design this properly, we need to understand the domain. And right now, that’s unclear.

  • What actually is an account holder? The person who booked? A parent? A teacher?
  • Can an account holder also be a passenger?
  • Is “passenger” the right word to use?

And given we’ve only discussed one of the fields in the form, there’s a lot more to consider.

I don’t have time to do that.

But maybe you do:

GroupCollect is looking for a senior designer to work remotely on this form - and the rest of the product.

I've spoken to the guys at GroupCollect - they know this stuff is hard and care about doing it right, which is rare in our industry.

So if you’re looking for a new role and think you could help, click the link below:

https://groupcollect.notion.site/Product-Designer-at-GroupCollect-2cd6470adf8c80708c90cbe527aa53cd

Cheers,
Adam

p.s. if you end up getting the role, let me know. I'd love to hear how the redesign went.

Design tips to help you create products that are ridiculously simple and accessible to use

Join 10,000+ designers, content designers and engineers who get my free weekly newsletter with evidence-based design tips (in 3 minutes or less). Mostly forms UX, but not always.

Read more from Design tips to help you create products that are ridiculously simple and accessible to use
Opening a file dialog with some files disabled and the user trying to click on them.

Last week I wrote about the problem with using the accept attribute for uploading files. As a quick reminder: When you use accept to specify which file types will be allowed like this: <input type="file" accept="image/jpeg,image/png"> …the dialog will disable invalid types like this: This is bad because: The disabled files are greyed out making them hard to read Some users won’t notice the subtle greyed out styling - so will try clicking the invalid files anyway And this will make the...

Me holding a sign saying, "Error hiding is not error prevention."

Last week I posted about why the accept attribute on file inputs is bad UX. The accept attribute lets you specify which file types an input will accept. For example, if users need to upload a receipt, you can do this: <input type="file" accept="image/jpeg,image/png,application/pdf"> That means users can only select those file types. All other files are disabled: This sounds good because it stops users from picking an invalid type before they submit - which would then cause an error. But as I...

Me holding a sign saying, "Go from good UX to great UX."

Last week I listened to episode 10 of the Complimentary podcast, “Taking Interaction Design from Good to Great”. Anthony Hobday, one of the hosts, gave an example of applying for a driving license on GOV.UK. He said that instead of asking you to upload a photo, the form said: “We notice that you’ve already got a passport with us. Do you want us to use your passport photo for your driver’s license?” You just click ‘Yes’ and move on. Anthony said this design is “next level”. I agree. The best...