Mobile for B2B: Design Considerations Page

1

Mobile for B2B Design Considerations August 2011

Rajen Mistry & Rob Hurst

Mobile for B2B: Design Considerations Page

2

Intro Mobile for B2B Series This paper is one of a series we’ve written to help answer some of the questions we often hear from clients now that mobile content is firmly on the B2B marketing agenda. Web apps or native apps? How to optimise content? What should an app look like? Why might I need an app and how can it benefit my marketing activities? This series aims to give some useful context for anyone considering how to make the most of mobile as a marketing channel.

1. Native or Web?

2. Design considerations

3. Security considerations

4. Cross compiled apps

Mobile for B2B: Design Considerations Page 3

Introduction There are many considerations in planning the use of mobile as a marketing channel – deciding what content to optimise, what functionality you need, what audience you can reach and whether you should develop a native or web app.

All of the functionality and technical decisions that you’ll need to make have an impact on the final user experience and design. Sometimes the design requirements are going to lead the way – and define the technical approach. Sometimes the technical approach will need to lead – and in doing so will define some of the design requirements.

There is no right or wrong approach – the decisions can only be made taking into account what your app needs to achieve and who your target audience are – but having some awareness of the design considerations when planning mobile apps and some of the restrictions of different approaches is important in selecting the right approach.

The fundamental choice is the one you will make between web or native app; choose to optimize your app, what your app does and what it looks like by choosing the right platform for it.

There is no definitive answer to choosing the right platform, from a design or any other perspective. In this paper we want to outline some of the considerations in designing for each approach, what can be achieved with each approach and some of the inevitable limitations.

We hope they will help inform your planning and decision making – and open up some of the possibilities of designing for mobile content.

Richer User Interface Native apps allow for a richer and more beguilingly beautiful interface, nothing is left to chance because the device though which the user will experience the app is known and it is possible to control exactly how content behaves – there are pit falls though, it is possible to get caught up with what is possible and forget your user and their needs.

Conversely with web apps, the act of trying to optimise content for the range of smart phone devices now available means that there is often a huge technical challenge in maintaining a consistent design across all devices.

The rich design experience that can be achieved in native apps can be exploited to allow for a potentially better, more immersive brand experience that enables you to reflect your business USPs and values across a new channel.

With a native app you can either borrow from the devices user interface (UI) standard or replace these ‘normal’ UI elements with your own brand’s look, in doing so you can create a true-to-brand visual look & feel to include colours, fonts, graphics and even animations, where appropriate.

Mobile for B2B: Design Considerations Page 4

In these examples a custom design to replace the standard iPhone UI has been applied but wisely kept in the same location keeping the experience familiar and consistent. Where symbols are less intuitive labels ensure a clear user experience.

This example is an obvious departure from the orthodox and there’s no guarantee that users would understand it without sufficient testing.

Mobile for B2B: Design Considerations Page 5

It’s important to bear in mind though why those device specific standard UI elements were created - be careful to do them the same justice with your replacements, as the standard UI elements have usually been thoroughly tested for how they look and feel, and what they do. Consider whether it’s obvious that the user can interact with and touch something, click it, or swipe it. Is it legible? Can you read or interpret what it asks you to do? Is it even big enough, in fact, for fingers to interact with?

SyPhone app takes the UI in a completely bespoke direction, using family components in a different way – good or bad usually the user decides very quickly.

There are so many possibilities and variables, it is possible to get carried away, always keep the end user in mind and be aware of the actions and behaviors they are familiar with and will understand.

The Holy Grail is to create an app, whether native or web

based, that the user can use intuitively.

Design Efficiency It may look like an app but will it work like one?

On the whole UI design for web apps can be visually similar to a native app counterpart. However, performance is a major factor when trying to mirror the user experience of a native app with a web one. Not having the power of hardware acceleration and slow connections can mean that the design elements make the app slow to respond and lagging the user interaction, things may not move as you expect or load as quickly as you, and your user, would like them to.

Designing an app for the web means designing efficiently and not expecting more of it than the device and connection will be able to deliver.

‘Oh no’, I hear you say, does this mean my web app has to look boring and simple? Far from it actually, a good example of this comes from Facebook, if you compare the Facebook web app to its native sibling, it looks almost identical; the brand identity comes across clearly as does the intuitive experience of the desktop browser version.

Mobile for B2B: Design Considerations Page 6

Facebook’s native app

And its web app sibling

Simplicity Simplicity should be the goal for web apps; just as with native apps, they need to perform a task and perform it well. It is important to

understand what the app is trying to do and reflect that in your design approach. Far better to design a simple app which works well and is easy to use, than an overly complicated one which fails on user experience. So whilst you are limited in some cases, it’s best to concentrate on making sure the app does what it’s supposed to functionally, but maybe without some of the bells and whistles a native app’s device can provide.

Factors to consider include whether you really do need to fake a finger-swipe (when the screen contents move not with your finger, but afterwards), when you can simply scroll? Do you need to be able to delete by swiping and clicking if you can just add a delete button?

Conclusion The challenge for user experience design is the same for both native and for web apps and always comes back to the user and delivering the best experience for them. Ultimately, once you make your choice on platform, there will always be a way to create a design to effectively deliver and subsequently optimize what you want to achieve with your app.

It’s ok to let your creativity flow but don’t forget to be true to the choice you made in the first place, and the design considerations that come with it.

Read the rest of the Mobile for B2B series.

1. Native or Web?

2. Design considerations

3. Security considerations

4. Cross compiled apps

Mobile for B2B: Design Considerations Page

7

Omobono is an award winning digital agency specialising in brand development and engagement for large corporates and government. We believe no one has a better understanding of business audiences and how to reach them.

For more information, please contact Rob Hurst on rob@omobono.co.uk or +44 (0) 1223 307000.

© 2011 Omobono Ltd.

All ideas, concepts, brand-related names, strap lines, phrases, copy/text and creative concepts developed and contained within this document remain the intellectual property of Omobono Ltd until such time as they are procured by a third party.

Anyone viewing this document may not use, adapt of modify the contents without our prior consent.