Design principles for public sector and enterprise mobile applications

15 November 2006 by Rod McLaren

Here’s a working list of ideas and patterns we’re finding useful in designing mobile applications for public sector and enterprise customers. (Not all of these will be useful for enterprise and consumer applications: most of our work is in government and emergency services, so there’s an inherent bias in this list towards compliance.)

Loose constraints allow local solutions
We repeatedly see the value of loose constraints (over rigid workflow) because local solutions either emerge with time, or are there already. So: we design interfaces that are flexible enough to allow users to retain and develop local solutions and customs, whilst remaining contractually compliant. Otherwise the users won’t use the app, and the customer sees no return on investment. See also People over process and IT in mobile workforces.

MIS and reporting might be paramount
The compliance requirements in some projects require that we treat the data and particularly its reporting as paramount – in the sense that if the user performs a task correctly but the reporting doesn’t show that compliance, then there be a non-compliance penalty anyway. So we might start with the data we want the system to output and the views of the data we want the reporting to provide. (Note for designers: this can sometimes feel at odds with user-centred approaches, but it makes sense because it provides a context for user-centred design to take place meaningfully.)

Explicit compliance
Following on from reporting, we’re designing apps that show the user which actions will result in data being saved that is directly measured for compliance. For some services, this might also mean explicitly indicating the status of any legal regulation that may be in force around an activity.

Applications should work offline
Users should be able to continue performing their work whilst off the net, and ideally the application should reconnect and sync up seamlessly in the background, without complaint. Additionally, it may be useful to indicate a user’s own connectivity, and even that of their team members. See also When do we need offline functionality?.

Planning for device heterogeneity
Some services will see the same apps running across a range of devices: execs with BlackBerrys, field sales with rugged handhelds, etc. But even when this requirement isn’t planned, the network operator’s lifecycle may force device heterogeneity upon us, so we try to prepare accordingly. See also: People over process and IT in mobile workforces.

Autosave (vs off-the-record data)
We’re looking at designing interfaces that record everything automatically. The user doesn’t have to “save” or “send” their data or messages because the application talks to the server in the background. (Note that such an interface can be confusing to a userbase whose mentals models developed from experiences with desktop computing, but it can be useful in organisations that are already compliance-centric.) However, there may be a need for users to be able to record information that explicitly doesn’t go into the central datastore, like a scratchpad of notes. At end of the day, they can run through the notes and “save” or “delete”.

Device security vs user friendliness
There’s always a balance to find between security and ease of use. For instance, between having the security of (eg) a PIN-lock on the application or device and the speed of access afforded when PIN locks aren’t in place. And if we’re having a PIN-lock, how often does the device wait before PIN locking? Similarly for the data: should we wipe data from the device at the end of day or the activity? Or keep the data for tomorrow? Which is more valuable – security or continuity? Perhaps the context determines this best, so have this as a setting for customers. Additionally, remote device, security and data management is becoming essential.

Use existing data formats and design models
We’re expooring the use of simple data formats and models that are proven in the real world, rather than creating our own. For instance, RSS and RSS reader software offer a useful design pattern that’s proven: the user can read what’s in their for:user stream when the situation is suitable for them to do it (rather than being unnecessarily or dangerously interrupted). See also (non-)interruptability, below.

(Non-)interruptability
User-selected information and (non-)interruptability: the current activity or situation may best determine what information a user needs to receive or access, more so than a rigid management hierarchy. Equally importantly, a user may need to become “non-interruptible” temporarily, if their situation demands it. Similarly, where a user is in an eyes- or hands-busy situation activities it may be appropriate to bookmark a moment so the user (or someone else) can come back to it later.

Time and geography
Where appropriate, we’re time-stamping and geo-coding all the data that goes to and from the mobile device. Some applications will explicitly show that metadata (see also bookmarking the moment), others may merely use it in their reporting functions. However, note that in low-bandwidth situations this approach may add unnecessary payload to the data being transmitted.

Re-broadcast video
Sharing real-time video and other information can improve the information and decision-making of users not (or not yet) on the scene of an emergency-service situation, as well as laying down a permanent record. Obviously, this requires a lot of bandwidth!

Synchronise watches!
Some organisations and activities require an official time for compliance or regulatory reasons. This implies the use of time servers, which can be complicated if the network operator doesn’t provide access to one.

Contextual, on-demand help
On-site and on-demand help information is contextual (and may therefore be easier to remember than lessons in a training manual), and good insurance against procedural or legal mishaps.

Building technology appropriately for long-term services
Long-term contracts and services may require extremely permanent data, which suggests a focus upon resilience and archiving. Additionally, the customer should make clear when historic data may be safely erased. There is also a need to design all the components of a solution to be extremely replaceable: there should be sufficient abstraction that we can swap out different components and levels of the solution (eg user interface, databases, infrastructure, application architecture, and so on) as we discover new needs or better ways to do things. For no other reason than the fact that we don’t yet know what kind of views we’ll need over the data when it’s a pile 17+ years deep. (See also the Long Now of government IT)

More of these coming soon.

Elsewhere: some useful design patterns for mobile:

• Barbara Ballard’s series on mobile interface patterns at Little Springs Design is great. Her forthcoming book sounds like it will be essential too.
• Matt Jones has this gem on providing input fields but also issuing user ids that are T-9 friendly.
• Welie.com’s mobile UI design patterns.

(And here’s the commercial plug: Mobbu provides mobile applications and services that work for public sector and enterprises. To discuss: email us at hello@mobbu.com or call Alex Laurie on +44 (0)797 643 6630. )

name		Remember
email
http://
Message
	Textile Help

Mobile design: Bookmarking the moment The Long Now of government IT