Sometimes I do research, analysis or design pieces on larger projects. The examples below are a couple somewhat complex business process analysis, user/application flow and wireframe samples.
Jump To
- Infosessions Registration Application
- Student Intake Registration Flow
- External Client Course Registration Flow
Information Sessions Registration Application
This was actually an application component of our much larger CMS migration and redesign, but since I did only BA, IA and interaction design work on it, I’ve included it with these other UX deliverable samples. It is also an application port to a WordPress custom post type from a standalone tool, with a few enhancements.
What I Did
- business analysis & partial requirements
- flow diagramming
- wireframes
General Process
I had initially built and was iterating on an agile requirements dashboard (from user stories collected), which was comprised of background, goals, user/business research, links to prior documentation, and a matrix of key user stories, always updated with the latest Moqups flow/wireframes. Additional work has been continued since then, which included new stakeholder meetings to flesh out ‘nice-to-haves’.
- I mapped the initial application into main actor/user stories
- we (another BA and me) met with internal application users to verify what we had mapped and do some ideation work for potential additional features
- I built the roles and processes into the flows below
- front-end wireframes are very basic with placeholder site chrome, while backend wireframes have been designed ‘the WordPress way’
- anything beyond the existing application functionality will be added to the development backlog for V2
User Role Application Flows
The four roles below are effectively maps of the original application’s capabilities, plus a few additional capabilities that came from either stakeholder research or that we will have with WordPress, which we didn’t before. I also made an attempt to consider default WordPress roles and how the application roles could map to them.
L-R ~ attendee, presenter, owner and admin user role flows
Key Back-end Wireframes
The application has been designed as a WordPress custom post type. We looked at a couple different options, including customizing The Events Calendar, given its core functionality. However, our lead developer found that starting with a custom post type gave us more flexibility. Even attendees are also a custom post type, related via Post 2 Post functionality.
L-R ~ Full listing of all sessions to WP standards, Add new / edit existing session, full listing of all attendees, email/attendees screen. Click any for overlay.
Key Front-end Wireframes
The front end has a very simple interaction model. Most traffic is deep-linked to single sessions, but they can also hit the Infosessions landing page and filter/sort sessions based on program and learning sector. Similarly, we already have a mailing list app with a front-end web panel for managing subscriptions, and I used that model for managing Infosession registrations in part for consistency for our users.
L-R ~ Landing page with filter/sort capability with registration session overlay (error styling displayed), success overlay, end-user attendance management panel (description hover state displayed), and key user email wireframes. Click any for overlay.
To Be Built
The full project was completed after I left BCIT.
…
Student Intake Registration Processes
This project was part of was a very large review of all institutional processes for student applications into programs, which were varied and numerous. The overarching goal of this project was to streamline the general processes and reducing variations. I was asked to map out front-end user touch points.
What I Did
- business analysis
- flow diagramming
- UI screen planning
Challenges & Process
Requirements were almost entirely technical for this project by the time I was involved. Existing business processes had been revised and mapped, and desired improvements were envisioned almost entirely from the business point of view. Vendor selection had already occurred prior to determining all aspects of what the new system would need to do and, again, as I wouldn’t be involved in the project in later development/implementation phases, I was only working with internal resources to clarify and map out a flow for web implementation.
- The first phase involved leading brainstorming/whiteboarding sessions where I asked business leaders to ‘put on their student/applicant hat’ and envision what they’d like the experience to be. This was hard, but very useful, as it helped reduce myopia and got stakeholders outside their comfort zones.
- The second phase involved working with the business analyst who had mapped the existing/desired business processes, to reduce them down to the front-end touchpoints our students/applicants would experience, and thus help me map out the front-end web flow.
The final product
I developed the flow below in Omnigraffle, to be used as a user interface inventory/application map, which was then used for wireframes and interaction specs. After this stage was complete, the project took a very different direction, but as my flow was still used as a high level application plan, I feel the process and deliverable were worthy of inclusion here.
…
Client Course Management Application Flow
In 2014 BCIT’s Business Applications group was developing a course registration system for an external client. I was asked to provide some user experience strategy, clarify user roles and map out a flow for the application.
What I Did
- business analysis
- information architecture
- flow diagramming, UI screen planning
Challenges & Process
Course registrations for this client had historically been handled manually via a combination of a shared Access database and Excel spreadsheet. It was insecure, error-prone and regularly resulted in labour-intensive corrections and re-work.
- I was brought in quite late, which meant parachuting into work that was quite far along.
- As I wouldn’t be involved in final application development, there was no contact with external client stakeholders.
- I had to translate a largely technical requirements document, and talk to key internal stakeholders to understand user needs.
- I built this based on three key user roles, whereby each (student => facilitator => manager) built upon the capabilities of the previous one.
The final product
I developed the application flow below in Omnigraffle, the original being a clickable sitemap with several articulated application/user flows. A particular application user flow is determined by the assigned role at login, with sidebar interaction notes with numbered callouts for each panel. Scroll through the slider to view all functional application flows.
Application map and all user role flows (admin, facilitator, manager, student and role/permission management)
…