Remember when every unit, division and subsidiary in an organisation thought they needed their own web site? Local IT technicians with their own servers under the desks. Dreamweaver. First page always about the ”happy gang of 23 employees” eager to promote themselves. This was 15-20 years ago.
Today most organisations have reached a higher level of maturity. Most leaders and stakeholders realise it’s a good thing to have a coherent service offer on one web site, just like organisations need one economy system and one HR system in order to succeed. One CMS, a centralised operation of load balanced, clustered servers. Leaders and stakeholders also see that the services offered to the end users—and not the units’ presentations—are the key to a good user experience. A shared solution is better than 100 different solutions.
So far, so good. 1—0 to the web and intranet managers.
But today, we have another war to fight: native apps.
In almost every organisation I’ve had the opportunity to look into, I hear the same thing. A local employee or a local manager, responsible for business development in a subsidiary or unit, has a new idea about an iOS app ”so we can provide our service in an efficient way”.
But almost every time the native app they are planning for is a badly built extension of the old core system or something built on a weird stand-alone platform. Focus is on communicating one single thing—what the unique little group wants to say. Often the employee/manager with the app idea forgets that there are more platforms than iOS to support and that s/he also need to have the service on the existing web/intranet platform. There is no thought about the future cost of hard and soft maintenance. Focus is on solving the sender’s needs, not the end users’ needs. This will create a silo with isolated technique and forked content. The mindset is narrow.
For every separate mobile version you’re building and maintaining, a separate tablet version and TV version are right around the corner. No matter how many versions you support, if you’re using separate websites, you’re supporting too many. Drew Thomas
For me, it’s obvious this is the history repeating itself. Web and intranet managers have had this fight before. Back then it was ”our own web site”, now it’s ”our own app”. Ultra-local solutions like this was a bad idea 20 years ago and it is a bad idea now. It’s like Amazon would build a different app for every department\category of merchandise they have (because different units can’t cooperate) and as a result the customer has to download several apps and make isolated purchases in different ways depending on what app the item is in. Instead, when speaking about the employee experience, we should make everything accessible from all devices and use the intranet as the enterprise front door. (Steve Bynghall).
But right now this is not obvious to people dreaming about apps. It’s the Wild West again, in the name of modern ”digital transition”. And in some organisations I hear about IT departments having difficulties resisting this tidal wave of app requests, although every enterprise architect knows silos, forking and OS-specialised solutions are wrong.
The reason a separate mobile website is dangerous is that, in general, you want to avoid creating multiple versions of your website. It’s called forking, and it’s a forking nightmare from a maintenance perspective. If you fork your website into separate mobile and desktop versions, then you’re stuck updating both every time there’s a change. Karen McGrane; Content Strategy for Mobile
I’m convinced this phase can be short with the right reasoning, a good framework for employees and managers to follow and a good idea about how the single, organisation-wide IT platform for the mobile presence should be constructed. Comms, the IT department and the resources involved in Digital transformation should work together on this and it must have high priority. Or else your organisation might soon end up with hundreds of native apps doing one thing each, not sharing data and editorial content with each other.
And that is a really bad vision of the digital future.
///
So what is the solution if you do not want 100 apps?
- Digital transformation is governed centrally by a cross-functional competence team. The team selects, refines and builds the best ideas from the organisation.
- Every business system should have an API.
- The organisation has a framework for how to build device agnostic and how to handle mobile devices. In my opinion the best solution is using the RWD web/intranet as the sole place for digital service. A native app could be the right solution for a specific expert need, but not for ordinary end user needs.
Why your agency (likely) doesn’t need a mobile app (18F, U.S. General Services Administration)
A separate mobile website? No forking way! (Karen McGrane)
Going OS native often also means 3x the cost and maintenance, building every service three times—one on the web, one in iOS and one in Android.
We need to be device agnostic in our service offer. (Sarita Harbour, Webdesigner Depot) - IT provides core components (single sign-on, user database, integration engine, server, et cetera).
- Comms provides the primary surfaces for the digital services (= the web site and the intranet).
- Services and data from the business systems are brought together—via the core systems’ APIs—on the web site and the intranet, with the recurrent use of the core components from IT.
Leading digital workplace teams are building their own enterprise front door (James Robertson/Step Two Designs) - When developing solutions, always think customer journey, employee journey and end-to-end services. Always test ideas with the real customers/users.
The employee journey is just as important as the customer journey (Enterprise Strategies)
What we need to do to support end-to-end services across government (Government Digital Services) - Avoid having ”hey, let’s build an app” employees leading the digital transition.
Jesper Bylund – Intranet Manager 