Here’s the 6th topic you should consider when developing strategies for digital services across multiple screens
More and more people are using more and more screens. Users expect to access information on all relevant screens. Thus digital services require a holistic strategy.
Together with Pascal Raabe, from the UI/UX studio ustwo™ I’m going to introduce six practical tips (in an article series) that can help you improve your own digital products and services by employing an effective multiscreen strategy.
- Think multiscreen
- Know your screens
- Put the user at the centre
- Context is King
- Multiscreen-ready layout and content!
- Challenges are chances
This is the last article of my series.
6) Challenges are chances
Internet, synchronisation, and cloud computing are fundamental pillars of a functioning multiscreen strategy. Think about fallback solutions for poor connection speed, for example in areas with no reception. Watch out for project specific challenges and chances of cross-device and cross-platform concepts in regards to information, interaction, communication and collaboration.
That’s easier said than done. Beside conceptual and strategic challenges you also need to consider the technical requirements. They may change over time.
Desktop, mobile website or app?
There’s always the question whether a pure desktop offering is sufficient (a clear “No” to that) or whether a mobile optimised version is needed. Whether a native application or a web app is the better solution for mobile devices needs to be decided on a case by case basis. When using web apps it depends on the particular project if responsive webdesign or a separate mobile offering is better suited. We already discussed the responsive design approach. It’s a very complex subject matter.
A mobile optimised website reaches a larger target audience. It can potentially be displayed in every mobile browser. It’s easier to find through search engines, often cheaper to produce, and always up to date since there is no publishing cycle like that in an app store. When using native apps on the other hand you have to make a decision which platforms and programming languages you want to develop for. This depends on the target audience.
Mobile web apps are often not discernable from native or hybrid apps. They’re accessed through a mobile browser and based on web technologies like HTML and CSS. Production and maintenance is similar to mobile or responsive websites. They are not dependant on an app store. Changes can be made easily and don’t need to be issued through updates like with native apps. In comparison to native apps there are some drawbacks in regards to performance and using device specific features. A hybrid app is a mix between a web app and a native app. For an independent cross platform approach this is a sensible alternative. It uses web technologies, this means it is practically a web app that is distributed through app stores. This approach allows to create unified applications, that are similar to native apps, for all platforms. However you should avoid to imitate a native application with web technologies as this creates expectations that can quickly result in a poor user experience if they aren’t fulfilled.
A native app might work without an active internet connection. Data can be stored locally on the device. Native apps often provide a better user experience and can be found through the relevant app stores which makes distribution easier. Technical challenges are not as restrictive, which generally creates a better user experience. Native apps are created through the development environment which can be very costly depending on the supported platform. Every platform is based on different technologies and frameworks. Apart from that, you need to consider the interaction patterns, gestures and visual guidelines of the individual platforms and the number and function of the hardware keys on the device.
Whether a native app, hybrid or web app, a separate mobile website or a website with a responsive design approach are the best solution depends on different factors like the purpose of the service, target audience and technical requirements.
If the offering is used infrequently and contains only simple information (for example an article or an annual report), a mobile optimised website is probably enough. Nobody would want to download an app for this. If it is used more frequently you should evaluate whether the app needs to work offline, whether you would like to earn money from it (that’s usually easier through app stores), whether it should be found via search engines or through app stores and whether device features (e.g. camera, location or accelerometer) need to be used and whether the performance and user experience play an important role.
An approach like the principle “Code Once, Deploy Everywhere” is a possibility, however you still need to analyse the different platform cultures, paradigms and patterns carefully. Björn Oltmanns describes these challenges in the conference guide of Usability Professionals.
Requirements, target audience, technology
Other questions to be answered: What are the specific requirements for the service and what is the experience the application should deliver (user experience, corporate guidelines, communication aims)? What is the aim of the service, app or website? What content needs to be displayed? What is the business model? How large is the budget and the the available timeframe? How is the target audience defined? What user types are the target audience? What platforms and devices are used by the potential user?
In regards to the relevant platforms, maintenance and so on: What technology is used? What SDK is being employed? Are the devices and device classes (desktop, tablet, smartphone, TV, others e.g. feature phone) recognised correctly? Are layouts and content displayed appropriately? Is the content optimised for the display on the different devices, screens and applications? In some cases event adjustments are necessary for the different output devices (for example menu handling, native form input for date pickers etc.) and specific interaction patterns are to be considered (hover, click, swipe, etc.)
One last hint:
Live and breath multiscreen and your job will be a lot of fun. It is easier to create appropriate services and future friendly concepts when you’re frequently using multiscreen services and ecosystems in your personal life instead of only picking them up when you need them. Bringing your own experiences to the table makes your research a lot easier. You’re doing user research on yourself.
Outlook and conclusion
There will be a lot more interfaces and internet-connected devices (e.g. wearables, glasses) in the near future. This will lead to an even more fragmented multiscreen environment, and that fact should, and must be considered when designing and planning multiscreen-projects. It won’t be any easier, but will be even more exciting for designers and developers to work on digital projects in the future.
Let’s close my article series with a quote be the great Josh Clark:
“A part of multi-device strategy is simply embracing the uncertainty.”
– Josh Clark
That’s true! Enjoy the uncertainty and think multiscreen! 🙂
Any questions? Just send me an e-mail.
With the „Multiscreen Experience Design“ project we gathered and developed a number of patterns, methodologies, and insights and compiled them in a book (published 2013 in German by digiparden, an imprint of SETU GmbH). In this article series I introduce(d) some important aspects of a useful and user-friendly multiscreen offering.
Update (12/14/2015): If you’re more interested in the topic. My new English book “Multiscreen UX Design” is available sind 14th December 2015.
Tip (if you understand German): URL of the German project website: www.multiscreen-experience-design.com