The problem
At PENSCO Trust Company, a financial services company, employees used a legacy application to manage customer requests and often complained that it was confusing and difficult to use. As we needed to rebuild it to integrate with our customer-facing web portal, this was a great opportunity to redesign it for a better user experience.
Assets below have been generalized.
The process
I was the only designer so I was responsible for the full design process, from user research to UI design and even UI development.
I started with user research: a combination of user interviews and usability testing, listening to verbalized needs and frustrations as well as observing actual behavior and workflow.
Based on my findings, I identified several pain points to fix in the redesign. With feedback from the product team, I mapped new user flows, created wireframes for an improved information architecture, built an interactive prototype to demonstrate the details of new workflows, and designed the new UI. Working closely with the engineering team, I also built the new UI in HTML and CSS.
The solutions
My main focus was on minimizing friction so that users could accomplish their tasks more efficiently. This would make it faster to complete client requests and, on top of the new integration with the customer web portal, would provide a better customer experience.
There were three types of users:
- Power users: employees who processed client requests. This app was where they did their day-to-day work so they were our main user base.
- Admin users: managers on the processing team. They were power users that needed more oversight and control.
- Casual users: other employees that needed visibility into the status of client requests. This was our largest group of users, but they spent the least amount of time in the app.
Streamlined navigation
In the old app, the navigation and structure was the same for all users, which didn’t account for different user workflows and meant additional steps for power users, the main user base.
After logging in, users started on the search page, which consisted of 25 different fields to search by. Search was indeed one of the main functions used, but our research showed that users searched primarily by ID, so the rest of the page was ignored most of the time. Casual users only used the search function, so having immediate access to search was still helpful for them.
Power and admin users, however, used many other features that were less accessible. For example, they worked daily from a personal task queue that was accessed by scrolling through a full list of team members and finding their own name. Having the full list allowed admin users to review everyone’s queues, but it created unnecessary steps for power users to access an important function that they used throughout the day. These users would have benefited from an app structure that eliminated these extra steps.
In planning the app structure and user flows for the redesign, we decided to customize the app experience by user type to minimize unneeded navigation. Casual users would still have immediate access to search, but power and admin users would have their individual task queue as their homepage, removing the friction of having to find it multiple times throughout the day.
Since search was still an important function for all users, however, we placed the primary search field directly in the navigation bar for maximum accessibility. The rest of the search fields were used far less frequently, so we pared them down to 12 based on usage and placed them in a dropdown where they were less prominent but still easily accessible.
Improved page layouts
The UI in the old app was also not designed optimally for users’ workflows. The site navigation was a sidebar on the left, and pages were structured with a focus on minimizing height so that users never had to scroll down. Pages with more content had the information separated into tabs that users had to click through to see everything.
We found in our research, however, that since power users needed to work in multiple apps, most of them used a dual-monitor split-screen setup—each app took up half of one screen (960px by 1080px) so that they could look at four apps at once. Page width was actually more of a constraint than page height, and users found it troublesome to click back and forth between tabs for information they needed. We also found that much of the information on the tabs wasn’t used.
In the redesign, we moved the navigation to a thin header bar at the top and restructured the information architecture to prioritize what was important and remove what wasn’t useful, which meant that we could make the important information available on screen with minimal scrolling. This was helpful for all users, as it allowed power and admin users to complete their tasks more quickly, and also made pages easier to scan for casual users.
More usable task queue
The task queue was a list of client request items, which power users worked from throughout the day. Since it was the most user-specific page in the app, its design required more iterations to make sure it served its purpose well.
In the old app, the list included items that needed immediate attention as well as items that didn’t. In the first round of wireframes, we simplified this list to only the items that needed immediate attention, as that was a more focused and organized list. After getting preliminary feedback, however, we realized that there were many situations where users needed access to additional items, e.g., if they completed their current tasks and wanted to work ahead or if they needed to find a specific item in their list that was related to a new request.
We found that power users needed more flexibility to work efficiently, so it was important to have a good default view and an organized interface, but it was also important to give them access to more information and more view options.
We made sure that all columns were sortable and added more filter options, giving them access to completed and upcoming items, as well as the ability to view other team members’ queues. With the width constraint limiting the number of columns, we also added more details about each item in an expandable area so that users could have a full understanding without leaving the page.
Streamlined workflow
Power users worked in several applications to complete a client request, and with the old app, they had to manually retype information between each app in the process. For tasks that required multiple days, they also had to manually check statuses in various apps. This meant additional work as well as a greater chance of human error (and thus, required more oversight), which increased the time needed to complete each request.
We designed and built the new app to greatly simplify this workflow. We built integrations with other apps to automate many of these steps so that users could manage the majority of the process from this redesigned app, saving them a lot of time.
We also tried to remove as much friction as possible from the process by designing the app to have sensible defaults, to automatically update form fields and displays based on user input, and to remember user input across multiple pages (where appropriate).
For example, we found that power users always did a search before they created a new request in the system, both to check for duplicates and to have context on the client’s situation. Having the app remember the searched ID and prepopulate it in the new request form cut out several unnecessary steps so that users could focus their attention on the important ones.
The Results
Once the new app reached feature parity with the old one, and after some usability testing to confirm that there weren’t any major issues, we transitioned the users over. After a short adjustment period, we received very positive feedback on the app. Users were extremely happy with how much easier it was to use and how much simpler their workflow had become—the technical capabilities and UX of the new app drastically cut down the amount of time they needed to complete their tasks.
As an Agile development team, we continued working on new features and improvements for future releases. Once users had time to fully adjust to the new app, they also gave us more feedback on issues and enhancements, which we incorporated back into the design and development process.
Learnings
Design before code
Since I would review and update the UI after development, creating high-fidelity mockups before development seemed unnecessary at first. However, finishing the design as I updated the UI code often took a lot more time and made for a lot of code churn—since the devs were building from wireframes, I would often have to rewrite large sections of HTML in order to implement a more finalized design. It was also quite inefficient to design while coding.
After the first release of the app, I began to create high-fidelity mockups before development started on a feature. It was much faster to move elements around with a mouse than with code, and it was also far more helpful for devs to have clearer guidance. While I still needed to review and update the HTML/CSS, it made UI development more efficient.
Think incrementally for Agile development
With an Agile/Scrum development team, I couldn’t simply design the full site all at once and be done. The full vision of the app was broken down into releases, which were broken down into sprints, which were broken down into stories, each containing one piece of functionality. I often had to rethink how a feature could similarly be broken down into phases—I had to prioritize and consider how a page should look and function if it’s released with only a quarter of the planned functionality, or half, or three quarters. This also meant adapting my workflow to simplify the process of creating and updating mockups for these different stages.
Redesigning an existing app vs. creating something new
Redesigning an existing app was simultaneously easier and harder than designing something completely new. With an existing app, it was fairly straightforward to identify the users, observe their behavior, and ascertain their goals and obstacles. There was plenty of data on what worked and what didn’t, or what was important and what wasn’t. Since everything else was built on this foundation, there weren’t any major issues or surprises later on.
On the other hand, immersing myself in the existing environment sometimes made it harder to make larger and more innovative changes. In those times, it was invaluable to discuss my designs with members of the product or development teams, as they would have new ideas or questions that made me reevaluate and improve my designs. Having a variety of perspectives was instrumental to the design process.
Want to chat? Email me!