

Azure has a large breadth of capabilities, ranging from cloud center management to protection and monitoring of your devices. They strive to help the user achieve their goals with freedom and ease. It is important that the experience is also representative of something just as seamless in the mobile app. While the majority of users are preforming more complicated user flows on the desktop, the app remains a place to monitor notifications and keep up-to-date easily. Micro activity is key here, as most users are on the app to preform small, quick tasks. One of those tasks, Global Search, became a highly requested feature.
Role: UX/UI Designer, Visual Designer
Client: Microsoft | Azure
Timeline: 1 month
It was understood from user feedback that global search was the best way to improve micro-productivity. There are search capabilities within lists but the lack of global search on the home screen was a roadblock for our users. Our research team found there was confusion about where a notification came from and frustration to find it while being surrounded by a large amount of information. With this knowledge, I started by seeking global search experiences in other apps. I wanted to understand Android user search flow, so I began to answer these questions:
What user flows are Android users used to?
Are there patterns they look for?
Is there Android standards for this?
From this exploration, I found that leveraging Material guidelines was a great place to start. A search feature is something that mobile app users are very familiar with, along with their various capacities. Whether in a header bar, bottom nav icon, or floating action button, the icon is instantly recognizable. With that, it comes does to location, location, location.
The search flows that existed before were within lists. Whether resource or subscription, the search capability was limited to the screen the user was currently on. While these search experiences are helpful for users, there is a requirement of knowing where to search within. Global search provides a way to streamline that experience even more. When looking at location, it made sense to bring the same search flow from these screens onto the home page.
The next step was synthesizing a concrete set of goals.
User goals
Interact easily with information
Find what they are looking for
Ease of flow to/from Home
Business goals:
Leverage existing design patterns from Azure, Fluent, and Material
Increase app usage
Constraints
Accessibility guidelines
Existing UI language [Android & Azure]
Before building out solutions, it was important to understand the current user flow compared to the desired user flow. You can see below that the current flow required the user to go through 4-5 steps before reaching the resource they want. The goal of Global Search is to cut those steps down to 2-3. It also diminishes the decision making of what to click on the Home page. After understanding how the user interacts with search, we were able to outline which scenarios to focus on.
The main discussion in our solution was the location of the search icon. From our user research, I understood what patterns were present in Android. It was about playing around with the placement to find a design that I felt was ready for testing.
After a discussion with the team, I moved forward with the Floating Action Button for the search location. It was agreed that this location felt the most appropriate and we wanted to test this with our audience.
I was asked to create a high-fidelity prototype for our test subjects. Unfortunately, in the year 2020, our usability testing was only happening virtually which meant that the researcher clicked through the flow. While it would have been more ideal to have the user click through themselves, it worked out well and we were able to adapt.
Microsoft Azure Mobile App prides itself in maintaining a Grade B, or better, in accessibility. I had to make sure that I was designing not only for the target audience, but users outside our demographics. This includes users with disabilities. When addressing discoverability issues, I checked that I met all accessibility requirements. Some accessibility checkpoints included looking at color-contrast, text size and icon size. Material and Fluent both have done a great job of including these guidelines as well, so I was able to reference drop shadows and sizes to match.
I worked with our researcher to outline probing questions to assess the frustrations and concerns of the user. The questions were focused on the discoverability of the search icon and how well the user was able to complete the desired task. We outlined the two scenarios to assess the success of our design.
Test the placement of search icon
Test the interaction and search journey
Discover if users can navigate through the app
Discover if users are satisfied with the journey
Identify any pain points or unexpected interactions
Moderated usability study, 30 minutes sessions in which participants will be asked about their (1) micro-productivity scenarios and the role search can place in the Mobile app and (2) qualitative feedback on the designs/interactions.
The researcher outlined the key insights on the table below. The team discussed these results and determined what actions were top priority. These were the points that I focused on, specifically for Android:
Discoverability of FAB is low – let’s reassess the location here
The journey back to home can be tedious - we had discussed putting the search icon in the bottom nav bar. This still felt like too much of a change, but it was to be reassessed in a later sprint.
The sequence of sections met expectations – the journey made sense to users. This meant that we needed to focus on the discoverability the most.
Insights/Recommendations | Action Items | Tags | |
---|---|---|---|
Highlight | Search icon placement in iOS met with the expectations of the users. | No Action Needed | |
Highlight | The section dividers met with the expectations of the user. | No Action Needed | |
Highlight | The sequence of sections met with the expectations of the users. | No Action Needed | |
Highlight | The threshold for each sections met with the expectations of the most of the participants. | No Action Needed | |
Lowlight | Search icon in Android might have discoverability issue. | No action needed now but test this after the shipment | Discoverability |
Lowlight | Participants wants the results to auto populate without clicking on 'Go' similiar to Outlook mobile app. | This will be addressed in the V2 after ignite. | Ease of use |
Lowlight | Given that to do some tasks it requires deep journey, give an option to go back to the home page with less clicks. This of what LinkedIn, and Facebook app does for search. They have the bottom tabs persistant in the search results. | This will be addressed in the V2 after ignite. | Ease of use |
Lowlight | Think of ways to do quick tasks from the global serach to reduce the journey taken to navigate to a resource and then fix it. | More research needed to vet the ideas. | Ehance microproductivity |
After deciding that the FAB did not pass user testing. I went back to the previous iterations to see if there was a solution there that would work. The users felt that moving the search icon to the top navigation bar was most consistent with their experience. I moved it in line with the current set of icons as our final design.
Drawing from existing patterns designs in important. I created mockups that had existing patterns from Azure App but also drew inspiration from Fluent and Material.
User testing key. Without research and physically asking our user questions, we would have not known that the FAB was not successful. The testing can really poke holes in the design that I would have not thought of.