Designing Mobile Apps for the Enterprise
•Download as PPTX, PDF•
1 like•837 views
The document discusses designing mobile apps for enterprise use. It describes the enterprise mobile apps team at Genentech and some of the apps they have developed, including Site Explorer for finding locations on campus and Signal Me for conference room booking. It emphasizes designing for people by understanding user needs, designing for performance to optimize for mobile, and measuring engagement to understand what features users interact with most. Examples are given of analytics from the Peeps collaboration app that show high returning user rates and most common actions. The document advocates designing lightweight APIs and offline functionality to improve performance and usability.
Recommended
Recommended
More Related Content
What's hot
What's hot (12)
Similar to Designing Mobile Apps for the Enterprise
Similar to Designing Mobile Apps for the Enterprise (20)
Recently uploaded
Recently uploaded (7)
Designing Mobile Apps for the Enterprise
- 1. Designing Mobile for the Enterprise Christian Santiago
- 2. About The Company Considered the founder of the industry, Genentech, now a member of the Roche Group, has been delivering on the promise of biotechnology for over 35 years. At Genentech, we use human genetic information to discover, develop, manufacture and commercialize medicines to treat patients with serious or life- threatening medical conditions.
- 3. The Enterprise Mobile Apps Team Tech Leads App Analyst UX App Analyst Developers UX App Analyst
- 4. Devices and Apps iPad 25K iPhone 40K >1K Galaxy 300 Apps
- 5. Design Thinking Design for People Design for Performance Design for and Measure Engagement
- 7. Site Explorer • Location based app for finding buildings and services on campus. • Includes cafeterias, health and wellness, emergency contact numbers. • Employees travel, so we need to integrate multiple locations.
- 9. App Design
- 10. Signal Me • Conference Room booking on the go. • Information displayed based on proximity. • Very new technology not well known to our colleagues.
- 12. Test Results
- 13. Off My List • App to approve high dollar finance transactions. • One part of a more complex business process. • Built on the SAP ERP system.
- 14. App Design
- 15. The “Happy Path” • The intended audience really can make a decision at a glance. • They might just want to get it done from the transaction list. • Provide a swipe interaction, with no confirmation to approve.
- 16. Subject Matter Experts ≠ Users
- 17. Audience Research • Identify your audience and separate them into segments. • Look for problems and pain points, not requirements. • SMEs are a great resource, but are not familiar with paint points.
- 19. SOA Is Not Your Friend • Uses data formats like XML, OData with large payloads. • Requires too many HTTP calls. • Often dumps entire tables with unneeded information. • Too much metadata!
- 20. Keep It Light • Use what you have to manufacture APIs. • Make the meaningful, lightweight and self describing. • Reduce the number of HTTP calls made in apps.
- 21. Smart Data Load • Delta algorithms server side can reduce payloads, serving only new or changed information. • ETag headers and http response codes signal the app that nothing has changed. • Use background loading in iOS7 to allow the app to be used when new data are loading.
- 22. Offline First • Use the SDK or the browser to store information on the device. • Let consumers of your app know that information can be used offline. • Detect weak or no connection to preserve battery life.
- 23. Site Explorer
- 24. Peeps
- 25. Data and API Design • Use lightweight APIs and reduce the number of HTTP requests. • Load and update with the audience and the constraints of the device in mind. • Think through the use cases when people are offline.
- 26. Design for and Measure Engagement
- 27. Peeps Usage Stats • 20,000 Users • 94% Returning • 70% of all sessions outside the corporate network. • Top Events: Contact Someone, Search for a Person, Add to Favorites
- 28. Callback Lessons Learned• 98% Returning User Percentage • Dropped VPN Requirement in Q1. • Usage climbed to 60% off the corporate network. • Top Events: Listen to a message, delete a message
- 29. Design Lessons Learned• Sharing is a small percentage of the events we track across most of our applications. • These features do not appear to be easy to find. • Do not invest resources in these use cases when defining roadmaps.
- 30. Measure App Usage • Measure ROI in terms of usage and engagement, not downloads. • Track specific events to find out what features work and which don’t. • Use statistics in product decisions: future investment and feature roadmap.
- 31. Good Bad Feedback “Dear colleagues, Thank you for creating Peeps, the greatest app in the Roche/GNE AppStore. Unfortunately since you introduced the latest update I am unable to log into Peeps. Could you please advise how I can use Peeps again? Thanks a lot!”
- 32. All Icons Provided by the Noun Project iPad by Daniel Cell Phone by Alex S. Lakas Icon Template by Dimitry Sokolov Team by Wilson Joseph Gears by Dasha Shevyrenkova Nuptial Bed by Luis Prado Radio Tower by John Caserta Map by Jonathan Higley Check Mark by Jardson A. Curious by Stephen Borengasser Divorce by Luis Prado Feather by Sofía Moya Yield by Mike Jewett Disconnected by Ugur Akdemir Database by Shmidt Sergey Share by Benni Analytics by Christopher Holm- Hansen
Editor's Notes
- I will discuss best practices for designing and building mobile applications for the enterprise. I will not discuss specific technology platforms or frameworks for building apps. Whether you build iOS, Android or cross platform apps, these principles will hold true.
- A bit about the company. We are considered the founder of the Biotech industry. We were acquired in 2009, and are now a member of the Roche group.
- My group is the enterprise center of excellence for mobile in the company We are a global team, with team members across the world. Our apps have a global audience. We have other mobile development groups in the company, dedicated to regional and line of business groups.
- We have a large scale device deployment, globally. 65K and growing as of last month, and growing Mostly iOS devices. We have 300 apps in our internal App Store developed by multiple teams across the IT organization. We have learned that people have come to expect the same experience they get from consumer apps. Our apps sit side by side with our users favorite consumer apps on the phone’s springboard. We have to meet the same expectation of quality.
- Getting the consumer experience requires design thinking through the entire process of building an app. People: it’s not enough for apps to be easy to use, they have to make a difficult task easy to do. Performance: unlocking enterprise data and getting it to a mobile device is also a design challenge. Engagement: we don’t want people to just download our apps, we want them to love them, and keep coming back.
- It is crucial, before building an app, to talk to its intended audience. Before we start, we do a fair amount of research. The amount and type of research we do depends upon the problem we are solving. Sometimes, we are taking a business process, or part of one, mobile. We also create apps for general productivity. In these cases, we are attempting to solve problems people don’t know they have, but are begging for a mobile solution. Either way, we have to figure out how to make tasks on a phone or tablet easy for people to do.
- Our team was approached by the site services in South San Francisco to create an application. They realized that campus info is a problem for people who travel. Employees who work in SSF are not necessarily aware of how to get around and find services on campus. There is a large amount of information, but the question becomes how to organize and display in the app.
- To understand this, the UX team in SSF did a card sort exercise. They ran focus groups in both Basel, CH and SSF with people who travel, who are parents, who have long commutes. They wanted to find out how to organize the information so that these different personas can find what they need. Dots signify priority for that person, black ones are pain points. This tells us what to choose for inclusion in the app.
- The design, then focused on finding things, with a map based interface. The application also cross references important information. Cafeterias can be found both under the food category, but also when looking for a building.
- One of our early iOS apps is called Get A Room, built for ad hoc conference room booking. It can be hard to find a place to meet. We wanted to update the app, and integrate global locations. We also wanted to add some proximity based info to the app. People move around a lot, both on their home campus and when traveling, it’s not always readily apparent what rooms are available or where they are located. To do this, we use iBeacon technology released by apple in iOS7. Low power blue tooth devices that present info when you are close to a conference room.
- The research for this app is prototype testing. The app that finds conference rooms, their disposition, and allows for booking. The beacons link the conference rooms to the sensor, and return a list of conference rooms within a short range, rather than a pick list. We wanted to understand how people understand what they can do with the information, and how the beacons are impacting the experience. Do they work?
- The beacons worked great; they were easy to configure, we connected to them and got the right information. The UX team tested with 12 people. The “Free Later” terminology was confusing to about half of the people; should change the label. 75% of the people in the test group did not get that they could tap the word “book” and get the conference room right now. So that needs to be redesigned. These results were consistent after they talked to six people; you don’t need that much data to draw important conclusions and make necessary changes.
- We built an approval app on top of SAP, on an existing business process. The design challenge is different; so the research is different. We talked to a few key people in the audience for the app about their concerns and needs. The use cases remain the same, people need to view pending approvals, approve and reject, leave comments, view history. It’s their implementation that is different after researching the business process.
- The resulting design privileges the right information for easy, at a glance decision making. When we talked to the app’s audience, we found out that the transaction type, the dollar amount and the vendor were the most important pieces of information to see right away. Making the right decisions about what to show, and where can make a big difference. Feedback, “this will change my day.”
- SMEs told us that they MUST HAVE an ability to approve all. But bulk actions are really hard to do on a small screen without unintended consequences (rogue touch events, bad queuing). So, we talked to the audience to find out what was beneath that request. They told us that they don’t more information a lot of the time to make a decision. The swipe lets people make a quick decision without a lot of drilling down or confirmation.
- We see this come up over and over again when we set out to design an app. The person that knows how the system is supposed to work is blind to all the ways people are working around that system. The SME will get you to the base use cases, but will not be able to tell you how best to implement those use cases in your mobile app.
- Designing for the people using your mobile app requires you to be a curious observer of their behavior, their problems, and their true needs. Doing some amount of research, we have found, is essential to get the app’s design right.
- Once we have a solid interaction design, we have to think about what is happening underneath that nice UI. How are the data and content making it to the app, and what happens once it gets there? Mobile devices are underpowered computers with intermittent access to networks. If people have to wait a long time to use your app, they will abandon the app. Thinking about performance in the design process will help you avoid this scenario.
- Enterprise SOA is not your friend — you have to break up with it. These integration tools are geared toward system to system communication. They often don’t allow you to consolidate data or combine information from several systems. Enterprise systems that supply APIs are designed to simply dump data from their base tables. They don’t know how you as an organization are using the system.
- There are no magic tools that will create APIs that are appropriate for mobile. Use lightweight formats like JSON and reduce the number of http calls made where possible. JSON is self documenting; it increases developers understanding of a business process that may be entirely new. It’s a faster development cycle.
- Think about storing data within the app and getting deltas from the server. You can also use eTag and 300 response codes to signal the app that nothing has changed in your API Background loading allows use of the app before all the data are present.
- The delta techniques assume that developers are thinking offline first. In mobile, there is no such thing as an “online only” scenario. Our global users often have less than good connections over wifi and cell networks. In Europe, people can work in a different country than the one in which they live, causing daily roaming.
- Site explorer stores data locally and does a delta update. The first time it is opened after download, it displays a splash screen while enough content loads, the displays the home screen. The app is immediately available. Thereafter, it loads data incrementally based on changes. The small spinner in the iOS toolbar shows that something is happening, but users don’t have to care. Works offline, because we want travelers to be able to find things when they turn off data roaming.
- Peeps is our most popular application. It’s a global company directory. All data are downloaded and stored on the device. It background loads the delta between what is there, and what has changed in our directory. On my profile, the only thing that loads real time is my calendar free/busy. That needs to be updated frequently, but employee information changes very infrequently. Sometimes once or twice a week.
- In summary, backend and data design are just as important to a great experience as the UI. Spend some time up front thinking about how this should work.
- Once the app is built and released, we want to know how it’s doing with our employees. We build analytics into our apps to measure how many people are using it, and what features they are using. Our only real measure of ROI is usage, so it is important to capture some statistics.
- The best app experiences are sticky, people come back to the app a lot. Peeps application is easily our most successful app The stats tell us how many people are using this app over time, how engaging it is, and what features are being used.
- Callback allows employees to listen to messages left on their desk phones via the iphone Strategic use of push notifications lets people know they have a new message Stunning returning user percentage We made a mistake in the first rev by requiring people to be on the corporate network. Removing this requirement saw a huge uptick in usage
- The stats across many of our apps tell us that sharing is not popular. It could be that they are hard to find or that people do not care. While it adds something extra to the app, it should not consume a lot of our time and energy. This is an example of how analytics are used to drive product decisions and roadmap. These features are not revisited when we come up with the product roadmap.
- To sum up, measure return on investment using a fact based narrative. Use the statistics also to justify future investment in a mobile app, and to drive what functions are important to the user community.
- We love getting feedback like this; it tells us that people are engaged with what we have built for them. The bottom line is that, even though we are building apps for employees, they still have a choice in what they use to get work done. For this reason, caring about getting them as close to the consumer experience as possible is a worthwhile goal.