Turning a paper-based application process into a guided, scalable digital workflow.

Understanding how applications actually moved through the organization

The documented process did not fully explain how applications were handled in practice.

I interviewed graduate students, academic supervisors, and administrative staff to understand how people completed applications, interpreted funding requirements, corrected mistakes, and communicated status.

I also reviewed existing forms and historical application patterns. This exposed the points where users became confused and where staff had created manual workarounds to compensate for gaps in the process.

The research showed that many apparent “form problems” were actually workflow problems. Applicants lacked guidance, supervisors lacked structured decision support, and administrators lacked consistent information.

This distinction shaped the product strategy.

Reorganizing the application around user decisions

The paper application presented users with a large amount of information at once, even when some questions did not apply to their situation.

The digital experience divided the application into clear, manageable stages. Related information was grouped together, and conditional logic determined which questions appeared based on earlier responses.

This created a more focused experience:

• Users only saw questions relevant to their application.
• Progress was visible throughout the journey.
• Applications could be completed in logical stages.
• Required information was explained in context.
• Validation identified missing or incorrectly formatted information before submission.
• Smart defaults reduced unnecessary entry and repeated work.

The objective was not to make the application feel shorter by hiding complexity. It was to present the right complexity at the right moment.

Building funding rules into the product

Budgeting was one of the most consequential and error-prone parts of the original process.

Academic supervisors had to interpret funding rules, determine eligible allocations, and complete calculations manually. Mistakes often resulted in additional review and communication.

The portal introduced a structured budgeting experience. Funding rules, grant limits, and allocation requirements were represented directly in the workflow. As supervisors entered information, the system applied the appropriate calculations and identified values that required correction.

This changed the role of the product. Instead of acting only as a place to collect information, it actively helped users complete the process correctly.

It also created greater consistency in how funding requirements were applied across applications.

Connecting submission, review, and approval

The original process provided no shared view of application progress.

The portal connected the major stages within one workflow:

• The applicant completed and submitted the application.
• The academic supervisor reviewed the submission and completed the budget.
• Missing or invalid information was returned to the appropriate participant.
• The corrected application continued through review.
• The completed application and budget became available to the relevant stakeholders.

Applicants could see when an application had been submitted, when additional information was required, and where it was in the review process.

Supervisors could focus on the applications awaiting their attention. Administrators gained a more consistent view of progress and outstanding actions.

This reduced the ambiguity created by disconnected paper documents, email threads, and phone conversations.

Creating a reusable application foundation

The organization needed to solve the immediate application problem without creating another one-purpose system.

I defined reusable patterns for:

• Multi-step applications
• Conditional questions
• Validation and error handling
• Role-based review
• Budget calculations
• Status communication
• Corrections and resubmission
• Administrative oversight

These patterns created a foundation that could support additional programs and application types without redesigning the complete experience each time.

This was an important product decision. The value of the portal was not limited to the first application workflow. It established common capabilities the organization could continue to use.

Connecting product definition with implementation

I created wireframes and prototypes to test the structure and behavior of the portal before implementation.

Early concepts focused on application organization, navigation, workflow transitions, and role responsibilities. More detailed prototypes were then used to validate interactions, content, validation states, responsive behavior, and accessibility.

Testing focused on realistic tasks rather than asking users whether they liked the interface. Applicants completed sample submissions, supervisors reviewed information and prepared budgets, and internal teams evaluated administrative scenarios.

I worked closely with engineering to translate the validated experience into reusable front-end patterns and implementation requirements. Interactive HTML templates helped communicate intended behavior and reduced ambiguity during development.