SECURED
MESSENGER
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study.
K Messenger is a highly secured mobile application (B2B), built specifically for the government officials to collaborate within the organizations they worked in.
The Ask
Redesign the secured communication tool. Due to NDA, I am not able to share the application's name. This application was built for both iOS and Android platforms. Like the commercial app, this application was not launched in App Store or Play store. My company had clients from the Middle East's government organizations. Contracts were signed from these entities, to use the applications for their employees communication.
My Role
Lead UX Designer
UX domains
Duration
Research|Design|Strategy
1.5 Year
Team size
2 - Me & a Visual designer
UNDERSTAND AND DEFINE
Understanding the problem
The ‘Ask’ mentioned above, was not elaborate enough to begin the work. I had a lot of questions, such as:
Why a redesign? - The purpose
-
WHAT are the issues with the existing design?
-
WHO are the end users?
-
HOW is the business getting impacted?
-
HOW can we measure success? KPIs
-
WHAT are the technical challenges?
How I got the answers ......
I conducted alignment sessions with key stakeholders to understand the problem, define problem statements, align on goals, understand the business, vision and product goals. This was an interactive session with activities such as individual brainstorming, abstract laddering & voting. Post the sessions, I prepared digital versions for further alignment sessions, which helped to align personas and create stories.
Digging deep into the application
-
Explored and analyzed the existing application.
-
Conducted heuristic evaluation to capture the severity metrics and showcase the issues to the team.
-
Gathered the technical details from development team.
-
Studied competitors to understand the applications used in the Middle East region.
The BEFORE of our design - Existing application
Understanding the users
I conducted surveys to identify the users and user interviews to find insights.
I have explained my research process in detail:
Detailed information on the user recruitment process, building a research panel, building guides, the challenges I faced and how I overcame those.
FINDINGS AND INSIGHTS
Survey results
Surveys helped to capture the user types and to understand the NPS (quantitative data) . I felt NPS surveys are a good place to get hold of customer names. I got some more info from the In-product surveys which helped to build a research panel.
Set of 12 questions were asked to capture details on the user categories, ease of use, information discovery, usage of features, and accessibility.
Few results...
52%
of the users were of age above 40 - So called grandma users.
31%
of the users were of age between 30-40.
Familiar with whatsapp, Snapchat etc
17%
of the user were of age range 24-30. Frequent user of social media.
32%
of the users used the application everyday.
76%
of the users were of did not share files via the application.
Insights
Conducting user research helped me understand the user's deeper need.
“Communicate SECURELY” - with no fear of breach & no complexity.
The barrier - what’s stopping?
-
Security is too visible - blocks users in the key actions
-
No clarity in features
-
Redundant information
-
Outdated design
-
Low performance
Empathizing with the users....aligning with the stakeholders & product team
Based on the research results, I understood that users have different motivations in using the application. Hence, I had to design personas to prioritize the type of users to our application.
Building the personas had helped to remind the major stakeholders always about the product, design decisions and prioritizing the feature set.
Logical breakdown... STAGES
I observed that the application had multiple and complex flows.
Example: Unlike the social messaging application, contacts were not the ones listed in mobile contacts, but the ones that were added into circles by an admin (in the background).
I felt it would be an easier approach if the app flow was broken down into logical groups. This helped in feature prioritization per STAGE, which further helped the product team to build the application in an efficient way.
User journey
Preparing a user journey had helped to design and communicate the edge cases that were not thought initially. Such a representation had also contributed to clearly communicate with the stakeholders and get buy-in for the features proposed.
Building the stories
Job story framework
Based on the user insights, I used a job story framework. These stories helped me convert the insights into actual problems that are needed to be addressed as a priority.
When _____ I want to _____ so I can ______
These activities were done for each flow - which then helped in feature prioritisation and user story creation.
Few job stories that were defined based on the flow breakdown(Stages):
Job story #1:
Flow: Initiate
Situation: When I am creating a new chat,
Motivation: I want to see both internal and remote contacts,
Expected outcome: so I can choose the contacts to chat without contacting the admin
Job story #2:
Flow: Launch & Explore
Situation: When I am logging in to the application,
Motivation: I want to generate an authorization code myself,
Expected outcome: so I can quickly create an account.
Success Metrics were mapped using a ‘HEART’ framework.
These were then marked into improvements and opportunities categories.
WORKING ON THE STRUCTURE
Prioritizing features and building a revised Information Architecture
Considering the time, I chose Impact-Effort matrix to prioritize features with the product scrum team. This task was done at multiple stages of app development (a lot of times, as the features kept gaining momentum), as per the flow breakdown and sprints.
Mode: Activity with the product team - Listing down, categorizing and dot voting.
Deadlines…Parallel activities...Mix of Agile and Waterfall methods
Features priority, design and development were planned to happen in parallel.
Design of each stage (with the features priorities + Design deliverables + Evaluation + handover) was sequenced. Once each feature was designed and approved, the engineering team began the implementation.
I followed by working with Android and iOS developers to address product features for their platform’s context. Concurrently, I would design the next feature in the pipeline, whilst also working with the engineering teams to execute the current feature through to completion.
My process for each stage...
Iterations and Formative evaluations
For each STAGE, I ideated and iterated on the designs. Reviewed with the POs and scrum teams. Conducted formative evaluations with a mix of internal users and few customers ( Mode: Cognitive walkthroughs). Here is an example of the design iterations for one flow:
HI-END DESIGNS, SPECIFICATIONS and DOCUMENTATION
Style Guide
With no design system in place, it was challenging to achieve a consistent application. Me and my team member worked on a style guide, which helped us align well with the interaction designs and developers. We redefined the brand elements to improvise the visceral aspects of design.
The Redesign
.jpg)
Detailing the flow
Got an understanding that the developers and QAs had a lot of dependency on the UX flow. Thereby, to solve this issue, I prepared highly detailed task flows.
CREATING DETAILED SPECIFICATIONS
I created six sets (two for each platform that I owned) of documentation during this project to communicate requirements to the engineering team and support our quality assurance teams in writing test cases.
These deliverables consisted of the CX Spec—requirements and customer journeys and the Visual Design Spec & Key lines—the design system.
This documentation required the most rework during the project and was the highest overhead to maintain.
I also experimented and came up with complementary documentation to communicate animation and timing keyframes for our micro‐interactions.
Deliverables
With no access to Invision or any other cloud based tools, we depended on Sketch Measure plugin to generate the specifications. In addition, we also created extensive amount of other documents:
-
Visual specifications - For 2 platforms and 2 themes
-
Task flows
-
Detailed behavior documents
-
Assets - Icons, logos etc
-
Keyboard behavior document
-
Micro-interaction specifications
-
Gesture documents
INTERACTIONS
Recording a voice memo.
This feature was never there in the old application. Considering our grandma users, they were really comfortable with a dedicated panel to record-play-then send (unlike click-record-release pattern)
Long press menu
The old application had very tiny and unclear components. The users were really happy to use bigger touch targets and clear icons (with text).
Time sensitive messages
As this was a secured messenger, this feature was a prominent one for the user. Redesign of this made it much simpler to compose and view. Trust and safety were the words chosen to describe this by the end users.
VALIDATION
Guerilla Testing with the internal users
2 months before the launch, I partnered with Visual designer + Product owner to test the major workflow of the application, by conducting a Guerrilla testing with the internal users.
This helped us validate our assumptions and provide us a heads up on potentials issues that might arise.
First impression tests
For the re-branding and visual design updates, we conducted first impression tests and grabbed adjectives. We made sure our assumptions matched user’s expectation.
Usability testing - Summative evaluations
I worked closely with PO and writers to define the objective, success metrics and set of tasks for the session. Unlike formative evaluations, we needed more number of users to conduct these summative evaluations. We spent 2 months of time to conduct these sessions. This helped us capture the quantitative information such as SUS score, ease of use and NPS.
Due to the NDA, I am restricted to explain the changes based on the usability testing results. Overall, the product resonated well with the participants and had a more excellent NPS score compared to the old version that was previously tested.
THE IMPACT
Reflecting back to the goals
Redesign of the K Messenger app on iOS and Android had a positive impact on the secured collaboration experience.
-
8 New contracts were signed in the span of 3 months - Big success
-
Daily usage rate increased by 42% (specially by the age group of 40+ ‘ our grandma users).
-
Screen views increased by 21%.
-
File sharing increased by 27%.
-
Dropouts reduced by 52%.
-
Support tickets reduced by 43%.
WHAT NEXT?
“A successful product is never done or perfect”
-Geoff Teehan, Product Design Director at FB
The above quote is so true. A product is never done and the challenges evolve once it is out into the market.
-
We started creating the enhancements list for the next updates.
-
We got back to planning, creating user stories.
-
We also prepared the success metrics for future usability studies to see how well the messenger had been able to justify the user insights that we had collected during the user research phase.
-
We are currently working on the sound design and integration with our suite of applications.