Mobile App
Building a touch-first experience without sacrificing complexity
Why a mobile app?
Our current product does not support mobile interactions, instead we offer our users a mobile app to meet their needs on the go.
What's the problem?
The new IT asset management system has been designed and implemented on our web platform. We need to fully translate the day-to-day functions in a mobile experience. Our current mobile app only shows our ticketing inbox with poor UX framework for expansion. We need to create a new space for ITAM.
How do we get there?
Create a touch first experience for the complex actions that work successfully in the limited mobile space without removing any functionality. Ensure our framework will allow connection to our current mobile app and have scalability.
Working in ambiguity is not uncommon. This project only provided me with a list of pages that needed to be translated to our app. I understood our goals, I understood the priority, and I moved forward to set the foundation for all future additions.
start
Research and Planning
Where I started
Figuring out what current actions would need to be designed for our mobile space guided my research and design plan. Having led most of the design work for the IT asset manage system, I understood the kind of complexity I would be working with. Some core experiences to address were:
data tables
search and filtering
forms
dropdown lists
Establishing successful UX for these actions would set the groundwork for our app as it continues to grow.
Research
I understood that this project would require in-depth research, and lots of it. Not only did I need to share my findings with the team for design choices, but also help create specs in order to have smooth implementation. I started first by examining typical UX patterns in mobile design. It was important to create a familiar experience for our users to ease frustrations and confusion.
Interacting with popular mobile experiences (Amazon, Google Shopping, Pinterest, DoorDash, and more) helped me understand these patterns. I also looked into how other IT asset management systems succeeded in the mobile space. I gathered screenshots with reference links, recorded my own phone interactions with various apps, and used AI tools like Claude and ChatGPT.
Planning
Since the ITAM mobile app was not something already established, I had to create a holistic plan on how each page would interact with each other. In addition to that, I needed to make sure anything I created for the mobile experience matched with the web experience. This would allow our users who already work in our system to understand the structure and steps naturally.
My plan of attack was starting on the outside and making my way inwards. Design the frame for the shell and overall navigation, then design the main surface level pages, and finish with the flow for when users dive into each area. In order to make the app design manageable for myself, my team, and implementation, I planned to reuse single framework experiences as much as possible.
action
Framework
The typical process for design starts with drafting and designer review prior to sharing with the rest of the team. Due to the volume of work, I had to adjust and tackle each framework with the team before bringing everything together.
Shell
The shell always starts with clear labeling allowing users to quickly understand their current location in the app. This offers clarity as users get into deeper levels of the app and space for moving back to the page before.
Search and filter come next. Since our search function does not support overall app searching I wanted to make it clear the search is for the space the user is currently viewing. Moving it below the shell label helps clarify this.
Top level actions follow. These are the common actions users take in the ITAM system. Because our product continues to grow I needed to ensure the framework could accommodate additional actions. I utilized typical side scrolling behavior to achieve this.
The core navigation lives at the bottom of the app. Using this approach allowed us to connect the established inbox with minimal work. Due to time restrictions we needed it to "work for now" before we could address inbox changes.
With the shell framework established, space was becoming an issue. To solve this I used the common "hide on scroll down, show on scroll up" behavior. This allowed essential space for our users without limiting interactions.
Tables
To address the data table issue for a mobile experience, I looked at popular alternatives. The most popular being a card-based layout with limited surface level information. Cards are an element commonly used across our product and would be a great opportunity to keep brand consistency.
Filters
We offer robust filtering on our web app but the nested drop-downs and accordions wasn't going to translate for mobile. Each team member also had personal ideas on how filters should function. Based on my research and examples from the team, I created a combination of chips, visual indicators, and a scaling menu.
Forms
One of the most common interface designs in our product are forms. Since forms are pretty straightforward, the adjustments I focused on were visual cues and groupings for length concerns. Using the required color as a border to help as users skim to understand what fields need to be completed.
Drop-downs
The hardest problem I had to solve was creating drop-downs in a mobile setting. Common alternatives like radio buttons, segmented controls, and accordions would not work for dynamic content. It's not uncommon to find over 100 customized list items in our product.
I felt using a bottom sheet would be the best overall design. This would allow for consistent interaction across the app, the ability to expand to any length, and only require small behavior changes between single and multi select.
action
Design and Revisions
Bringing the pieces together
I worked through each framework with the team, showing them the recordings and interactions to help explain my choices. After we agreed on each section of framework, the next step was bringing it all together and creating the base pages planned for initial release.
Asset information
The main page users will see when coming into the ITAM app is the asset management table. Each card replaces a table row with the most important and commonly searched information upfront. I mirrored visual elements used in the web app like missing information and status, while also adjusting layout to include asset type, subtype, building, and assignment name. Users can quickly toggle between complex and simple assets just like web, and clicking the asset will show the details which appear in a side panel on web. Since the details panel can become longer as the product continues expanding, I divided sections into collapsible groups. This would allow for better searching and help with visual fatigue.
Batch check in
We offer multiple batch operations to our users in our IT asset management system. To mirror the actions on web, I separated each action into its own group on mobile. This structure walks the user through the steps in a chronological way. Repeating information fatigue solutions, each section is also collapsible without removing needed functionality such as history cards and actions you can take.
Adding assets
For long form fills like users adding an asset, I continued reinforcing the collapsible group formatting. There are multiple system features in ITAM that will require these longer form fills, with this structure established we can continue to easily add more of those areas to the mobile app quickly.
Search and filters
One strong reason behind the urgency of creating the ITAM mobile app was the ability for users to use their phone as a scanner. With this in mind, I added a "scan to search" button next to each search bar. With the fully open filters panel, I continued to use the section separation and replaced checkboxes and radios with large buttons. Using two visual indicators, one on the filter button and a high level label at the bottom of the screen, ensures users will understand when a filter is applied.
Multi-select drop-downs
I used the initial framework I created for solving drop-downs anywhere a drop-down is located. Offering both single and multi select, users can search their long dynamic lists for quick selection. Following the filter behavior, all checkbox or radio options on mobile instead use a large button for easier touch interactions. Clear color indicators ensure our users quickly understand their selections made.
end
Final Approval
Approval and hand off
In order to ensure I had thought through every page to page interaction, I gained one final approval by showcasing the entire app and how it functions. Putting myself in our users' shoes, I walked through a few journeys; a system admin coming in to do asset management updating (including editing and adding assets), an IT agent coming in to navigate between user information and ticket inbox, and a school staff member coming in to start the end of year check in operations.
During this, we compared the new mobile app functions to the web functions, solidifying the complete story and behavior matched. With this style of presentation, we were able to confidently move forward as a team to implementation.
post
Impact and Reflection
How did it go?
The new ITAM mobile app was implemented successfully with minimal back and forth during development. Reactions were extremely positive and stakeholders want our inbox updated as soon as possible. In addition, the framework has allowed development to quickly implement user requested features that mirror the web app.
Would I change anything?
This was a unique project that didn't follow typical processes. We always want to follow standards set in place, but the reality is that doesn't always happen. Having more resources, real user testing, and adequate time would have solidified our solution.
Rolling with it
Shifting priorities and urgent deadlines. I work through these with honest cross team communication and organized planning for what we can and can't realistically achieve.