BridgeEnglish is a global language school in need of developing a management system to deal with their high number of international admissions.
- First release: February, 2015
- Roles: Architecture, Interface
- Work under: Bridge Education Group
BridgeEnglish is a website that takes care of the enrollment of international students who apply for an English course that will allow them to study in American colleges.
BridgePathways -a product of Bridge- was the new way of offering students the ability to enroll online. BridgePathways has four centers in the United States, all of which serve as a gateway for international students seeking to gain admission to U.S. universities and colleges.
The process of admissions requires the submission of many forms and different types of information. And students frequently submit incomplete data, or they don’t have it all at once.
In addition to this, 80% of the students are from the Middle East, what makes it hard to talk with a representative in the US because of the time difference.
The enrollment process was long and tedious, with many items to cover and many conditionals depending on several numbers of factors. Moreover, as a student, you had to compile documentation from your country and college which could be hard to get in time. And after that, an admissions coordinator had to be in touch to deal with the payments via phone and email.
For the coordinators was painful as well, because they had to follow up with sometimes even 200 students at a time, and keep track of all the transactions on a spreadsheet that was later manually translated to Salesforce.
So this new product was a portal that allowed students to create an account and complete their required information at any time, at their pace. And a resource for the company to compile and organize the data.
The two mains goals were:
- A portal for students to submit information.
- Improving the managing of data for the admissions coordinators.
For this project, there were three product managers involved. In addition to that, there was a Salesforce analyst, a developer, and I was taking care of the Architecture and interaction.
This portal was replacing an old 9 step wizard form, and becoming a link between the user and the company’s database.
Because this program has been running for years, there was a lot of customer feedback and experience from the salespersons. That helped us trace the most common pain points and the possible workflows to address them.
The drop-off from the 9 step wizard was an issue. There were some required documents you didn’t know you have to get them to complete the process. That means having to start all over again in case the smallest piece of information was missing.
That’s when I volunteered to compile all the user research to create a product according to everyone’s needs.
The first step was conducting interviews with each one of the stakeholders to align business goals. Some of the remarkable quotes were:
- President: "We are growing. It’s time to find a way to scale when we add more universities."
- Marketing: "Students want to see their application status, and being able to modify the information at any time."
- Product Managers: "We are few people to deal with too many admissions. Pursuing students asking for their papers is very stressful."
After sharing the insights with the team, we all gathered to build the following hypothesis:
"We believe that creating a student portal for students applying for admission will achieve better control of their status. We will know this is true when we see completed applications without assistance."
There were three statements that during the process we tried to validate -or invalidate:
- User: "I want to be able to track and submit my information."
- Salesperson: I want to reduce the number of calls and emails."
- Product Manager: "I want to generate a lead even if the user doesn’t complete the nine steps."
Time to sort cards to build a sitemap
With admissions managers from Bridge and Universities, sticky notes and a big whiteboard helped us understand which ones were the data points that the authorities required for enrolling a student.
Based on the categories and the requirements of each information field, we crafted a sitemap with the assignment of one individual ID for each one.
As I mentioned before, there were many possible scenarios for each student. For that reason, we had to think of conditional fields appearing depending on the users’ choices.
A right way of solving this was by mapping the customer journey of each one of the scenarios. Again, this was a team effort because we needed input from all the different people involved in the various stages of the product lifecycle.
Probably at this point, wireframing was the most natural part thanks to having all the sitemap and architecture already in place. This part of the project was very straightforward – a form with fields tied to Salesforce.
The challenge was now to verify if our assumptions about the user’s navigations paths were correct. We added some visual aids and guides (tooltips, a help center), but we could only know if we were successful by running a usability test with users.
Usability testing sessions
We searched for existing users who were starting the process of enrolling in the old 9-step wizard website. With three applicants volunteering as participants, the assigned tasks were:
- User goal: Cancel a part of the total price.
- Task: Make a payment of $50.
- User goal: Request assistance.
- Task: Contact a representative regarding an accommodations issue.
Their feedback helped us make the last tweaks, especially in the help documentation and ways of contacting a representative.
After that, we started to build the portal. Based on Bootstrap 3, it was a responsive web application with styles coming from the design guidelines of Bridge Education Group.
There are some advantages to creating something step by step. But in this case, you could start from mostly anywhere from the whole list. The new portal addressed that by letting the user navigate through the interface and complete anything with no determined order. There was a progress indicator to use as a reference to know what was missing and what was not.
The sales team could log in and check the status without having to explore their busy email inboxes. The same thing happened to the students: Payment history was visible at all times, and that also brought peace of mind to the end users.
But, because this product was still very complicated, we didn’t want to deprive the students of having a one on one conversation. That’s why the phone number and email address were still available. However, the primary focus was on the chat feature, in which you could even check the conversation history at any time.
The UX Research continued
Every requirement and user stories that appear along the way went to our backlog. We assessed them in bi-weekly sprints, and changes were deployed online biweekly on each design sprint.
For organizing the process, we relied on the whole Atlassian ecosystem.
Confluence. All the results of the research were here. We used Confluence as a Wiki to track the evolution of the products over time.
Bitbucket. We worked with a Version Control System that let us coordinate different tasks despite the distance between the developers in Argentina and the Product Managers in Denver.
Jira. The place where we documented our SCRUM and organize the sprints with the team.