Overview
The OPAS Portal is an application designed to help users find and manage a variety of forms across domains like finance, security, career progression, and more. Users typically access the portal when they need to submit information or make requests that require formal approvals. In addition, the OPAS Portal serves as a workflow management tool, visualizing the initial submission and tracking the ticket's progression through a series of approvers. These approvers visit the portal daily and are highly sensitive to changes.
Overview
The OPAS Portal is an application designed to help users find and manage a variety of forms across domains like finance, security, career progression, and more. Users typically access the portal when they need to submit information or make requests that require formal approvals. In addition, the OPAS Portal serves as a workflow management tool, visualizing the initial submission and tracking the ticket's progression through a series of approvers. These approvers visit the portal daily and are highly sensitive to changes.
Overview
The OPAS Portal is an application designed to help users find and manage a variety of forms across domains like finance, security, career progression, and more. Users typically access the portal when they need to submit information or make requests that require formal approvals. In addition, the OPAS Portal serves as a workflow management tool, visualizing the initial submission and tracking the ticket's progression through a series of approvers. These approvers visit the portal daily and are highly sensitive to changes.
Project Scope
Replacement of existing application
Tools
Roles
UI/UX Designer, UI, Developer, UX Researcher
Team
3
Developers
1
UX Designers
1
Product Owner
1
Analysts
1
Scrum Master
3
Developers
1
UX Designers
1
Product Owner
1
Analysts
1
Scrum Master
3
Developers
1
UX Designers
1
Product Owner
1
Analysts
1
Scrum Master
Audience
30,000+ users
Duration
2.5 years
Challenge
Originally, the OPAS Portal was a simple application hosting forms and providing approvers with a view to manage submissions. However, confusing form names led to incorrect submissions or, in some cases, users avoiding submissions altogether. Approvers, who were familiar with the system, had to manually search for forms multiple times a day and use a data table that lacked basic functionalities like sorting, searching, and filtering. These inefficiencies created significant friction in the process.
We needed to design a system flexible enough to accommodate users with varying levels of expertise in the OPAS Portal. A one-size-fits-all solution wouldn’t work; we had to tailor the experience to meet different user needs.
Challenge
Originally, the OPAS Portal was a simple application hosting forms and providing approvers with a view to manage submissions. However, confusing form names led to incorrect submissions or, in some cases, users avoiding submissions altogether. Approvers, who were familiar with the system, had to manually search for forms multiple times a day and use a data table that lacked basic functionalities like sorting, searching, and filtering. These inefficiencies created significant friction in the process.
We needed to design a system flexible enough to accommodate users with varying levels of expertise in the OPAS Portal. A one-size-fits-all solution wouldn’t work; we had to tailor the experience to meet different user needs.
Challenge
Originally, the OPAS Portal was a simple application hosting forms and providing approvers with a view to manage submissions. However, confusing form names led to incorrect submissions or, in some cases, users avoiding submissions altogether. Approvers, who were familiar with the system, had to manually search for forms multiple times a day and use a data table that lacked basic functionalities like sorting, searching, and filtering. These inefficiencies created significant friction in the process.
We needed to design a system flexible enough to accommodate users with varying levels of expertise in the OPAS Portal. A one-size-fits-all solution wouldn’t work; we had to tailor the experience to meet different user needs.
Business Goals
Decreasing incorrect submissions by guiding users toward the forms they were required to complete
Shorten time between entering site to form submission
Provide power users with tools to improve efficiency and automate remedial tasks
Design a system that spoke users’ language and not agency jargon
Business Goals
Decreasing incorrect submissions by guiding users toward the forms they were required to complete
Shorten time between entering site to form submission
Provide power users with tools to improve efficiency and automate remedial tasks
Design a system that spoke users’ language and not agency jargon
Business Goals
Decreasing incorrect submissions by guiding users toward the forms they were required to complete
Shorten time between entering site to form submission
Provide power users with tools to improve efficiency and automate remedial tasks
Design a system that spoke users’ language and not agency jargon
01 / Discovery
Empathize with users
Meet Users
Before redesigning an application, I met with the users. It was important to understand why users visited the OPAS Portal and what kinds of tasks they were trying to complete. During this time, I learned about the problems users were experiencing and the areas that could use the most improvement.
I also discovered that OPAS Portal users, depending on role, had varying levels of expertise in the previous system, which heavily influenced the kinds of changes they wanted to see implemented. While these suggestions seemed to vary widely, their recommendations ultimately boiled down to solving efficiency problems.
Meet Users
Before redesigning an application, I met with the users. It was important to understand why users visited the OPAS Portal and what kinds of tasks they were trying to complete. During this time, I learned about the problems users were experiencing and the areas that could use the most improvement.
I also discovered that OPAS Portal users, depending on role, had varying levels of expertise in the previous system, which heavily influenced the kinds of changes they wanted to see implemented. While these suggestions seemed to vary widely, their recommendations ultimately boiled down to solving efficiency problems.
Meet Users
Before redesigning an application, I met with the users. It was important to understand why users visited the OPAS Portal and what kinds of tasks they were trying to complete. During this time, I learned about the problems users were experiencing and the areas that could use the most improvement.
I also discovered that OPAS Portal users, depending on role, had varying levels of expertise in the previous system, which heavily influenced the kinds of changes they wanted to see implemented. While these suggestions seemed to vary widely, their recommendations ultimately boiled down to solving efficiency problems.
Methods
Interviews: 10+ participants
Field studies: 5 disabled users (508 compliance)
Surveys: 300+ responses
Methods
Interviews: 10+ participants
Field studies: 5 disabled users (508 compliance)
Surveys: 300+ responses
Methods
Interviews: 10+ participants
Field studies: 5 disabled users (508 compliance)
Surveys: 300+ responses
Findings
After meeting and receiving feedback from users, I learned there were essentially two kinds of users: submitters and approvers.
Submitters were often unfamiliar with agency jargon which led to problems finding and completing forms. Renaming forms, using the same language our submitters spoke, would shorten form hunting and improve accurate submissions. To give an example, a form named TRR-251 would be renamed to International Travel Submission.
Additionally, submitters frequently did not know which forms were required to be completed in certain scenarios. Submitters also needed help identifying which forms were required based on their situation.
Approvers, on the other hand, spent much of their day using the OPAS Portal. Their current approval process was linear and prevented them from multitasking. Approvers wanted to be able to manage multiple workstreams at once and have quick access to the forms they used most frequently.
Findings
After meeting and receiving feedback from users, I learned there were essentially two kinds of users: submitters and approvers.
Submitters were often unfamiliar with agency jargon which led to problems finding and completing forms. Renaming forms, using the same language our submitters spoke, would shorten form hunting and improve accurate submissions. To give an example, a form named TRR-251 would be renamed to International Travel Submission.
Additionally, submitters frequently did not know which forms were required to be completed in certain scenarios. Submitters also needed help identifying which forms were required based on their situation.
Approvers, on the other hand, spent much of their day using the OPAS Portal. Their current approval process was linear and prevented them from multitasking. Approvers wanted to be able to manage multiple workstreams at once and have quick access to the forms they used most frequently.
Findings
After meeting and receiving feedback from users, I learned there were essentially two kinds of users: submitters and approvers.
Submitters were often unfamiliar with agency jargon which led to problems finding and completing forms. Renaming forms, using the same language our submitters spoke, would shorten form hunting and improve accurate submissions. To give an example, a form named TRR-251 would be renamed to International Travel Submission.
Additionally, submitters frequently did not know which forms were required to be completed in certain scenarios. Submitters also needed help identifying which forms were required based on their situation.
Approvers, on the other hand, spent much of their day using the OPAS Portal. Their current approval process was linear and prevented them from multitasking. Approvers wanted to be able to manage multiple workstreams at once and have quick access to the forms they used most frequently.
"
"
I can't find the forms I'm looking for. The names of forms are confusing.
Organization Business Analyst
Submitter / Novice Experience
02 / Define
Identify problems
Visualize the Problem
Now that I had a better understanding of OPAS Portal users, I wanted to take their experience and visualize it. The goal here is to identify pain points during the customer journey and alleviate them.
Visualize the Problem
Now that I had a better understanding of OPAS Portal users, I wanted to take their experience and visualize it. The goal here is to identify pain points during the customer journey and alleviate them.
Visualize the Problem
Now that I had a better understanding of OPAS Portal users, I wanted to take their experience and visualize it. The goal here is to identify pain points during the customer journey and alleviate them.
Who Are Our Users?
Based on user research, more than 70% of our users were submitters yet the OPAS Portal’s design did not accommodate them. Approvers, while a smaller group, accounted for the most time spent in the application.
Who Are Our Users?
Based on user research, more than 70% of our users were submitters yet the OPAS Portal’s design did not accommodate them. Approvers, while a smaller group, accounted for the most time spent in the application.
Who Are Our Users?
Based on user research, more than 70% of our users were submitters yet the OPAS Portal’s design did not accommodate them. Approvers, while a smaller group, accounted for the most time spent in the application.
01 User Type
Field Agents — Submitter
Field agents only visit the OPAS Portal when required. Their frequency of use is typically low to medium, and they are not usually familiar with the breadth of the application. Field agents will complete a form and not revisit the site until another event occurs. Their day is usually hectic and the OPAS Portal is considered a hassle.
01 User Type
Field Agents — Submitter
Field agents only visit the OPAS Portal when required. Their frequency of use is typically low to medium, and they are not usually familiar with the breadth of the application. Field agents will complete a form and not revisit the site until another event occurs. Their day is usually hectic and the OPAS Portal is considered a hassle.
01 User Type
Field Agents — Submitter
Field agents only visit the OPAS Portal when required. Their frequency of use is typically low to medium, and they are not usually familiar with the breadth of the application. Field agents will complete a form and not revisit the site until another event occurs. Their day is usually hectic and the OPAS Portal is considered a hassle.
02 User Type
Intel Analysts — Submitter
Intel analysts tend to be younger and more technology literate. They visit the OPAS Portal a few times a year and have a difficult time finding forms. Intel analysts typically rely on outside help to find a form they are required to submit. The OPAS Portal looks dated to them and doesn’t reflect the modern applications they encounter on daily basis.
02 User Type
Intel Analysts — Submitter
Intel analysts tend to be younger and more technology literate. They visit the OPAS Portal a few times a year and have a difficult time finding forms. Intel analysts typically rely on outside help to find a form they are required to submit. The OPAS Portal looks dated to them and doesn’t reflect the modern applications they encounter on daily basis.
02 User Type
Intel Analysts — Submitter
Intel analysts tend to be younger and more technology literate. They visit the OPAS Portal a few times a year and have a difficult time finding forms. Intel analysts typically rely on outside help to find a form they are required to submit. The OPAS Portal looks dated to them and doesn’t reflect the modern applications they encounter on daily basis.
03 User Type
Business Analysts — Approver
Business analysts use the OPAS Portal daily. In fact, their job likely exists because of the OPAS ecosystem. They are highly sensitive to change and prefer functionality over style. Many of them are complacent with the current solution because it "gets the job done".
03 User Type
Business Analysts — Approver
Business analysts use the OPAS Portal daily. In fact, their job likely exists because of the OPAS ecosystem. They are highly sensitive to change and prefer functionality over style. Many of them are complacent with the current solution because it "gets the job done".
03 User Type
Business Analysts — Approver
Business analysts use the OPAS Portal daily. In fact, their job likely exists because of the OPAS ecosystem. They are highly sensitive to change and prefer functionality over style. Many of them are complacent with the current solution because it "gets the job done".
Take Aways
Pain Points
Forms not intuitively named and located
Forms not intuitively named and located
Forms not intuitively named and located
Site is slow and unresponsive to user input
Site is slow and unresponsive to user input
Site is slow and unresponsive to user input
Outages occur without notification to users
Outages occur without notification to users
Outages occur without notification to users
No assistance to help users find forms
No assistance to help users find forms
No assistance to help users find forms
Too much information displayed
Too much information displayed
Too much information displayed
Lacks ability to have quick access to frequently used forms
Lacks ability to have quick access to frequently used forms
Lacks ability to have quick access to frequently used forms
Data table cannot be filtered, sorted or searched
Data table cannot be filtered, sorted or searched
Data table cannot be filtered, sorted or searched
Aesthetically unpleasing
Aesthetically unpleasing
Aesthetically unpleasing
Solutions
Rename forms to speak user’s language
Rename forms to speak user’s language
Rename forms to speak user’s language
Lighter weight application with better performance
Lighter weight application with better performance
Lighter weight application with better performance
Ability to push notifications to users
Ability to push notifications to users
Ability to push notifications to users
Intuitive way to funnel users to specific forms
Intuitive way to funnel users to specific forms
Intuitive way to funnel users to specific forms
Better information hierarchies and limiting information displayed
Better information hierarchies and limiting information displayed
Better information hierarchies and limiting information displayed
Ability to favorite forms
Ability to favorite forms
Ability to favorite forms
Modern data table with ability to filter, sort and search
Modern data table with ability to filter, sort and search
Modern data table with ability to filter, sort and search
Updated UI
Updated UI
Updated UI
03 / Ideate
Wild ideas welcome
Hand Sketches
Based on user feedback, the new OPAS Portal home page was going to be minimalistic. This decision was made to alleviate overwhelming users with options. We wanted to drawl users’ eyes to the large cards in the center of the screen. Clicking a card would then begin a process of funneling a submitter to the required forms they needed to complete.
The navigation bar at the top was also streamlined. The original application had tabs, pages and duplicated content dispersed in random locations. It was confusing. The navbar would consolidate content into distinct pages that day-to-day users would be familiar with.
Hand Sketches
Based on user feedback, the new OPAS Portal home page was going to be minimalistic. This decision was made to alleviate overwhelming users with options. We wanted to drawl users’ eyes to the large cards in the center of the screen. Clicking a card would then begin a process of funneling a submitter to the required forms they needed to complete.
The navigation bar at the top was also streamlined. The original application had tabs, pages and duplicated content dispersed in random locations. It was confusing. The navbar would consolidate content into distinct pages that day-to-day users would be familiar with.
Hand Sketches
Based on user feedback, the new OPAS Portal home page was going to be minimalistic. This decision was made to alleviate overwhelming users with options. We wanted to drawl users’ eyes to the large cards in the center of the screen. Clicking a card would then begin a process of funneling a submitter to the required forms they needed to complete.
The navigation bar at the top was also streamlined. The original application had tabs, pages and duplicated content dispersed in random locations. It was confusing. The navbar would consolidate content into distinct pages that day-to-day users would be familiar with.
Guiding Principles
Limit visual noise
Obvious hierarchies so pages are scannable
Follow common design practices
Guiding Principles
Limit visual noise
Obvious hierarchies so pages are scannable
Follow common design practices
Guiding Principles
Limit visual noise
Obvious hierarchies so pages are scannable
Follow common design practices
More Clicks are Better!
Team management and users had requested an application with less clicks. However, after observing users in the previous application, the number of clicks was not the problem. In fact, the previous application had arguably required less clicks.
The problem was that the previous application showed too many forms to try and satisfy the one-click requirement.
We solved this problem by limiting the options available to users. The application, instead, displayed cards with sentence fragments that, when selected, would filter forms. This form of filtering was natural to users and was much better than showing hundreds of forms at once.
More Clicks are Better!
Team management and users had requested an application with less clicks. However, after observing users in the previous application, the number of clicks was not the problem. In fact, the previous application had arguably required less clicks.
The problem was that the previous application showed too many forms to try and satisfy the one-click requirement.
We solved this problem by limiting the options available to users. The application, instead, displayed cards with sentence fragments that, when selected, would filter forms. This form of filtering was natural to users and was much better than showing hundreds of forms at once.
More Clicks are Better!
Team management and users had requested an application with less clicks. However, after observing users in the previous application, the number of clicks was not the problem. In fact, the previous application had arguably required less clicks.
The problem was that the previous application showed too many forms to try and satisfy the one-click requirement.
We solved this problem by limiting the options available to users. The application, instead, displayed cards with sentence fragments that, when selected, would filter forms. This form of filtering was natural to users and was much better than showing hundreds of forms at once.
Let's Organize
The original OPAS Portal had too many pages and the location of content was confusing. I decided to give each category of content a page that was easily accessible from the navbar. For example, instead of scattering forms in multiple locations, they would now live on the Forms page.
However, based on user feedback I would loosen this design approach. While bucketing content on pages made sense, having access to forms in other logical locations was convenient. In later designs, a Forms Tray was added to the Task List page.
Let's Organize
The original OPAS Portal had too many pages and the location of content was confusing. I decided to give each category of content a page that was easily accessible from the navbar. For example, instead of scattering forms in multiple locations, they would now live on the Forms page.
However, based on user feedback I would loosen this design approach. While bucketing content on pages made sense, having access to forms in other logical locations was convenient. In later designs, a Forms Tray was added to the Task List page.
Let's Organize
The original OPAS Portal had too many pages and the location of content was confusing. I decided to give each category of content a page that was easily accessible from the navbar. For example, instead of scattering forms in multiple locations, they would now live on the Forms page.
However, based on user feedback I would loosen this design approach. While bucketing content on pages made sense, having access to forms in other logical locations was convenient. In later designs, a Forms Tray was added to the Task List page.
04 / Design & Test
Take it back to users
One OPAS. Two Experiences.
To satisfy our large diverse userbase I designed two primary experiences.
One OPAS. Two Experiences.
To satisfy our large diverse userbase I designed two primary experiences.
One OPAS. Two Experiences.
To satisfy our large diverse userbase I designed two primary experiences.
Submitter Experience
The submitter experience was purposely minimalist with few distractions. The intent was to boil down the OPAS Portal experience into small digestible chunks that users with minimal experience could understand. So instead of displaying a list of hundreds of forms and work items, we provided users with a mechanism to find forms and a summary of their work items.
Submitter Experience
The submitter experience was purposely minimalist with few distractions. The intent was to boil down the OPAS Portal experience into small digestible chunks that users with minimal experience could understand. So instead of displaying a list of hundreds of forms and work items, we provided users with a mechanism to find forms and a summary of their work items.
Submitter Experience
The submitter experience was purposely minimalist with few distractions. The intent was to boil down the OPAS Portal experience into small digestible chunks that users with minimal experience could understand. So instead of displaying a list of hundreds of forms and work items, we provided users with a mechanism to find forms and a summary of their work items.
Approver Experience
Every design decision for approvers promoted efficiency and flexibility. The star icon (top right) provide access to a list of favorited forms. Now approvers could repeatedly open their most used forms without searching an extended list. The tabs across the top of the task list allowed users to work multiple instances of the data table with different active filters. Approvers no longer had to open multiple instances of the OPAS Portal in different browser tabs. And lastly, forms were accessible directly from the task list page. When needed, approvers could open the forms tray to view forms relevant without routing to a different page.
Approver Experience
Every design decision for approvers promoted efficiency and flexibility. The star icon (top right) provide access to a list of favorited forms. Now approvers could repeatedly open their most used forms without searching an extended list. The tabs across the top of the task list allowed users to work multiple instances of the data table with different active filters. Approvers no longer had to open multiple instances of the OPAS Portal in different browser tabs. And lastly, forms were accessible directly from the task list page. When needed, approvers could open the forms tray to view forms relevant without routing to a different page.
Approver Experience
Every design decision for approvers promoted efficiency and flexibility. The star icon (top right) provide access to a list of favorited forms. Now approvers could repeatedly open their most used forms without searching an extended list. The tabs across the top of the task list allowed users to work multiple instances of the data table with different active filters. Approvers no longer had to open multiple instances of the OPAS Portal in different browser tabs. And lastly, forms were accessible directly from the task list page. When needed, approvers could open the forms tray to view forms relevant without routing to a different page.
Lo-Fi Pages
Submitter Experience
Home Page
The new OPAS home page was intended to provide visual simplicity for novice users who have limited experience.
Submitter Experience
Home Page
The new OPAS home page was intended to provide visual simplicity for novice users who have limited experience.
Submitter Experience
Home Page
The new OPAS home page was intended to provide visual simplicity for novice users who have limited experience.
Priorities
01
Visual simplicity and minimalism
02
Focus on prioritizing simple language
03
Reduce perceived options and actions
Priorities
01
Visual simplicity and minimalism
02
Focus on prioritizing simple language
03
Reduce perceived options and actions
Priorities
01
Visual simplicity and minimalism
02
Focus on prioritizing simple language
03
Reduce perceived options and actions
Approver Experience
Task List Page
The new task list page was intended to get power users to their to-do items as quickly as possible.
Approver Experience
Task List Page
The new task list page was intended to get power users to their to-do items as quickly as possible.
Approver Experience
Task List Page
The new task list page was intended to get power users to their to-do items as quickly as possible.
Priorities
01
Provide features for pro users
02
Tailor language for application user type
03
Allow users to customize their experience
04
Maximize efficiency and reducing time on task
Priorities
01
Provide features for pro users
02
Tailor language for application user type
03
Allow users to customize their experience
04
Maximize efficiency and reducing time on task
Priorities
01
Provide features for pro users
02
Tailor language for application user type
03
Allow users to customize their experience
04
Maximize efficiency and reducing time on task
Styles & Branding
The base color palette for the site would be lighter with soft shadows to show visual hierarchies. I wanted the application to feel approachable, bright, and new.
I also used color to help associate certain forms with categories. We called these categories "Areas". The intention was to assign a certain color to a category so that users would recognize a forms category from a glance. Since there were hundreds of forms, color helped quicky communicate the purpose of a form.
Dark mode was something early on I experimented with and was eventually implemented. I had learned from user interviews that OPAS approvers were spending hours a day looking at a screen which inevitably led to eye strain. Dark mode provided relief for this problem.
Styles & Branding
The base color palette for the site would be lighter with soft shadows to show visual hierarchies. I wanted the application to feel approachable, bright, and new.
I also used color to help associate certain forms with categories. We called these categories "Areas". The intention was to assign a certain color to a category so that users would recognize a forms category from a glance. Since there were hundreds of forms, color helped quicky communicate the purpose of a form.
Dark mode was something early on I experimented with and was eventually implemented. I had learned from user interviews that OPAS approvers were spending hours a day looking at a screen which inevitably led to eye strain. Dark mode provided relief for this problem.
Styles & Branding
The base color palette for the site would be lighter with soft shadows to show visual hierarchies. I wanted the application to feel approachable, bright, and new.
I also used color to help associate certain forms with categories. We called these categories "Areas". The intention was to assign a certain color to a category so that users would recognize a forms category from a glance. Since there were hundreds of forms, color helped quicky communicate the purpose of a form.
Dark mode was something early on I experimented with and was eventually implemented. I had learned from user interviews that OPAS approvers were spending hours a day looking at a screen which inevitably led to eye strain. Dark mode provided relief for this problem.
Style Goals
Use color to efficiently communicate information
The use of font size, weight and shadows to visualize information hierarchies
Reduce cognitive load by reducing text and replacing with icons and color
Reduce cognitive load by reducing text and replacing with icons and color
Style Goals
Use color to efficiently communicate information
The use of font size, weight and shadows to visualize information hierarchies
Reduce cognitive load by reducing text and replacing with icons and color
Reduce cognitive load by reducing text and replacing with icons and color
Style Goals
Use color to efficiently communicate information
The use of font size, weight and shadows to visualize information hierarchies
Reduce cognitive load by reducing text and replacing with icons and color
Reduce cognitive load by reducing text and replacing with icons and color
Usability Testing
I frequently usability tested the OPAS application when new functionality was added. It was important to me that OPAS designs were validated by users. The high frequency of usability testing prevented the application from deviating from user needs and sanity checked our design thinking.
Usability Testing
I frequently usability tested the OPAS application when new functionality was added. It was important to me that OPAS designs were validated by users. The high frequency of usability testing prevented the application from deviating from user needs and sanity checked our design thinking.
Usability Testing
I frequently usability tested the OPAS application when new functionality was added. It was important to me that OPAS designs were validated by users. The high frequency of usability testing prevented the application from deviating from user needs and sanity checked our design thinking.
01 Step
Preparation
Before conducting usability testing, I created a script and outlined what aspects of the application needed to be tested. Typically, these were new functionalities that had not been tested before. Then, I would create open ended tasks that would test each functionality. The tasks were based on goals a user might attempt in their day-to-day while using the application. Tasks never prescribed how to complete it. Additionally, each task was expected to be completed with a low error rate (<5%).
Often the note takers that participated in usability testing were not familiar with the application. Therefore, each task also included a section that highlighted what a note taker should be aware of and what metrics they should capture.
01 Step
Preparation
Before conducting usability testing, I created a script and outlined what aspects of the application needed to be tested. Typically, these were new functionalities that had not been tested before. Then, I would create open ended tasks that would test each functionality. The tasks were based on goals a user might attempt in their day-to-day while using the application. Tasks never prescribed how to complete it. Additionally, each task was expected to be completed with a low error rate (<5%).
Often the note takers that participated in usability testing were not familiar with the application. Therefore, each task also included a section that highlighted what a note taker should be aware of and what metrics they should capture.
01 Step
Preparation
Before conducting usability testing, I created a script and outlined what aspects of the application needed to be tested. Typically, these were new functionalities that had not been tested before. Then, I would create open ended tasks that would test each functionality. The tasks were based on goals a user might attempt in their day-to-day while using the application. Tasks never prescribed how to complete it. Additionally, each task was expected to be completed with a low error rate (<5%).
Often the note takers that participated in usability testing were not familiar with the application. Therefore, each task also included a section that highlighted what a note taker should be aware of and what metrics they should capture.
02 Step
Conduct Testing
Usability testing was usually scheduled with 5 users and lasted between 30 to 45 minutes. I wanted to keep testers engaged and respect their time. After all, our users had full time jobs. During usability testing, users typically completed between 10 to 20 tasks and were asked to think out loud. Periodically I reminded testers they weren’t being tested; the application was. I wanted to reinforce the fact that testers were testing the application and not the other way around.
At the end of usability testing, I thanked the user for their time and stopped the recording. Recordings were used to highlight successes and pain points experienced by users.
02 Step
Conduct Testing
Usability testing was usually scheduled with 5 users and lasted between 30 to 45 minutes. I wanted to keep testers engaged and respect their time. After all, our users had full time jobs. During usability testing, users typically completed between 10 to 20 tasks and were asked to think out loud. Periodically I reminded testers they weren’t being tested; the application was. I wanted to reinforce the fact that testers were testing the application and not the other way around.
At the end of usability testing, I thanked the user for their time and stopped the recording. Recordings were used to highlight successes and pain points experienced by users.
02 Step
Conduct Testing
Usability testing was usually scheduled with 5 users and lasted between 30 to 45 minutes. I wanted to keep testers engaged and respect their time. After all, our users had full time jobs. During usability testing, users typically completed between 10 to 20 tasks and were asked to think out loud. Periodically I reminded testers they weren’t being tested; the application was. I wanted to reinforce the fact that testers were testing the application and not the other way around.
At the end of usability testing, I thanked the user for their time and stopped the recording. Recordings were used to highlight successes and pain points experienced by users.
03 Step
Synthesis & Report
After usability testing was completed, I would summarize the results into a document. The report contained both successes and failures of the current design and outlined potential ways to remediate problems. The report was used to socialize UX issues to the team and explain where and why users failed certain tasks. I wanted to keep team members looped in with the UX process so they understood my decisions.
03 Step
Synthesis & Report
After usability testing was completed, I would summarize the results into a document. The report contained both successes and failures of the current design and outlined potential ways to remediate problems. The report was used to socialize UX issues to the team and explain where and why users failed certain tasks. I wanted to keep team members looped in with the UX process so they understood my decisions.
03 Step
Synthesis & Report
After usability testing was completed, I would summarize the results into a document. The report contained both successes and failures of the current design and outlined potential ways to remediate problems. The report was used to socialize UX issues to the team and explain where and why users failed certain tasks. I wanted to keep team members looped in with the UX process so they understood my decisions.
Thoughts & Takeaways
Taking a look back
Final Deliverable
The OPAS Portal final deliverable was the culmination of organizational goals, user feedback, and iterative change that proved to be a powerful leap toward user centric design within the unit and agency.
Accomplishments
Reduced help desk ticket volume related to incorrect form submissions
Received A+ 508 compliance rating from agency
Renamed forms using natural language leading to less user confusion
Lowered site load times by nearly 50% compared to original application
Removed remedial tasks such as repeatedly hunting for forms and re-configuring data table filters by implementing favoriting and incorporating multiple tables per instance
Accomplishments
Reduced help desk ticket volume related to incorrect form submissions
Received A+ 508 compliance rating from agency
Renamed forms using natural language leading to less user confusion
Lowered site load times by nearly 50% compared to original application
Removed remedial tasks such as repeatedly hunting for forms and re-configuring data table filters by implementing favoriting and incorporating multiple tables per instance
Accomplishments
Reduced help desk ticket volume related to incorrect form submissions
Received A+ 508 compliance rating from agency
Renamed forms using natural language leading to less user confusion
Lowered site load times by nearly 50% compared to original application
Removed remedial tasks such as repeatedly hunting for forms and re-configuring data table filters by implementing favoriting and incorporating multiple tables per instance
