/Resources//How to Mobilize Your Self-service Portal

How to Mobilize Your Self-service Portal

90% of consumers expect brands to have an online customer self-service offering, according to a Microsoft study; 60% of them said they have a more favorable view of a brand if that self-service offering is mobile responsive.

True, it pays to make your portal truly mobile, with proper scalability to all screen sizes. Evidence from market studies backs up that opinion: According to a study by Adobe, 65% of information workers in the US reportedly used a smartphone or tablet for work in 2014 and now the figure is higher. In developing economies, mobile has already for some time been the first, often the only screen for accessing the Internet, according to studies by Pew.

But how to make your self-service portal work on a handheld device? Here are some ideas for self-service content portals for accessing documentation, training material, bulletins, spare part information and so on, based on our hands-on experience:

  • Start from the mobile design, then expand to wider screens
  • Use search as the sole access to content – at least at the beginning
  • Ensure that it works over low bandwidth.

No-frills for high thrills: start from mobile design

This is an idea I heard a few months back in an excellent presentation by UX designer & coach Jan Krebber: today, a web service should really be designed first for the handheld screen. And why not? On a handheld, there is only space for what is truly essential. Start from those core functionalities and do them well, as well as you can. It is easier to expand the design from small screens to large rather than vice versa.

Such an approach also allows – possibly – for faster rollout of the portal: when that first, basic version is ready and properly tested, it can be launched. Additional functionality for wider screens can be added gradually later on. It might also work for the handheld, now that the most important things have been allowed to take the center stage.

Simpler, quicker content access with search

How to make finding and accessing the content in the portal sufficiently easy and fast on the small screen? Tree-like directory structures tend to require a lot of space, so they do not work that well in the mobile context (they pose other challenges too, but more about that in another article).

More and more companies today are abandoning such approaches in favor of designs that feature a search application as the backbone of the portal and the sole access point to content. It is not difficult to place a field for keying search words and a few drop-down menus for selectable search filters on the screen. Cleanliness and clarity of the interface layout will not be compromised. User satisfaction has been reportedly high for a few of such implementations.

Lighten the load on network

And what if a user ends up in a crowded network or at its very edge, with weak coverage and low bandwidth? Is there a way to make the content lighter?

Some of today’s search applications made for powering up portals can generate lighter previews of documents. They allow users to view and download just those pages of a document that feature the search words keyed in by the user.

So if a 350-page document has just two pages with hits, relevant to the user (a true-to-life scenario, isn’t it?), transmission of just those two will consume network capacity. Even when the connection is faster, this ensures quicker delivery of the results.

Start with minimum viable lovable product

Getting back to the presenation of Mr. Krebber, he also emphasized the importance of making the first version of a service the minimum lovable product (one that truly pleases and benefits the users), as opposed to the oft-heard minimum viable product (a no frills, no thrills offering at worst).

Ok, easier said than done. However, one would think that limiting the scope by concentrating on handheld can really make it easier to achieve this.

A robust, versatile search application like Documill Discovery can too, we believe.

By | June 9th, 2016|
Follow us