Take control - Part 1 - When DIY is not A-OK

Though some of our customers are new to creating guided tours, many do have experience with building walkthroughs developed and controlled by their product development and engineering teams. At some point, they outgrow this process and come to Inline Manual.

Naturally, one of the most common questions we hear when they join our webinars and demos early in their search is “How much control will I have?” Or as one client put it more plainly: “Can I get this out of the hands of engineering?” Ouch.

DIY is not A-OK

At the start, development or engineering teams implement open source libraries to build tutorials, tooltips and tours right into their applications. This works really well for a little while. Marketing teams see people are completing their onboarding, the support teams see less tickets. Everyone is happy! This works for a little while, until suddenly it just doesn’t.

Especially when the teams are small, it means communication is easy, and any required changes can be made quickly. As a small company grows, or of course in larger companies, the people who see the need to build those tours are based in the marketing or support teams.

This means requests for changes to tutorials get filed alongside bug reports and feature requests. In terms of priority, this means they may have to wait days or weeks to see their changes made. Each request must be carefully communicated, because any further change means yet more delays.

This means they have a number of problems.

What are some problems a DIY approach creates?

• Authoring and creating content is slow.
  • Requests for changes can take a long time to fulfill. Even with simple text changes, each new alteration is a new “work request” or backlog issue, subject to the prioritization of product development.
• It’s not possible to change content on the fly.
  • Depending on the workflow, it can sometimes mean a marketing team member must hand over a document which carefully specifies the text, directions, and click actions to design a walkthrough. They have to include marked-up screenshots to even show where to place the launchers or tooltips. Then this has to coded and developed with skills only a developer has, and precious developer time is tightly time-boxed.
• Not on the same schedule
  • Because of the reasons described above, though the marketing team might need a tour to be updated now, they still have to wait until the planned release to see their changes live.
• No Analytics. Lack of visibility into results.
  • The teams who need to track results have little insight into which content is performing best, and where people are getting lost in drop-off funnels. They may be using site analytics, but it’s difficult to identify where the content is helping or not.
• It’s time-consuming to develop and test.
  • Selecting the right elements, testing, and managing the tours - it all gets complex when you’re taking a code-only DIY approach to managing the content.

We hear about these issues from our new customers. These are not terrible tales of woe. These are normal, practical problems and friction they deal with day-to-day. And, it was all probably manageable until it became clearly too costly and time consuming. Small frustrations like these seems to build up until it’s just too much.

At some point, they come to the conclusion that the time spent in communication, coordination and development of product tours could be better spent by moving control over to the marketing and support teams who are closely monitoring user engagement and needs.

The problem is, our potential customers must evaluate all of the onboarding solutions out there, find a good one and then finally, convince their engineering teams it’s time to let go.

What is engineering concerned about?

Considering the amount of friction a DIY solution can cause, you have to wonder then, why would engineering teams be so unwilling to let go of this? When their response is delayed, it can make marketing and support teams feel like communicating with customers is must be considered low-priority by engineering teams.However it’s more likely the opposite, that the engineering teams do hold this as very high-priority, and they want it to be as high-quality as their app, QA tested, and seamlessly branded.

In fact, engineering might be afraid that using a third-party solution will mean it would be inferior to what they can craft bespoke for their application. Let’s consider their concerns.

• What about the lack of design control?
  • They want to be able to control of the CSS entirely. They want to inherit or reuse the existing CSS from their application so updates are easier to manage. They don’t want a third party solution confusing their brand experience.
• What about the display, positioning, placement?
  • They’re concerned about being unable to control where tips appear, by either choosing selectors, or manually editing selectors, and placing where they appear.
• Do we want to do maintain yet another third party service?
  • They might worry about having to reconfigure every time a third party service updates. Or having to engage a third party service who charges for yet more professional services just to make the basic features work as expected.
• What about the lack of QA and testing? Don’t touch the live site!
  • They’re worried about letting support and marketing teams edit interactive elements which will be edited LIVE on a LIVE site. That is crazy talk. They prefer clear points for QA, testing and deployment. They don’t want to deal with kludgy workarounds of copying or re-creating tours.

Finally, and this might sound harsh, but some extent Engineering teamsfeel guilty about adding tutorials to apps. It’s a delicate subject to broach. Admitting your UI needs a tour is like saying there’s an inferior user experience that needs an interpreter. User experience designers may, as Kathy Sierra said, think a product should be so good it doesn’t need a manual.

Engineering teams therefore might feel the issues could be fixed with a better design. Maybe they have to tweak the UI or add another feature? And this explains why product-specific issues can take precedence when there are requests for updating a product tour.

Of course engineering will continue the conversation with users to find tweaks and improvements to the interface. What engineering teams don’t know yet is that by having contextual help, tutorials and auto-launching tours they can provide a more empathic user interface which gives support to different customer groups even better than they can in their UI.

For example, new users might leap delightfully into a new UI or feature, and yet existing users might need more hand-holding to manage the change to un-stick their habits. There are also certain kinds of users to playfully discover in a UI, and other users who really want assurance the entire way.

Perhaps there isn’t even a clear way to tweak the UI to help all users. But a guided tour can, and perhaps even smarter by providing specific user groups the right messages. When the engineering and product teams give control of this layer to their customer-facing colleagues, they can have a more emotionally responsive and helpful UI. And, it can save hundreds of support requests from existing users asking “who moved things around here?”

In Part 2, we’ll answer your questions about how much control you’ll have when you’re using Inline Manual.