We are big fans of the jobs-to-be-done theory at Mobiscroll and we believe that focusing on the job customers are hiring our products to do is better than focusing on what they tell us. To get familiar with jobs, you should check out this 5 minute video and jobstobedone.org for a lot of great content on the topic.

I am going to share our thought process behind re-designing the demo page.

Whenever we have to shape a new product or improve on existing products we always go back to what job it serves for the customer. We learned that people hire our demo pages for a couple of different reasons. At start we made a bunch of demos, and categorized them based on the components we provide. We also had customization options, language setting and different phone simulators among other things for the visitors to play with. We have built it to show what mobiscroll can do, help them see the value and make it an easy sale.

Well, it turns out that it wasn’t the full story. Checking what mobiscroll can do for them, seeing if it can help them make their app nicer was only one of the jobs they were hiring the demo page to do.

There we other jobs as well which we discovered based on discussions and interviews. They were hiring it to see how they can implement certain things. Think of it as a documentation. It is better to look through interactive demos with the code right next to it that to just browse through a table of options while trying to guess the name of the property… So the second job we found is education. People were using the examples to learn how to use certain features.

Quick note here: We show the code next to the working demo. The role of the code example changes with the job. In the first scenario people want to get an idea of how hard it is to implement mobiscroll, so our goal is to show them that it’s easy. For the second job the code serves as the actual content they are looking for. They look at the demo, if it does what they are interested in they just copy & paste and then move things around so that it fits their requirements. This is where the [ Copy Javascript ] and [ Copy HTML ] buttons play their role. Every element, down to the smallest button should play it’s part in serving the job.

The other thing we learned is that people were looking for alternative solutions to problems. Let’s say someone is building an app for setting appointments. Picking a time can be done in several different ways – see the Time input ui pattern. So they come in with a solution in mind, let’s say a scroller control and started looking around to see if there are any other options. The question is how can we help them see what are the other options for solving the problem of picking a time. This is how UIPatterns came about. It sprung from a number of conversations and we realized that people come to us for advice on how to solve their UI problems.

Jobs to be done

We identified 3 jobs.

• People educating themselves about what mobiscroll can do, see if it fits the bill
• People educating themselves on how to use mobiscroll, like how to set minimum and maximum constraints for date selection
• People looking for alternative/different solutions to common problems (you could argue that this is similar to the first job, and it is, however we handle it as a different job)

Are these new jobs that just developed and people need new ways to solve it? No, these jobs were always there and people were using a combination of things to solve it. They were using the demos in combination with the documentation, jumping back and forth plus they were using external resources like UI pattern libraries and their own insight, making this huge mix, jumping from one place to the other while putting the pieces together.

As we have these jobs identified, we can focus on helping people being successful and to get the job done as efficiently as possible.

The old product

On the old page, the demos were categorized based on components. So when we released a new component, we have built a number of examples to demonstrate its features. Of course we could not show every nuance and option combination that is available in the API, but we tried to come up with real-world examples and used support tickets and other customer threads as inspiration.

Each demo had it’s own page, and visitors could navigate from page to page if they wanted to try multiple demos.

We iterated a couple of times on naming, from “Booking example” through “Basic Date” or “Basic Time”, but we never really focused on what the job that visitors were hiring the demos for.

The new product

While it is a work in progress and we didn’t fully address all three jobs, there were a couple of things we already did improve.

We kept the categories (there are more than 160 demos at the moment), so it makes sense to categorize them somehow. For now it is still based on components. However we moved all demos under a category to the same page. So we have one demo page per category, which makes navigating the demos faster and much more efficient hence serving all three jobs better. The demos are loaded dynamically which makes rendering the page faster, and as you scroll through them they pop as they get into the view, which makes the exploration more engaging.

How big is the job?

For job number three – educating people on alternative solutions to a problem – we created UIPatterns. The job was big enough so that we broke it out and made a separate product. While we reference it when we have to explain something we also direct mobiscroll customers to uipatterns.io so that they can learn about common solution to recurring problems. This also gave us the opportunity to create something of value for other people than just our customers. While all examples on the website are implemented with Mobiscroll, it doesn’t mean that you as a non-customer can’t get value from it. The goal is to curate a list of mobile ui patterns that can be implemented with the technology of your choice and help you become better at your craft.

Our next step in serving Mobiscroll customers better is to figure out a way of integrating the examples and patterns back into the original demo page. We are looking to make it easier for them to get the same value as navigating away to uipatterns.io while not breaking the fluidity of the experience.

A companion to the documentation

Let’s address job number two. People are using the demos for figuring out how to implement certain things. In these situations users know what they want and can probably articulate it really well. So providing if they see a list of examples they can easily skim it and quickly find what they are looking for. If they don’t hit it in the first try, scrolling through a couple of other examples is reasonable. Based on these observations we made the configuration options links to the documentation. If something looks promising the user can get more information with just one click.

Knowing this, there are a couple of places where we can still improve:

• Creating small demos that can be easily digested and focusing on one or two small features.
• Naming the demos in a meaningful way, using the same language customers are using – you can learn how they are speaking about your product, naming your features from any type of communication like support emails, phone calls…

Demonstrating the power of mobiscroll

If we look at the first job, we see people who are using the demos to learn what mobiscroll can do for them. This might include things like, “I need a calendar and I want to check if it can do xyz…” or “I need a calendar and a list view, but let me see what else is there…”. They can be visitors before becoming a customer, or existing customers having the need for maybe another piece of Mobiscroll that they didn’t use before, just to name a few.
The common theme is exploration, so our goal here is to make the process enjoyable and serve their underlying jobs better, which could be something like showing it off at a meeting.

How can we help them look good at it, how can we help them be successful? We have this feature called “Send demo to your phone”. So what it does is basically sending a text message with a link to the demo for testing or sharing. This also gives them the opportunity to see how the product actually behaves on a real device – not just their laptop. You can get to these underlying jobs when you explore motivation and intent through a jobs-to-be-done interview.

If you plain and simple ask them “What would make the demo page more useful to you?” they won’t be able to answer it and provide meaningful information.

How to serve all three jobs with one product

If you identify three different jobs, that doesn’t mean you will have to create three different versions of the product. If you put a three way choice in front of people, they might get the fear of missing out which adds anxiety into the mix. People always find their way around, it’s not just a simple this for this and that for that. They are “misusing” things to get the job done, and “misusing” sounds terrible and has a negative connotation but it is where innovation lies. Misusing means it is being used for something that is outside the boundaries of what it was designed for. I am using a butter knife for a 100 different things, even for tightening a screw sometimes, because I just can’t find a screwdriver. So what?!? … it gets the job done.

We have a long way to go in improving our demo pages to server the three jobs better. But the first step is finding what those jobs are and being able to articulate it so that everyone understands. It helps in alignment around something that is meaningful, it helps in communication internally and between teams.

People are terrible in explaining what they want. They usually think they know what they want, but they always think in terms of solutions. It’s your job to makes sense of all the feedback and get to the root of things.

If you are looking for quick, no-hassle solutions that can be literally implemented in minutes, check out the products we provide at Mobiscroll.