Rebuilding Grupop’s Onboarding Hints in UserGuiding

This piece was originally going to be a WalkMe build - Grupop’s 5 onboarding hints, recreated in the classic WalkMe editor. It turned out that editor has no public self-serve trial at all; access is gated to existing customers, SAP-internal staff, or partners. After checking a few well-known alternatives (Whatfix and Appcues both turned out to gate their trials behind a sales call too - a related pattern worth its own note elsewhere), UserGuiding was the one that let me actually sign up and start building, no call required.

Grupop’s real onboarding is deliberately light: 5 short, contextual hover hints shown on first login, after considering heavier options (full video walkthroughs, then captioned screenshots) and judging them as too much friction for an already busy teacher. I wanted to rebuild the same 5 hints here, both as a like-for-like comparison to the hand-coded version, and to see what a dedicated tool adds that custom code doesn’t, or vice versa.

I started by building a Guide - UserGuiding’s step-by-step, sequential flow type. It worked, but it only offers a centered floating modal box; there’s no way to anchor a step directly to a specific element on the page, or highlight it. For hints that are supposed to point at something - a button, a field - that’s a meaningful gap.

UserGuiding’s Hotspots solve the anchoring problem directly - a pulsing beacon attached to an actual element, expanding into a tooltip upon user interaction.

But they come with a real, deliberate constraint: hotspots in a group aren’t sequential. They all appear together, and a user can click them in whatever order they like. There’s no “hotspot 2 only unlocks after hotspot 1” - that’s not a missing setting, it’s how the feature is designed to work, in contrast to the strictly ordered Guides.

I initially treated this as a problem to solve - I wanted the 5 hints to run in a fixed order, the way the current JS-based version does. After testing however, I realised that this was not a design flaw or a limitation but rather it is how UserGuiding’s different features are designed to work, for good reason. Not for the first time in this series of case studies was I brought around to the idea that the design of products I was using was based on research rather than just being what I initially assumed to be oversight that only a true genius such as myself could recognise!

I had wondered why guides and hotspots were separate features within UserGuiding rather than a joint functionality. The more I dug into the issue, I became aware that this has been a topic of research since as far back as 1987 in Rosson & Carroll’s HCI research (Interfacing Thought: Cognitive Aspects of Human-Computer Interaction). More modern interpretations of this compare product tours - what Grupop uses and what I was hoping to replicate - to progressive onboarding. Progressive onboarding is based around the idea that users prefer to interact with onboarding and a new product in their own manner using their own intuition and exploration instead of being directed through a full onboarding session the minute they interact with the product.

I have come to find that using 3rd party tools to replicate functionality is a healthy way of testing your own functionality. And in this case, once I had made my peace with hotspots over guides (and progressive onboarding over a product tour) the non-linear behaviour stopped being a limitation and started looking like the better design: a teacher can explore whichever part of the interface draws their attention first, rather than being marched through a fixed script - arguably a better fit for a busy user than a forced sequence.

Only 1 of the 5 original hints needed any real rewording to work independently of order - the rest transferred across to a completely different tool and delivery mechanism with no changes at all. That’s a small but genuine data point: it suggests the original onboarding copy was already well-calibrated on its own terms, not just “good enough” by luck. Rebuilding it elsewhere, under different constraints, is a reasonably honest way to stress-test that.

Also, upon having to question my design for the product tour format of Grupop’s onboarding, I thought back to how I had come to that conclusion in the first place to see where I had effectively mistaken or misunderstood the situation. As referenced in the first case study, I had initially believed Grupop could be explained to everyone together via video tutorials and the more I edged away from that idea, the more I wanted something sleek, quick and easy, almost instantly forgettable. I wanted Grupop’s onboarding to match what the product itself was supposed to be - seamless and easy. So I decided on keeping it confined to one single screen so it could be done as quickly and painlessly as possible by the user rather than them being continuously peppered every time they opened a new part of the web app. I believe that my initial onboarding decisions were in actual fact running parallel to the ideology I discovered within this case study - I did not want to force my users into a long-winded product tour. I essentially wanted just a minimum number of hints or directions that provided just enough information to enable them to go figure the rest out themselves. The fact that they were presented in a predefined order ran counter to that in some way but my overall decision making process has been validated rather than ripped to shreds!

• Sequencing isn’t automatically better UX - I assumed it was the goal going in, and testing proved otherwise for this specific case.
• A tool’s constraints are sometimes a design signal, not just a limitation - Hotspots’ non-linear behaviour pushed me toward a genuinely better-suited onboarding pattern than the one I’d planned to force onto it.
• Rebuilding existing content in a new tool is a legitimate way to test whether it’s actually well-written, independent of the platform it was first designed for.