Inline Manual Blog

"Lets sort out the murky world of documentation!"

Why auto-launch different onboarding tours for different user groups?

6 months ago

It’s rarely a good idea to develop and maintain an application with different UIs for different users. Yet an ideal user experience is one which is tailored and provides the right level of guidance to help users find their way.

Different users: job comprehension versus solution experience

To design an ideal onboarding experience, you have to make some assumptions:

  • The goals of the user.
  • Their experience level with the subject matter.
  • Their awareness of your application.

Knowing this, you can decide what message and experience will function the best for that user.

To make the best guess, you try to get as close to your users as possible. Through market research, interviews, surveys and analytics you can see how users interact with your application.

The closer you get you’ll realize there is more than one user group and there is more than one goal. One user may be completely new to the sector you’re operating in, and in need of more hand-holding. Another user may be switching from a competitor’s product. That type of user would be experienced with similar applications and bored by excessive explanation.

Unlike many products, software is one that could respond to someone’s prior experience levels. For example, software can take into account someone’s level of “job comprehension” and “solution experience” as described by Alan Klement in Design for switching. Alan proposes that if a user is switching, their prior experience will be different to a user who is new to that type of solution.

Alan Klement manages where you can learn more about the Jobs-to-be-Done framework and how it can help you understand ‘the why instead of the how.’ That is, why people make buying decisions, and using that to design products.

However, he highlights this is a potential pitfall: “from a software complexity point of view, it’s rarely a good idea to have different UIs for multiple types of users.” Rather, he suggests revealing features to customers when they need it.

Adaptive systems

Marketing teams develop buyer personas to understand who they are selling to, and what the right message is for those users. Product developers and interaction designers spend extensive time trying to understand users to make the most informed decisions about users needs.

This creates a dilemma. In the process of developing one product, you discover you have a variety of different users with different goals and prior experience. There isn’t necessarily a one-size-fits-all solution.

In terms of marketing messaging, companies have become ever more granular in their targeting specific messages to specific user groups. All of that communication generally happens outside the application, such as in targeted email marketing. There’s increasing investment in personalization at the application-level, yet this is also complicated to develop and maintain.

In terms of interaction design, progressive disclosure can hold back more sophisticated functionality as a new user gets familiar with a system. There are a few negatives, though. You run the risk of over-constraining users who later don’t need to have advanced features hidden away.

Both of these solutions are not straightforward or ideal, and they can create a maintenance headache and misdirect your product development.

Onboarding in an adaptive layer with Inline Manual

If you want to start now to respond to different user groups and buyer personas, you can do this with Inline Manual.

Merely offering a list of tutorials won’t provide the right kind of onboarding experience. A Job-to-be-done isn’t a task or activity because that doesn’t address the motivation of the user, nor their prior experience.

To respond to “job comprehension” and “solution experience” as Alan Klement suggests you can create unique onboarding experiences for specific user segments.

Here are three ways you can build in this adaptive layer with Inline Manual.

If you’d like to see how to build an interactive and adaptive user onboarding experience watch this demo of using Inline Manual.

User onboarding at Vincere - recruitment at a global scale

6 months ago

We contacted Annabella Poon, Marketing Manager at Vincere to tell us more about how Inline Manual fits into their mission.

Vincere is a Cloud-based recruitment platform specially designed for recruitment companies of all sizes. More than just a database of records, Vincere’s intelligent pipeline-based CRM/ATS gives recruiters a heads-up display of all activities happening at every stage of the recruitment pipeline to help them manage the end-to-end recruitment process - from getting jobs all the way to shortlisting, interviewing, placements and ultimately, getting paid.

Vincere User Onboarding

Though Vincere is loved for its intuitive and easy-to-use software, the software boasts many other features and configurability options under its hood. Its SaaS-based model also means that product updates are released on a regular basis. Hence they needed an effective way to train existing users on newly added features as well as onboard trial users on the depth of their system. Their users required “on-demand training to suit their learning pace.” Their user base is global, and this means that support had to accommodate for various timezones and languages around the world.

Annabella and her team started with a free trial of Inline Manual, and determined that the pricing and responsive support made this the best choice for them. “Inline Manual provided maximum control with its fast, out-of-the-box authoring tool for marketing team to create, test and push tutorials live with little to zero help from dev team,” she said.

This mirrors the experience of many of our clients, where marketing teams were having to wait for IT/dev support to implement the wizards built into applications. When the numbers of tutorials increase, or when they need targeted tutorials, these companies come to Inline Manual looking for a way to make this process independent of product development timelines. One of the most common questions, particularly from marketing teams is: How much control will I have?

Annabella said that they liked that “Inline Manual is very much a self-service tool but there is support when you need it most.” That’s reassuring.

They chose Inline Manual to create tutorials and walkthroughs which would allow them to train and onboard new users. By creating step-by-step walkthroughs they are able to “enable users to follow and get a quick feel of how things work,” Annabella said. The good news is, they can see the benefit, “We get lesser support tickets to handle and this frees up time to work on other things that will deliver value.” That’s great to hear!

We love that Inline Manual can work great out of the box, but it’s inspiring to see how our clients extend and integrate it. One thing we really liked was how Vincere uses progression tracking to encourage users to complete the onboarding and training. We checked with their Chief Technology Officer, Nigel Gardiner, to ask how they extended Inline Manual. He told us: “The progression tracking was very easy for us to add to Vincere, we simply needed to supply a unique identifier for each user in an API call to Inline Manual, and Inline Manual took care of the rest!”

To find out why companies like Randstad and Michael Page, plus hundreds of smaller growing recruitment firms across the globe choose Vincere, go to

Vincere User Onboarding

Growing Customer Success

6 months ago

In the past two years, Inline Manual has undergone big changes, and we’ve grown with you, our customers. This growth has meant responding to your needs with an expanded support system in place.

Big changes

Previously, you could only launch static click-by-click walkthroughs with our authoring tool. Now with Inline Manual, you can launch a range of content dynamically based on segmentation, provide detailed help in context, and you can carefully ensure the quality of your content with version control.

We’ve learned from you as you’ve extended how you use Inline Manual. You’re taking what you learned with new user onboarding, and you’re applying that to your wider customer base. Your messages and needs are different, and that is where our Segmentation and Analytics help.

As the quality of your content is improving, the positive results you’re getting are more wide-reaching. Like our customers experiment and report back to us, we, in turn, develop the product to meet your needs. Meeting those needs means also providing expanded support and help.

Support coverage extended

Everyone who uses Inline Manual gets help and support. We’ve grown the support team to include four people now. Our bigger team has allowed us to extend coverage from 8 to 14 hours a day. Soon we’ll be extending to 24 hours a day coverage by growing the team.

Expanded guides and resources

We’ve been growing our knowledge base, which we implemented in January of this year. We’ll be improving our guides with your feedback which has been very helpful to us.

User Experience Improvements

We’ve improved the tools and user experience based on feedback. Our aim is to help you be as self-sufficient as possible.   

Professional services

We also started providing consulting and development to help clients create walk-throughs and implement designs.  

Getting started webinars

We’ve added bi-weekly live demos to help you get started with using Inline Manual. You can register for those here on our blog.

Get in touch with us at at any time. We're always happy to help!

Yarn - first impressions and future prediction

7 months ago

Facebook released Yarn - a package manager that is supposed to replace NPM. What do I think? TL;DR: Yarn is great, but it will be irrelevant soon. NPM too.

Yarn logo

What is Yarn?

Yarn does the same thing as NPM. It's a dependency manager. It just has few extra features. The important ones are:

  • It makes sure that everybody installs the same versions of packages in the same form. Just like Shrinkwrap, but native. If you already use Shrinkwrap, or you're afraid of another LeftPad scandal, Yarn is an easy solution.
  • It supports offline mode. If you already installed some version of a package, you don't have to download it again. You can add it to a new project even if you don't have an internet connection. Which is great for digital nomads sitting in coffee shops with poor connections.
  • It's fast. Two reasons: First, there's no problem with slow progress bar redraws (which was already fixed in NPM). But more importantly, it downloads packages in parallel (NPM downloads them in waterfall style). If you have large project with lots of dependencies, the speed difference is significant.
  • One tiny feature nobody talks about yet: Yarn takes care of dependencies from both NPM and Bower. So if you still use Bower, this could simplify your workflow.

Should I use Yarn?


If you deal with any of the points above, you can start using Yarn right now. So far it is fully compatible with NPM. Just install Yarn, type yarn and you're done.

However, if you have lots of small packages and you don't have any solid reason to migrate, then it's not worth it. NPM isn't going anyway and it will stay with us for very long time.

The only problem with Yarn I encountered so far are dependencies on packages linked directly from private Git repositories. But that should be easy to hack.

A little bit of history

Before I reveal my forecast of Yarn's future, let's go back in time a little bit.

Do you remember Grunt? The build system used by everybody. But then some developers started to grumble, that it's slow and needs lots of configuration.

And so Gulp was born. A shiny new build system. Very fast, compared to badly configured Grunt. And it made sure to be in your face about that. In the console, every line contained information about how many milliseconds this task took. It was a perfect marketing strategy. Everybody was ranting about how fast Grunt is, while the true innovation was the use of streaming.

Everybody predicted that Grunt will die and everybody will use Gulp, forever and ever. But what happened? Since developers started to notice the build process problems, they migrated directly to native NPM scripts.

Grunt and Gulp still exist. But nobody cares about build tools anymore. The problem is already solved. Everybody cares about the new stuff - transpilation and package management.

Back to the future

I think the history will repeat itself.

Yarn in console

Just look at how Yarn brags about the speed. It even brags about the speed during tasks that depend on user interaction! That's the same marketing trick used by Gulp. And again, everybody is raving about the speed, while the key feature is version locking (Shrinkwrap).

Now, since this problem will attract the attention of developers, I think they will again come up with a completely new and different solution, making the package management problem irrelevant. I personally think it will be something, that:

  • analyses source code, finds all imports and requires
  • does smart lookup for linked packages
  • is based on package content finds relevant loaders and transpiles it
  • shakes the tree and eliminates dead code
  • runs the result through tests
  • saves valid output

This way we will get rid not only of package managers, but also Webpack, Babel, Rollup and who knows what else. Well, no. We won't get rid of them. But we will hide them into the background. So if we don't want to, we won't have to deal with them.

The nice side-effect will be that we will also get rid of these quasi-funny articles.

I can't wait.

What about you?

Did you already try Yarn? Will you use it in your projects? What do you think about Yarn and its future?

About the author

Riki Fridrich, @fczbkk, lead frontend developer at Inline Manual.

PS: You can also read original Czech version of this article here.

We're hiring!

We're looking for JavaScript developers! Come join our team.

Take control - Part 2 - How much control will I have?

7 months ago

If you choose a DIY solution, there can be an increasing amount of friction building up between customer-facing teams and product-focused teams when implementing tours, tips and tutorials. In Part 1, we looked at this issue to try and understand the issue from both perspectives.

On the one hand, marketing and support teams want to respond to opportunities and user needs quickly. On the other, engineering teams are concerned about switching to a third-party service because of the lack of QA and testing, and poor design capabilities.

If you’re stuck in this situation, we’ve listed some of the issues below, and how you can address your concerns with Inline Manual. We do think Inline Manual will be much better than a DIY solution if you’re running into these problems. However, with every change you have to evaluate the gains and losses by comparing it to your current solution.

Let’s look at the kind of control you will be able to have with Inline Manual.

What about installation and updating?

  • The player: You will need one line of code installed in your application to have the player right in your app. If you want to have advanced segmentation and analytics with People tracking, you will need to have a few more lines of code installed. They player works on any browser.
  • The authoring tool: You will need Chrome just for authoring. If you have control over installing extensions in your browser, you can install the Inline Manual Authoring tool into Chrome.

The good thing is, once you have the player installed on your app, and the authoring tool installed in your browser you’re good to go!

You do not need further support from your engineering teams to keep Inline Manual updated.

Will I be able to control configuration?

You will have full control over your account.

  • Add new tours, tooltips, launchers and knowledgebase articles
  • Control who sees content, such as welcome screens targeted to specific users

You can also add collaborators with role-based access, as owners, writers and readers to give tiered control over each site.

We need WYSIWYG content creation and interactive design

With the authoring tool you can add and edit content, and control how it appears.

  • Include a video in a tour,
  • Edit the HTML directly,
  • Dim a screen and highlight single or multiple elements,
  • Lock down the UI so they can’t click actions until users are prompted,
  • Position launchers on the page and within contexts or sections of an application.

These are all of the kinds of things you will easily do in the authoring tool.

We want Total Design Control

Marketing and Engineering teams especially will be glad to hear you have total design control to make the tours look like they are seamlessly part of your product and not just a third-party add-on.

  • Are you not experienced with HTML and CSS?
  • Inline Manual can inherit the CSS from your website and instantly just match the look and feel of your site.
  • You can click to change colours using our design tools.
  • Are you experienced with HTML and CSS?
  • You can edit each step’s HTML directly.
  • You can also edit the CSS of your tours.

We also offer help from our customer success team to integrating Inline Manual and helping you achieve a seamless experience to match your brand.

What insights are available with Analytics and People tracking?

Analytics will work right out of the box. Access depends on your subscription level.

  • Which tours are really helping people?
  • Where are users getting lost or dropping off?

Having access to Inline Manual’s analytics will allow you to compare the experience across your application and see how users are benefiting from the content you create. For example, our customers often see higher completion rates for tasks.

People tracking on the otherhand, is one thing your developers would configure. (A few lines of code, similar to installation!) People tracking will let you see user-by-user who is playing and completing your tours. Having that information is helpful because you will be able to make sure auto-launchers for specific groups of users. It also helps with segmenting so you can control who sees what.

We want reliable QA and testing

Marketing and Engineering both want a clear quality assurance process.

With Inline Manual you can create a QA and a production site, each with their URLs and unique API keys. When you create a new walkthrough, you can assign it to the QA site and test it there. Once you’re happy you can assign it to the production site. You don’t have to do kludgy things like duplicate it, or recreate it.

This is all done within the administrator dashboard, and again you don’t have to lean on your development team to deploy.

This leads us to talking about version control and releases.

Can the marketing team handle version control and releases?

You can create releases as you make improvements and iterations to your content, all from within the admin dashboard. And again, you do not have to ask for help from your developer team.

This is super helpful when you are preparing to launch a tour for a new campaign. Once you understand how to create releases, you will be able to manually specific the new version of your content and control when your campaign launches.

The great thing is, this puts marketing teams in control of their timeline, and not tied to the development schedule.

If you’re wondering what kind of control you can have - sign up to our next webinar to see how to Get Started with Inline Manual.

Upcoming free webinar

Learn how to keep users engaged with feature announcements

Thursday, April 27, 2017
4:00 PM - 4:45 PM GMT (BST) - London
9:00 AM - 9:45 AM PST

Sign up for webinar

Notify me about tips and new features