Paperworked Interactive Prototype
Paperworked is a web app that adds interactive playback to annotations on PDFs, essentially allowing users to author step-by-step guides directly on documents. It was designed as a part of my undergraduate senior design.
In order to see how the idea would work, I created the prototype above on Adobe XD.
World at Penn Assistant
I wanted to demonstrate the potential of a proactive virtual assistant that would help international students complete important immigration-related tasks. I focused on a few things to give the assistant more natural and user-friendly,
Conversational and friendly language.
Clear differentiation between message types: ✅ for confirmation, ✳️ for starting a task, 🔸 for a reminder, and ➡️ for call to action.
Tasks and uploads done directly through messages.
ISSS Online Queueing System
Before starting, I thought about the the minimal set of interactions necessary for . Before mapping out the user journeys, I identified the variables that inform the instructions, notifications, and the user state:
Date and time: queue closes before advising.
Length of queue: if nobody is waiting, they should just walk in.
Whether the user is queued.
Length of time in queue.
Whether the user is physically present at the office.
Based on the steps and the variables, I began mapping out the user journey from the landing page to completion, incorporating the variables above. Once the map was simplified to my satisfaction, I created plenty of mockups for each item on the map to illustrate the UI.
The most challenging part was determining a fair and straightforward way to manage the queue. This was quite the riddle, because initially, we wanted to give the physical walk-ins priority. However, this ultimately conflicted with the purpose of the project, so we abandoned the idea for a simpler solution: treat them the same, and the advisors will take whoever is present at the time. This scheduling algorithm was to be implemented on the staff side.
Things look very different for the staff. I had to consider different facets of the system:
The receptionist’s view
The queue display in the waiting area
Database and scheduling
For the receptionist view, I noticed that nothing needed to change because in the queue, the online and offline queuers are treated the same. The changes would be implemented in the backend, where existing functions would be modified to account for the online queueing system. For example, the receptionist can remove someone from the queue, and removing someone who is not present will additionally trigger a notification.
The queue display in the reception area would be modified to hide online queuers until they are physically present, because the display is only visible in the reception area. If the display showed names of people who are not present, potentially in front of those who are sitting there, it would be misleading to those who can actually see the display.
I outlined the process and the modifications in plenty of specific cases and examples, so that even if there is a loose edge case in the description, the developer can deductively arrive at the correct implementation.