Case study 01 · 6 min read
One checkout, four industries
Redesigning checkout and sign-up at Nexudus
- Problem
- Coworking spaces sell multiple items, such as memberships, leases, products, event tickets, and room bookings, through the same checkout. Operators had to choose between asking every customer for too much, or switching off online sign-ups altogether.
- Role
- Lead designer, from discovery through to handoff, beta, and launch
- Team
- Product managers, developers, QA, content, training, and marketing
- Timeline
- About three months
- Outcome
- In the first three months of the new portal, completed bookings rose from Visa required, and portal-related support tickets decreased by Visa required.
Four businesses, one checkout
Why checkout was harder than it looks.
Nexudus is the platform coworking and flex space operators use to run their business. Part of that is the checkout their customers use to sign up and buy things online.
That sounds simple, but a coworking space is really four businesses under one roof:
Memberships and leases
Work like subscriptions
Products
Work like retail ecommerce
Events
Work like ticketing
Room bookings
Work like hospitality
Each of these has its own way of buying. On top of that, it’s a fragmented industry with no real standards, so every operator runs these in their own way.
Picture two people landing on the same space’s website:
A day pass for tomorrow
Should be able to pay and go in a couple of minutes.
A private office for a team of 12, on a two-year lease
A big commercial decision that usually involves a sales conversation, a proposal and a contract.
Our checkout treated them the same.
Because every purchase went through the same flow, operators were stuck with a trade-off.
Asking for too much information for a simple meeting room booking put off potential sales, but keeping the form simple limited what the operators could feasibly sell online. Add in that memberships aren’t all the same (hot desking v a designated office) and a lot of our operators gave up selling memberships through Nexudus.
The most valuable sales were happening outside our product.
What I found
What did each different purchase actually need?
Before moving into design I had spent over three years onboarding and training operators, so I knew a lot of the difficulties first hand. That gave me a head start, but I wanted to go deeper.
Around 50 hours
Of customer interviews, not counting the validation research once we had a prototype
Hundreds
Of Zendesk tickets related to checkout and sign-up were reviewed
Over 3 years
Onboarding and training operators before I moved into design
I also went through the existing Basecamp backlog of improvement requests. The picture that came out of it was pretty consistent.
Different purchases need different information at different times, and some of them shouldn’t be a checkout at all.
What I designed
The job was to let each purchase ask for what it needed, and nothing more.
Key decisions
1. Only ask for what the sale needs
Instead of one form for everything, each item an operator sells can ask for its own information. A meeting room booking might only need a name, email and phone number. A membership might need a company name, address and more. Customers only see what’s relevant to what they’re buying.
2. Every step should get the customer closer to buying
This became the rule for the whole flow. If a step didn’t move the customer towards completing their purchase, it was removed.
3. Self-service or enquiry, plan by plan
Operators can choose which plans customers can sign up to directly and which ones go through an enquiry. When someone enquires about an office or a long-term lease, a draft proposal is created automatically on the backend, so the sales team can pick it up straight away. Lower-tier memberships like hot desks can stay self-service.
This brought the sales process operators were running outside Nexudus back inside the software.
4. A true guest checkout, with clear payment expectations
Customers can now buy one-off items without creating an account.
Payment in Nexudus has a lot of variations, and customers need to know what’s going to happen before they commit. For example:
- They might be part of a team where another member handles all the payments
- Some items need approval before they can be purchased
- Some companies need an invoice so their finance team can pay
- Payment methods like card and direct debit/ACH have different processing times
The checkout makes it clear which of these applies, so customers know exactly what to expect.
The admin side
Operators needed to be able to set this up without it becoming another complicated settings screen. They needed:
- A simple form builder so they can decide what information is requested for each sales item
- A per-plan setting for self-service sign-up or enquiry, with the draft proposal created automatically
- One settings section that brings all checkout and sign-up settings together, to make setup simpler and easier to understand
The solution
Trade-offs
“Won’t asking for less mean we end up with incomplete customer data?”
Required fields carry across purchases. If a customer is missing information that a new purchase requires, they’re asked for just that. For instance, if a booking asks for name, email and phone number, and a product asks for the same plus an address, a customer who has already made a booking only sees the address field when they buy the product.
“Doesn’t guest checkout mean anonymous purchases?”
Guest checkout only applies to bookings and products, which are one-off items. Operators can also switch it off if they don’t want it.
Iterating rather than starting over
I didn’t really explore or throw away big alternative directions. The first idea was a very simple version of what we shipped, which got refined through research and testing.
Shipping it
Designing it was half the job. The other half was getting it live without breaking anyone’s setup.
Rolling it out without breaking anything
Every operator already had checkout set up their own way, so this had to be fully backwards compatible.
I created a “default form” that controlled the forms for all sales items. When we migrated, each operator’s existing form became their default, so nothing changed on day one. From there they could customise their flow by overriding the default on any individual item.
Testing and launch
Once we had a prototype, I ran validation research with operators before development. I worked with the developers and QA throughout the build, up to a beta in more than 20 locations, run by operators both large and small.
For launch I trained our internal teams, ran webinars for customers and operators, and worked with content and marketing on help articles and announcements.
What happened
So, did it work? Mostly. Here’s where it did, and where it hasn’t yet.
The new checkout launched as part of our new members portal, so these numbers reflect the whole release, not only checkout. They cover the first three months, with Visa required of operators migrated so far.
Booking completion
In portal-related support tickets, as a share of all tickets
Accessibility score
Largest contentful paint
- Booking completion went up. Instant bookings now complete Visa required of the time.
- Guest checkout is working. Visa required of guest booking sessions complete, and guest checkout sessions grew from Visa required in the first month to Visa required in the last 30 days.
- Support tickets went down, not up. We expected portal-related tickets to rise to Visa required of all tickets during migration. Instead they dropped.
- Operators moved quickly from the default form to per-item forms, and didn’t go back.
- Customers told us they were seeing better conversions.
Still work to do
Plan purchases complete Visa required of the time, events Visa required and products Visa required. All three have improved month on month, but they’re still below our target, so that’s where we’re focusing next. As we didn’t track these in the old portal, these are our first real benchmarks for them.
What I’d do differently
We designed and built this as one big piece of work. Because so many of the settings interact with each other, it was really hard to test for edge cases and conflicts we hadn’t anticipated.
Next time I’d break it into stages, so each part could be tested and settled before the next one was built on top of it.