International Student & Scholar Services - Enterprise System
The UT International Office provides immigration, advising, and health services to approximately 7,000 international students, scholars and faculty at The University of Texas at Austin. Staff members used a patchwork of outdated systems to manage all of their workflows, often requiring triple data entry. These quirky, disparate systems resulted in significant delays for many of the IO’s core services.
The department desparately needed a new, unified enterprise system that would speed up their vital workflows, and reduce the time it takes to train new hires.
Objectives
Design a web-based enterprise system to support key immigration, insurance and financial workflows
Liaise with developers regarding feasibility and sizing of features
Identify and manage project risk factors
Methods
Contextual inquiry & task analysis
Participatory design
Information architecture
Iterative wireframing/prototyping
Rapid usability testing
My role
Product designer & researcher
Project manager (near the end of the project)
01
Contextual Inquiry
I observed and interviewed staff members as they worked, and sat in on weekly meetings. This helped me understand the implicit rules and expectations governing advisors’ work processes. I identified several major pain points, including:
Coping with task flows in the “mainframe” (an old, text/command-based interface)
Double and triple data entry across systems
Managing present vs. future data about international constituents.
Shadowing staff members is not without it’s lighter moments…
Managing US immigration documents
02
Collaborative sketching with users
We met with advising teams to talk about how the a new system would work in an ideal world. We sketched, discussed and amended ideas on a whiteboard during the collaboration sessions.
03
Iterative Prototyping & Testing
In discussions with users, we sketched rough wireframes on a whiteboard. Later, I created mid-fidelity prototypes in Balsamiq Mockups with one of our software developers. I employed rapid usability testing methods to evaluate mockups, both with individuals and groups. We performed several iterations, updating and re-testing prototypes with users.
Insurance coverage - detail page (with comments)
04
Mapping Out The System
I used Visio to create a page flow diagram, which describes navigation methods and page hierarchy for the new system. I continuously updated the diagram as we worked out the details. The diagram also served as a map for visualising and tracking many aspects of the project in one place.
05
Risks & Setbacks
Although we successfully create a UX design for the entire system, a number of challenges affected our ability to build it.
All-Or-Nothing Approach
Everyone involved would have preferred to develop the new system incrementally. Unfortunately, we determined that synching data between new and old systems would be too risky and time consuming. The new system had to go live all at once, after a lengthy development period.
Institutional Change
As we were finishing the design, The University of Texas announced that it would retire its mainframe system and stop supporting applications built in NATURAL/Adabas. The developer team, accustomed to working with Adabas, was suddenly faced with learning both Python and relational databases well enough to build a large, critical system. As a result, the development timeline was drastically extended.
Turnover And Resource Demands
Other demands on the IT team’s resources, as well as developer turnover, also affected the feasibility of completing the project in a reasonable amount of time.
06
An Alternative Solution
When it became obvious that we faced indefinite delays in building the system, we investigated third-party software options a second time. One product we revisited, although not ideal, had improved enough to meet many of our user’s needs. We carefully evaluated the product, discussed our concerns with the vendor, and ultimately chose to purchase the software.
Outcomes
Although we chose to pivot and purchase third party software, our design work still served an important purpose:
Based on the prototypes, I generated a list of 145 use cases / agile user stories that served as functional requirements. Those requirements served as a checklist for evaluating alternative software.
The prototypes will serve as a blueprint for customizing workflows and data fields in the vendor software.
Some of the prototypes may still serve as the basis for building smaller applications, for required functionality that the vendor software cannot address.