OneNet - Native IOS, Android App

Jan 2018 – June 2018

OneNet is a standalone organization of one of the world’s largest economy/superpower. Its aim is to develop, build and operate the nationwide, broadband network that equips fast guardians (FG’s) to save lives and protect communities countrywide.

In order to do so, they required a mobile support which will allow FG’s handle critical situations like terror attacks, fatal accidents, and community gatherings by collaborating through mobile (handheld devices) application.

Outline

Primarily, OneNet expects this platform to meticulously cater the FG’s critical requirements like, manage incidents, and receive push notifications from Case Manager (CM), request incidents access and many more functions.

My role was to handle end to end product development from a UX point of view. Wherein my key responsibilities were, understanding requirements, amending them if required, designing UX strategy from research till development and mentoring/managing design team. It had largely native features, however, borrowed few browser-based functions like self-device diagnostics etc. It had a great scope due to extended platform for various iOS and Android devices (Expandable up to dedicated OneNet devices in future).

It was a quite good experience to define a design team, do resource loading at different phases and craft a product by confronting various challenges. The primary challenge was to empathize fast guardian’s needs as this was first imitative to equip them with a platform to make the best possible use of the fastest inter-operable public safety broadband network.

Considering limited access to FG’s we shared our insights over few video conferencing and series of emails chains. Here we analyzed and assumed different on, off-field scenarios for them. After initial brainstorming with business and users, we finalized key user profiles. These where fast guardians representing primary user and case managers (CM) representing admin user and various secondary users (volunteer FG) as per role. FGs can be of different government job profile personnel’s like firefighters, police, soldiers, paramilitary forces etc. and to volunteer, there were no any prerequisites.

Following where few of tasks we thought off,

  • FG’s shows up at the incident/case
  • Wants to request case access
  • Reports to duty and checks list of active local cases
  • App (case manager) sends a pull notification to the FG connect to the specific Incident
  • Case manager approves the addition request by FG to a specific incident
  • The app will guide the User to different diagnostic steps depending on the issue.
  • Role management by CM
  • Live chat support during the non-emergency case

Owing to various limitations like tight timescales, minimal user involvement etc. we planned research in a linear way than a traditional UX. 

Mapping UX with Agile Development

I can say, this journey was rapid, iterative and hypothetical. I was involved in a sprint planning and was not surprised to see not time for a research, hence planned deliverable in a way, where we came up with assumptions for user needs and prioritized them by their impact. There were very few instances, where we got the feedback from actual users on research we did. In a nutshell, process was to visualize solution quickly and test with users, iterate if required before implementing it. Further, develop the MVP, and conduct a quick sprint demo. Frequent communication with the product owners, developers and users was my key task which helped to keep away misunderstanding among team members and increase efficiency. The crux of the matter was to be two to three sprints ahead of development teams which was a vicious cycle as always 😀

In initial sprints we catered push notifications and dashboard view for FG user which was most crucial. Owing to tight timelines I was quickly sketching solutions, checking remotely with business and few user and was coming up with the annotated wireframes. We had an agreement with OneNet that solution will be developed for primary devices (apple devices) and will be replicated for android. Hence I created annotated wireframes in a PDF format for iPhone and iPad devices. This exercise was fast, easy to share and manage.

There where situations, where solutions where not perfect, which was ought to happen due to rapid and very limited time to design. However, in my experience so far, I have learnt to cope up with this by learning to let go perfection and instead produce rapid design like a MVP and iterate and improvise it as sprint progress. Considering this I started doing guerrilla research, wherever possible to make an informed decisions.

Atomic Design Approach

Irrespective of the sprint plan and the user stories picked accordingly, I was constructing the solutions as a whole. However, I fragmented requirements into functional units which were combinations of basic design element or feature.

Following where few of the crucial features we constructed along the entire product development.

  1. Push Notification
  2. FG’s Dashboard
  3. Chat
  4. CTN/Network uplift

Further, I divided these features into basic units and did quick scribbles. This was easy to brainstorm with others and record insights. I was very particular with developers here, to check the feasibility and resilience of solutions inlined with native and browser-based features. Below I have discussed these features one by one.

Push Notification

It was one of the primary features, as it was notifying the user with the case updates even if the app is not open on the device. In this case, push notification of apple was predefined, however, I focused on the structure and communication of this widget. Following are few scribbles and the initial low fidelity wireframes created in PPT.

Through push notifications, the real-time data was shared with users and that needs to be well presented in a way that user can understand it and take necessary actions.

Fast Guardians's Dashboards

I enjoy a lot designing dashboards as it gives me to hold on the entire functionality. I believe, to design a good dashboard, one should be through with requirements and then should meticulously implement research and usability in practice. At times, I feel designing one can be a daunting experience, based on type and user expectations. Here I was dealing with the operational dashboard. I did various scribbles and shared my understandings. Finally, I present the summary of the entire ecosystem at a glance considering time-sensitive tasks to help users understand data quickly and clearly to react fast and take actions immediately. Choosing the right data visualization type is crucial here as the need to accommodate a ton of data, actions like showing CTN eligibility for uplift, uplift request status, make uplift request, list of active cases, kind of digital control room to handle critical cases easily. This was quite challenging.  

Finalized iPad Scribble
Finalized iPhone Scribble

Considering real-estate freedom in landscape view of iPad, I accommodated all the features upfront. Navigation was a crucial aspect, which was easily accessible to the left side with fix placement. In some scenarios FG’s on the field may use the glows like firefighters. Considering this, actions were presented with large icons and label with greater clickable. However, for Mobile, I preferred the standard placement of primary navigation in a Menu bar as it was obvious to users and accommodates well with mobile real estate.

As Customer Telephone Number (CTN) eligibility to make uplift request was a vital aspect. Initially thought to show it standalone on the top left of the stage are, however later clubbed it with uplift request status. Hence, placed CTN info, uplift function and respective case/incidence details for which uplift request was made in a single card with various UI variations. Further, to make it more perceivable, suggestive icons where used as a calendar for date, location pin for address etc., following flowchart showcases various CTN statuses.

Following are selective screenshots of CTN card’s probable UI behaviors as per scenarios illustrated in the above flowchart. Same was replicated in mobile design too. These were color-coded in visuals to make easily understand.

I reserved the second half of stage area for active case lists and detailed view of a selected case. For mobile, it was quite hard to make a room for this list. Most importantly I was keen about placing them above the fold of design. To do so I finally decided to use accordion layout for case list for mobile devices. Following are the visual for iPad and iPhone.

Global navigation had Chat, Call to Customer care and Self-Diagnostics features. Even though, these functions where par of primary menu it was placed on the tab bar to make them available globally. For iPad, I skipped tab bar as primary navigation was upfront.

Live Chat

Live chat was a comprehensive feature available for FG’s in case of handling non-emergency cases. Agent availability, archive and share chat, automated chat and many more were the aspects of this solution. Hence this module had multiple iterations. Certain features had a dependency on the back end like handling various agent status, like available, typing, busy or away hence few amends were expected even if developed.

Following are few visuals of chat interactions,

CTN/Network uplift

To uplift network, CTN eligibility is considered. Here a user can make uplift with respect specific active case. As discussed above cases were displayed in individual cards. Here I reserved space for the CTN status, uplift button and uplift status etc. All these parameters were working in collaboration hence maintaining harmony in UI was the must. I used different color codes for the uplift status supported with the short and clear text messages. In the following screenshots, various scenario’s illustrated.

Visual Design

OneNet had their branding defined, however, we suggested few additions to the mobile platform. Following is the short style guide we followed. Images and iconography were meticulously used. Considering the subject, we user San Serifs and bold fonts. Very limited use of images. Bold buttons and prominent navigation. Following are color and fonts specifications.

conclusion

Summative usability testing which was carried out lately which was conducted remotely. We deliver this phase adhering to timelines. OneNet was very excited to launch an app as per schedule with the expected output. It was well received by an entire fraternity.

Considering first phases success, OneNet approached us for the further development which will be more robust with features like, Maps, recording and sharing case videos etc.

Considering first phases success, OneNet approached us for the further development which will be more robust with features like, Maps, recording and sharing case videos etc.