One example of the many faces of a mobile app created at Dynamic Signal 2013-15.
This project outlines steps taken at Dynamic Signal in launching their mobile web, native, and Salesforce app integrations. For more information on the web version of this product, check out the advocacy section.
There were some obvious benefits a native application would bring to our product including deep linking from web, single sign-in, remote link overlays, and an environment exclusive to teams already on the platform. Metrics such as daily actives, email clickthroughs, and content sharing were utilized when evaluating our approach relative to web. Below shows some wireframes created to show topical amongst teams.
As part of the transition from desktop, we added some baseline media queries for landing pages, dashboards, and detail pages. Oftentimes users receiving links would access them from mobile web in a signed out state. Our first touchpoint with them would be either going through login or browsing content in order to prompt a signup. Below shows two of these common flows for creating new communities and setting up connections on existing sites.
The mobile web conversion worked especially well when importing webviews into other native apps. This was largely the case when working on the integration for Salesforce Chatter. For the manager case, we focused on broadcasting and reviewing content. For users, we looked at connecting accounts, browsing streams, and reviewing activity. Both of these flows were piped through the Chatter app using a combination of native components and mobile web views. This offered an alternative view of our existing web product and another example of the interoperability of the platform.
For our early native application, design used multi-step flows and detailed spec mockups. The long-term maintenance, templating, and documentation of all features on a configurable platform quickly added to the time. Below you’ll see a basic flow for a broadcast feature in two different configurations along with a feed/detail view with different types of post types.
Having worked alongside our iOS and Android developers through multiple launches, we gradually moved to native prototyping of new features. This doubled as a way to test transitions between views and served as a design spec for secondary features. Design could explore different iterations (without disrupting the build) and setup specific versions based on approval.