Feature overload: A brief critique of “AIA Vitality”
A header included in the iOS version of MyAIA
The current market trend of developing apps that let customers interact with services instead of over the web has been largely very successful. However, many traditional companies are having difficulties with transforming their predominantly web based service portals to apps with well intentioned design and a convenient experience.
The app our group has chosen, AIA vitality, is a perfect example of a poorly implemented mobile implementation of a preexisting web based service.
The app primarily serves two purposes.
a portal for customers to understand their current insurance plans and coverage.
a utility that uploads fitness activity data to the premium adjustment algorithm of the insurance company. The goal of the entire fitness service is to incentivize healthy habits by rewarding fitness activity with lower premiums.
The apps designers should have considered how the user experience can be complicated when two services and feature sets that are highly unrelated to each other are combined. This doesn’t necessarily mean that AIA designers should have made two apps, it simply is a reminder that consolidation without prior research into how the two different feature sets could effect one another.
Above is a photo that clearly shows the “overload” of features. Too many choices or options can potentially lead the user to become confused or sapping their valuable in-app time trying to navigate rather than complete their desired task.
The overall combination of graphics and typography choices indicates that the developers utilized a web view app design that takes JavaScript code and creates mobile apps for iOS and Android. It allows the developer to write in one language for two different platforms and decrease the time to market for new feature sets. However it is obvious after checking the online version of myAIA that the mobile app is a web view implementation of the responsive mobile format of the desktop site. There is obviously Very little design work going into the end use product in the app. This is more than likely in an effort to reduce cost.
Above is a photo of a side by side comparison of the web portal (left) and the app based portal (right) this photo does a good job of showing how the app was quickly produced to mimic the online version but neglected designing for mobile specifically.
In conclusion, do large web based services benefit their customers by offering a mobile app for a predominantly desktop based service. Just because you can make the mobile app doesn’t mean you should. MyAIA vitality is a perfect example of can but shouldn’t.