Verify and Attach Credentials

Fraudulent international credentials like degrees, transcripts and certificates present a huge problem for domestic academic institutions. Resource-strapped institutions struggle to verify the authenticity of international credentials themselves and even when the credentials can be verified, converting credits from international to domestic is time-consuming.

Prior to my joining this product team, a partnership had been established with Educational Perspectives, a Credential Verification Provider and a Digitary Inc. a Secure Credential Storage Provider. I worked with these partners and the product team to design an experience that benefited both our clients and their applicants.

Stakeholder Interviews

In order for this service to work, several departments would need to work together. Development time was tight and at the outset there seemed to be only 1 person, the Services Lead, who understood what was intended to provide. I partnered with a project manager and we conducted a lengthy interview with to understand the goals and needs of Services. We sketched a rough flowchart based on his feedback and began to validate with other stakeholders.

I then met with the client services lead to gain some understanding of client expectations and needs. Additionally, since this service was to be initiated from an application, I met with the Product Owner and a Javascript Developer from the Applications team to understand their needs. Finally, I spent several hours talking with our services partners to get an understanding of what information we did and didn't need to provide for them to fill the orders.

Information Architecture Volleys

Once the product requirements were taking shape, I had a clearer understanding of what the applicant workflow should provide. I started roughing out flowcharts of different paths the users could take to get from point A to point B. I drew and re-drew these, each time consulting with the product team to analyze strengths, weaknesses and opportunities. We went back and forth for a few weeks, expanding and simplifying as we went. After some time, common paths of least resistance took shape. I took the flowchart to the product owner for a final examination and he agreed we could use it to move on to the next step.

Identify the Minimum Viable Product (MVP)

Based on the flowcharts, we began to see some paths to release. The service needed to allow the applicant to initiate a Credential Verification Order. It would also have to allow the applicant to update the credentials at some point and have them re-verified. It would have to allow the applicant to attach the verified credentials to the application from which the order was initiated. It would also have to allow the applicant to attach the verified credentials to other applications, not just the original application. By examining these paths closely with the product team, we identified a few options for a minimum viable product. With a little more examination and thought, I narrowed it down to initiating a request and attaching it to a single application.

An Initial Set of Wireframes

Next, I documented what information we would need to gather from the applicants to fill an order. I broke the individual pieces of data needed into fields and grouped those fields into logical steps in the application experience. At the outset, I wanted the applicant to be able to initiate this service without leaving the application environment and I designed wireframes to facilitate this. The user would enter required information via a widget in the application, initiate the service, then complete the rest of the application. These initial wireframes were approved and presented at the Groningen Declaration.

Requirements Revelations

Following the initial wireframes, the Applications team began their work. This prompted new conversations that revealed requirements that were not clear during initial discovery. I worked with Applications to update the workflow to meet their needs. This process started out as small, minor tweaks but soon grew and began to require the creation of alternate paths for applicants based on a number of new variables. Additionally, as the conversations with our partners continued, I learned of new requirements from their end. As I hurried to make revisions to this application-centric initiation point, I began to think more about the larger picture. What's more, talk had begun about adding additional providers or adopting this service over to other products.

A UI facelift

During meetings with the product team, we all began to see more opportunities afoot than the application-centric approach would allow. I was asked to explore the product as a standalone service, free from any dependency on the application itself. Given this initiative, I revised the workflow and UI to allow for more flexibility and additional steps. The new workflow broke up the steps required to initiate an order much further than the initial one did and allowed for the user to be taken down multiple, optimal paths as the system captured their data. It was clear that a more flexible, modular approach would allow us to future-proof the user experience against any unpredictable additions or changes to the service requirements.

Usability Testing

Working with a user researcher, I organized usability sessions with a click-through prototype. We entered the test with one major objective to work from: determine if the average user can initiate a new order. Secondary to that was the objective to determine what level of understanding the user had of the process on a 1 to 10 scale. The scale was created via a series of questions about the experience as a whole. We ran the test with 10 users picked at random, all with no prior knowledge of the service. Following these tests, I analyzed the data and made a series of wording and layout changes based on those findings. Once those changes were made, we performed the tests with another set of 10 users picked at random and noticed an increase in speed and process scale.

HTML development

Once we validated and revised the workflow and UI based on usability testing, the project moved into the engineering development phase. I handed off the workflow and UI screens to an Angular developer who roughed out the service with some barebones UI. Once she was ready, she handed the roughed out UI back to me for HTML and CSS development. I wrote the initial markup based on pre-established CSS from the Applications suite. I was able to use much of the current CSS to meet the needs of the UI but still wrote a lot of custom CSS in order to get the job done. The end product was fully responsive and closely mimicked the experience of the application. Once I was done, I handed my work back to the Angular developer who finished it up and got it ready for publishing.

Onward and Upward

The second release was inherently more complex. It took what the MVP provided and connected it to additional applications. Users would not pay for an additional verification but they would pay a lesser fee to be able to attach their verified documents to other applications. To align the team early on, I held a workshop to collaborate on workflows and design and to begin the intial steps of experience development.

Workshop, Rinse, Repeat

Following the workshop, the steps to accomplish the next release mostly mirrored those of the MVP. I would rapidly create sample user flows and present them to the PO and our partners for feedback. Once the workflows were settled, I would sketch up possible Interface layouts. When those made sense I'd create higher quality wireframes. Using the wireframes, I ran usability tests and further revised the UI. I then wrote the HTML, adjusted CSS as needed and handed off to an Angular developer with a functional specification.