Planet MiNDS

The definition of an “engaged user” varies from product to product. For a to-do app an engaged user should be logging in every day to add and complete items whereas for an invoicing app an engaged user might only log in once per month. There is no consistent quantifiable definition of engagement across different products.

Unlike page views, visitors, returning visitors, and conversions, there’s also no analytics app that can instantly tell you what you need to know. But ignore engagement at your peril.

Google+ claims 170,000,000 users, which gets them a few news stories, but ignores a very real problem. Almost none of their users are engaged. They’re just people who clicked a link titled “Ok” when faced with Google+. It’s similar to newspapers goosing up their page views using hacks like slideshows. At some point you have to wonder who you’re really fooling.

Why is engagement important?

Most customers who sign up will use a product only once. This is true for every product with a free trial. This isn’t surprising; it’s the fallacy of funnels in action. When you strip every barrier away from signing up, what you get is lots of sign-ups. Unfortunately lots of sign-ups doesn’t translate to lots of customers. Customers are the result of a series of events. Here is a simple overview:

Engagement is just one piece of the puzzle, but it is so frequently ignored that there’s lots of quick wins to be had. Here’s 4 ways to increase user engagement.

1. Make a Strong First Impression

Every day a potential customer is seeing your interface for the very first time. This can be forgotten within teams that are always designing for themselves. The first screen your users see has 3 important jobs…

1. Explain how your application works.
2. Motivate your users to get started.
3. Let your users know how to get help, if and when they need it.

Web applications that do none of the above get the exact behaviour that they designed for. The users will log out and most likely never return.

There are lots of great ways to welcome a user to your app and show them around. There are blank slates, tutorials, dummy data, etc. A good first step that we encourage Intercom customers to do is to post a welcome message to greet each new sign up personally. This works great for starting conversations, which in turn increases conversions.

Always Show a Welcome Message

In Intercom we show the above welcome message to users after they sign up. It is a personal note explaining that we are always available to help. This single message is responsible for over 400 conversations that simply wouldn’t have happened otherwise. Some people just write thanks, and we reply. Some ask how to set up a welcome message, and we reply. Some ask questions, and spot bugs and, again, we reply.

Simply communicating with your users is a great way to encourage them to ask questions, try out features, and stick around. By starting a dialogue they’re far more likely to say things like “How can I do email inactive users” or “How should I use tags?“.

At best you’ll win yourself more customers, and at worst you learn what’s missing or misunderstood in your application.

2. Gradually expose the depth of your product

Every worthwhile application has features that aren’t immediately apparent or useful. These can include quick-wins such as email notifications and alerts, third-party integrations, export features, and even small optimisations like keyboard shortcuts.

These deeper benefits can’t be called out immediately. After all, who cares about data export before they have data, or keyboard shortcuts before they’ve used any features?

Most product owners tend to try to expose these features either through badly timed email blasts, documentation, or an FAQ. None of these approaches work well.

Emails arrive out of context, out of time, and are more likely to interrupt a user than to interest them. Their response is to archive your and stop reading future emails.

Leaving features explained and promoted in your FAQ or help sections means their only chance of exposure is when a user has experienced an issue with a part of your product. This isn’t the ideal time to distract them with other features.

Define a Message Schedule

We advise our customers to create message schedules to gradually promote certain features. When you have good insight into your userbase you can work out which secondary features delight users and at what point they’re useful. Once you’ve done that it’s just a matter of timely communication. Intercom lets you stagger messages over a series of sessions. This means each time a user logs in you’re showing them more and more reasons to stick around.

Here’s an example engagement routine from one of our customers:

Always end each message by letting your customers know that you’re there to help if they have any questions. This is key to getting feedback, which helps you tweak your engagement routine.

3. Announce features and improvements in-app

Users don’t notice when your product development slows down. They’re logging in to use your product, not monitor your development progress. However, if things go quiet for long enough, they’ll be easily distracted when a competitor releases a new feature, whether valuable or frivolous.

The only time your users care about features or improvements is in your application, so that’s exactly where you should be announcing them.

Anecdotally, we see a 10x increase in communications (as do our customers) from in-app messages over email announcements, and there are other, softer, benefits too. For example when we announced the map and gallery features in Intercom, our users clicked straight through, were immediately impressed and started tweeting screenshots. I can’t imagine an email achieving a similar effect.

4. Talk with customers during trials

Startups tend to fall into two categories: those that solve a problem people experience, and those that are nice to have or fun to use. Don Doge famously labeled the two categories as vitamins and painkillers. If your product is a painkiller, then you can learn lots from your trial users.

There are two types of users in your 30-day trial. There are tyre-kicker who might sign up after seeing some praise on Twitter or a link on Hacker News. They don’t have your problem, and are only here to have a quick look around at the solution you’ve created. These guys aren’t prospects, and will rarely have valuable feedback for you. Never listen to theoretical customers.

1. What makes them sign up? – This is usually your best approach to increase engagement and conversions. Every worthwhile app has some killer attributes or features that push users over the line and have them reaching for their credit card. Attributes can be things like speed, security, or compatibility. Features are usually specific things your product does that customers value.
2. What makes them leave? – What did they expect your product to do that it fails to do? This is useful product and marketing feedback. Either your marketing should be more targeted (e.g. imagine a professional photographer signing up for Instagram to sell their photos), or your product genuinely is missing features for a group of your prospects.

Starting these conversations with trial users is educational but also gives you an chance to address issues, let users know that their feature is weeks away, or persuade them to try your alternative approach. For many users, your app will hopefully be good enough to sell itself, but there’ll always be trial users who just have a few questions before committing. You have to be there for them. After all, even Porsche and Ferrari garages hire salesmen.

Start Increasing Engagement

We’ve seen first hand the effect of these four simple steps towards engaging with your customers. Each takes no more than an hour and pays back many times over. What other tips and techniques have you seen? Let us know in the comments.

May 16, 2012 05:39 PM

The goal of preparing wireframes is to solve design challenges regarding layout, and priority. This is usually done in wireframes through experimenting with layouts and the application of contrast, similarity and some other principles.

By applying the Gestalt principles to your components, you can quickly prepare concepts. The whole point of working at this fidelity is the speed at which you can explore ideas with a reasonable degree of precision. Over the years I’ve learned some useful ways to keep things fast, useful and timely. I’m loathe to write a “7 top tips for wireframing” but when working with less experienced designers I find the following themes occur frequently…

1. Everything means something

Every colour, every line, every shadow, every gradient. If your atomic unit of wireframes is a rectangle, with solid lines, a colored background and a drop shadow you’re communicating a lot, whether you intended to or not. These artefacts can be carried through to design, without anyone ever thinking why they make senes. Everything has to mean something.

2. Consistency Helps

One nice thing about sketching, is that it defaults to same colour and font everywhere (i.e. you have to swap markers or change your handwriting for a difference). A frequent issue I see with wireframes is numerous different shades of a colour, or line weights, or font faces, all included without thought. This makes the wireframe more confusing to understand, as I wonder “Did he deliberately change font here? Is that label bigger because it’s more important?” etc. To avoid this, I encourage students to use a limited color set (3-5 grays), 2 fonts, default HTML components, and little else. This might result in “dull” wireframes, but bear in mind all wireframes end up in the trash anyway. They’re not what counts, you’re not delivering a PDF for visitors to “ooh” and “aah” at, you’re desigining software for people to use. A sexy wireframe is a waste of everyones time in the project.

A second point worth noting here is where you lay your baseline. Starting with black text, means you can only get bigger and bolder, resulting in a Deep Purple style wireframe with everything louder than everything else. Starting with gray text, allows you to go darker and lighter. As Ryan Singer said, in a moment of Linguistic Relativity, HTML doesn’t offer a <weak> tag, but maybe it needs one.

3. Speed and Exploration

The purpose of low fidelity design, is not to polish and refine, but to explore the solution space. Initially it often appears there are many solutions to a design challenge. Only by exploring a few of them, and laying them out in front of you can you decide which will work best. Cennyd Bowles describes how chess players face a similar challenge. Early in the game there are a lot of choices. Some you can rule out by instinct or experience. The remainder you mentally explore to see how they play. Naïve designers will fall in love with their first idea and cling to it for dear life. Andy Rutledge describes this phenomena an Lord Of the Rings inspired essay title My Precious.

If you can’t produce concepts quickly, then you’re working at the wrong fidelity. If your wire-framing serves only to deliver a grayscale version of what you’ve already decided you’re building then you’re wasting everyones time.

4. Real Copy, Real Data

The biggest mistakes I’ve seen made in projects (including my own) comes from the designers not seeing real content up front. If you’re including a photo gallery, you have to see the photos before you can decide whether to include it, make it a primary feature or fight against it. Similarly If you’re designing a data driven dashboard, you need to know the data looks like. Dummy data leads you into a world where headings never wrap, text can justify without looking absurd, photo dimensions and orientations are always convenient, and numbers always fit in their little boxes. The path to UI hell is sign posted “Lorem Ipsum”.

5. Know your technology

A great design can be a terrible solution. If your design includes custom HTML components, novelty size buttons and dropdowns and ajax powered live search, it’s worth remembering that every project has a budget. If you know HTML/CSS/JS, which you should, and you’ve seen what it takes to test a page on IE6/7/8/9 Safari, Chrome and Firefox, you’ll think twice about what wizardry you’ll put in your wireframes. It might just a little component, and it might even be already available in jQuery UI, but remember, there are no small changes. I’m not saying that you should never include advanced interactions in wireframes, I’m saying you need to know the cost of what you’re doing. For Hipmunk it’s worth investing weeks, even months of work into the best possible calendar picker, as it’s the guts of the interaction. In that case the trade-off is worth it. It’s when I see a fancy date picker for date of birth, or a very precise Javascript powered time picker that I think the designer should first talk to the developer.

6. Whatever Works

The goal is great delivery, not great deliverables. No one marvels at great deliverables except other UX designers, and even then they’re only interested when the end result was solid. If you’ve sketched something on a whiteboard that you’re confident is a good feasible solution, that has real data in it and everyone in the project knows what precisely what you mean then there is zero value in re-creating your whiteboard as a wireframe. Don’t be a slave to deliverables.

Other resources

These are lessons learned both through personal trial and error, and also from lecturing and seeing the materials that students present. Here’s a short list of excellent posts about wireframing, sketching and designing.

• Gestalt Principles – Andy Rutledge wrote a great series on the basics of design. 1, 2, 3, 4, and 5.
• Good design faster – Leah Buley has had this as her mantra for years now. Here’s a slidedeck and a podcast where she explains it.
• Sketching User Experiences – Bill Buxton wrote an excellent book a couple of years ago, that covers some of the topics here. It’s a great read, and not just for designers.

May 15, 2012 11:23 PM

May 15, 2012 07:03 PM

I’m still struggling to get up to date with processing my shots, but I am getting closer to caught up than I was a month ago, so things are heading in the right direction at least .

Last time I reported on a steam special (the Maynooth Shuttles), it was to, yet again, say that, despite our hopes, newly over-hauled steam loco No.461 couldn’t make it. Well, that finally changed this time, when she worked her first passenger-carrying train from Dublin in over a decade. She’s not quite running smoothly yet though, clocking up some very significant delays on this rail tour. Still, at least she’s out pulling trains on the main line!

No. 461 is a relatively modern steam locomotive, having been built for the DSER (Dublin South Eastern Railway) by Beyer, Peacock & Co. in Manchester in 1922. She was initially conceived as an 0-6-0 locomotive, in other words, having six driving wheels with no leading or trailing un-powered wheels, however, the DSER ran into problems with similarly sized 0-6-0 locos derailing because they were too heavy for the track, so, the design of No.461 (and it’s one sister loco) was altered, and two leading wheels were added, making her a 2-6-0 loco.

No.461 had quite a turbulent start to her life, spending some time very early on sheltering from the Irish Civil War in Belfast. After the Civil War was over she served the amalgamated Great Southern Railway (GSR), and later CIE, very well until she was withdrawn in 1965. She was restored to mainline running once before, pulling trains between 1990 and 2001.

You can read more about No.461 on the RPSI’s Website.

The two-day Spare Link rail tour kicked off with a light workout for No.461, just a short run from Dublin to the new M3 Parkway station just beyond Dunboyne. This took the train along the recently re-opened part of the old Clonsilla to Navan line, which had closed to passengers in 1947, before being re-opened as far as the M3 Parkway in 2011. I caught up with the special in Clonsilla Station. The junction for the Dunboyne branch diverges from the Dublin to Sligo main line just beyond the station.

The Royal Canal runs next to the Dublin to Sligo main line for most of it’s length between Dublin and Mullingar, and the section around Clonsilla is no different. Just beyond the junction with the Sligo Line the re-opened branch crosses the canal. The original bridge was left in place for many decades after the line closed, but, it had fallen into such a bad state of decay that it was demolished a few decades ago, so a new bridge had to be built. It’s at this new bridge that I caught No.461 as she returned to Dublin with the Spare Link.

When she left Clonsilla she was still on time, and all seemed to be going well, but her day was just beginning. From Dublin she would run the whole way down the east coast of Ireland to Wexford, and that’s when she started to pick up delays. She overnighted in Wexford before heading north again, up past Dublin and on to Howth. Howth is a very picturesque seaside town a little north of Dublin, and is served by a short branch line that diverges from the Dublin to Belfast Mainline in Howth Junction. This branch is electrified, and seldom sees any trains other than the electric DARTs.

The run up from Wexford did not go smoothly, lots of stops because of overheating axels, and, those stops were made more ‘interesting’ by a sticky mid-gear, making starting ‘challenging’. By the time she made it to Howth she was over two hours late. This was a good thing, because the traffic in the area was horrific. Since Howth is both picturesque and close to Dublin City, half the city seems to want to get there any time we get some good weather, and, the weather on the 25th of March was spectacularly good!

I set myself up in Sutton Station, about half way along the short Howth Branch. This is a former Great Norther Railway of Ireland (GNRi) station, and it still retains it’s beautiful original platform canopy.

From the platform in Sutton I was able to capture most of the action near the end of the rail tour. No.461 first passed with the special, followed shortly there after by Irish Rail 201 class diesel loco No.217 running light engine. No.217 relieved No.461 in Howth, taking charge of the Rail Tour for the short final leg back to Connolly Station in Dublin. Finally, No.461 followed the special back to Connolly light engine. I was able to capture all four movements.

You can see all my shots from the day on Flickr where I’ve collected them into a set.

As well as shooting Stills with my trusty Nikon D40, I also shot some video on my new Nikon D5100. I’ve edited the video and some of the stills together into a movie of the weekend’s events which I’ve uploaded to my YouTube Channel. I’ve embedded the video below for convenience:

May 15, 2012 12:22 AM