Last week, I wrote an article about “one thing per page”.

In short, I said that instead of putting multiple fields on a page, you should put each field on its own page:

Tom, one of my new subscribers, messaged me:

“I read your article about one thing per page - doesn’t your sign up form have two fields?”

Here’s the form he was referring to:

He’s right - it does have two things on a page.

But like I said to Tom:

It’s an exception to the rule.

You could argue that I don’t even need to ask for their first name, but I want to have a personal relationship with my subscribers to the extent that’s possible to do.

So I added the first name field.

Tom responded:

“You could make it an optional question after sign-up. You could run an experiment - I’d be surprised if it didn’t increase sign-ups.”

I get it - if I saw someone else’s form with this, I’d be the first one to challenge the design.

But in this case, I have two reasons to justify the decision:

Reason #1: I want quality subscribers over a lot of subscribers

I’d rather have fewer subscribers who are committed enough to share their name than lots of anonymous subscribers who never engage.

It’s the same principle we used when creating the “Becoming a teacher” service - we didn’t design the service to maximise applications. We designed it to attract committed, qualified candidates.

That meant keeping questions in that would filter people out.

Reason #2: I have tech constraints

I don’t have the tech stack to do multi-step forms or run A/B tests.

Setting that up would be a lot of effort for potentially marginal gains that I don’t even care about. Even if the experiment showed more sign-ups without the first name field, that doesn’t mean better quality sign-ups.

So yeah, I could totally run that experiment. But like everyone else in the world, I don’t have endless time.

Like my wife keeps saying to me, I need to prioritise other things.

Specifically, she keeps telling me to promote my other course because I rarely do that.

On that note:

I have a course called the GOV.UK Prototype Kit Bootcamp.

Most designers use Figma. But Figma has a lot of downsides, the main one being:

You can’t test real user interactions.

As a result, you get incomplete and untrustworthy insights to base your decisions on.

That’s bad.

And that’s why GDS created the GOV.UK Prototype Kit.

It’s design tool that allows you to quickly make interactive, accessible and realistic prototypes of GOV.UK services that work in the browser.

Unlike Figma, it allows you to test real user interactions such as:

• Filling out a form
• Using a screen reader
• Dragging and dropping files
• Switching from portrait to landscape

The only problem with the Prototype Kit is that most designers don’t know how to use it. They don’t know how to code.

So they get stuck, fed up and stressed. Because instead of just designing what you want to design, you spend all your time working out how to use the Prototype Kit.

I get it.

When I first started using the Prototype Kit, I faced the same struggles.

But over the last 9 years, I’ve used the Prototype Kit to design 20+ different products used by citizens, specialists and internal staff who use enterprise caseworking systems.

And I’ve distilled down everything I’ve learnt into a self paced video course. I’ve designed each lesson so that it will be like jumping on a call with me.

You’ll see how I create:

• multi-step journeys with branching questions and exit pages
• task lists that handle partially complete tasks and file uploading
• caseworking systems with search, filter and pagination

So if you’d like to be able to quickly create realistic HTML prototypes, gain reliable insights from research, and confidently present ideas to stakeholders, all without stressing over code:

​https://prototypekitcourse.com​

Cheers,
Adam