Today's Nerdery webcast was hosted by Ryan Carlson and centered around mobile application design best practices. Specifically, Meghan Casey, content strategist, and Hannah Grossman, user experience designer, explained and answered the audience's questions regarding their workflow when a client comes to them with the ambiguous statement, OMG. We need a mobile app! Both Meghan and Hannah currently work at the Nerdery.
- As of March 2112, 50.4% of U.S. mobile subscribers owned smartphones. It has become our job as user experience designers to craft successful products accessible across these platforms.
- Part one is to validate the idea of why you need to have a mobile application or responsive web presence. Find the source of the mobile request by going up the management chain. Conduct meetings with key project decision makers and all people who can inform decisions on your project at anytime down the line. Then, answer the question; what are the goals of this mobile "thing"? It's very important to get everyone on the same page concerning the expectations of the mobile experience. Be sure to take detailed notes to references later, in case things get hairy.
- At this point, your team should answer some primary questions. Why do we need it and what should it do? Answering these should include a competitive analysis of the current market, feature inventory and analytical review of the current web presence.
- When conducting a competitive analysis, be sure your product owners don't want to copy what's already out there just because. Renforce the idea that you should always adhere to user experience best practices and build the best product possible.
- Consider that your site may rely on 3rd party services; be sure to know up front if and to what extend you can influence these applications. It can be very important to choose the best ones up front or know your mobile limitations if you are reliant on these services.
- Use analytics of your current site to determine primary and secondary device support. Primary will be pixel-perfect guaranteed working designs based on market share of your analytics. Secondary will work, but not on a pixel-perfect level. All devices outside of those defined have no guarantee. This can help to manage expectations.
- Overall market share should not influence big design decisions. Directly reference your analytics to determine the most important devices to support based on your specific user base.
- Once you decide that you do need a "mobile thing", have a creative brainstorming session to hash everything out. Include the previously identified stakeholders in this session. Here you should generate ideas and create wish lists for the mobile experience. Be sure to have a comfortable session where people can get all of their crazy idea out on the table.
- Next, try to determine what your users want or expect from a mobile experience. Do user research at this point to compare what you're planning to build, versus what the core users would expect to see you build on a mobile platform. Always be sure to target your audience, don't make major design decisions based on nothing.
- Decide if you should build a native mobile app or a responsive/mobile optimized website. As you discuss the features initially, think about which platform would be most useful for building out these features. Do you need to leverage device capabilities such as camera, accelerometer, etc?
- At this point, you get to buld the thing! Next steps are: project planning, requirements definition, information architecture and visualization of your "mobile thing".
Q & A Session:
- Q: Does HTML5 really solve the problem of OS diversity?
A: Depending on the application - HTML5 apps for mobile can help close the gap. I find that HTML5 applications that are more 'focused' are best in this case. It's a growing standard that meets a lot of needs but may require prototyping or a proof of concept.
- Q: iOS versus Android... Our potential app should be designed for both platforms. For development costs, can we assume the cost would be doubled to offer it for both?
A: Great question - Native application costs for native applications are in 3 buckets. Visual Design, Back End, and the Database. Visual design is made twice since Android and iOS has different nav and layouts, but you can reuse (some) of the elements. Back-End is generally going to be a unique snowflake for each OS. Database (server side) and push services, data access, API tie-ins can generally be re-used depending on how it's built - but planning for BOTH up front is smart.
- Q: How can you measure the success fo a mobile experience?
A: Metrics. Which specific metrics depends on what the client has is perceiving as successful for this specific situation. Also look at user research, app store reviews, etc. Many things contribute to success.
- Q: How difficult is it to get approved by the Apple App store?
A: High level, Apple doesn't want an app to simply be a wrapper of your website. Wants to see a use. Don't like just a website. Don't want it to drain the battery! Something that one of their own offerings doesn't already use. They have design standards.