Understanding the User

Looking at prior research

In our first meeting, the 5 of us were given some prior user research data by the existing team. Although the research was broad and some results were already implemented in the website, it gave us a sense of understanding about how users interact with the website.

One of the bigger features that interested our group was that some terms were confusing for users and needed more clarification. There was a big effort on classifying services within different categories to make the website have a clean interface.

Shown below is how the website looked like when we started the project:

Log in page

Landing page after login

Service page

User Research

Before starting user research, we had a meeting with our project sponsor and discussed about potential improvements. We came up with 4 criteria to focus on.

1. Improving the log in page’s UI

2. Adding a search bar

3. Redesigning the bulletin board

4. Removing the “pink box” error message which causes user frustration

My UX partner (aka. Brooke) and I pilot our user research and observe how users navigate through the website. We sent an email to a list of targeted customers for a 15-minute interview via Zoom. Unfortunately, we did not receive a good participant rate so we only interviewed 3 users.

Some of our notes from the interview

Defining the project

Defining the Project Scope

With our research data, we discussed with our sponsor in more detail on what to improve. Our Business Systems Analyst created a Business Requirements Document (BRD) to type out our focus for this project. The results were:

1. The log in and front page should be redesigned to help users easily navigate and find their service.

2. The search bar should be added to the front page so that users can search for any particular services they need.

3. The bulletin board should have a notification feature to grab a user’s attention if they have not read.

4. The “pink box” message should not look like an error message to users and should only appear when a user has partial access.

One of our priorities for the summer

Designing

Creating mockup options

Our sponsor wanted to see different mockup options before deciding on one design.

Brooke and I decided that since we were virtual, we will individually work on our proposed designs on Adobe XD and create different options for the team.

My design

Her design

Final Mockup Decision

Brooke and I presented our designs in the sponsor meeting and we ended up combining our designs for the final mockup.

This was the same for the log in page, landing page, and service page.

Log in page

Landing page

Service page

HTML & CSS Development

Now that our mockups are finalized, our 3 developers immediately started the development phase.

As both the Project Manager and the UX Designer, I played a close character working with them. We often have troubleshoot meetings with the SRS team head developer as well. They did an amazing job working together and distributing responsibilities, even after encountering challenges that risked our deadline.

Updates we would get on Slack

Testing

Usability Testing

Development is done and we finally have a website! Our changes are made in the dev version of the website so it is not fully integrated yet.

In our last stage, we ran a usability test. Our sponsors approached 3 customers for us to interview while we reached out to 3 other students. We wanted both qualitative data and quantitative data so we mixed task-based questions with feedback questions.

Our interview questions

Qualitative data:

We created a data report as a deliverable to the SRS team. The report consist of both individual impressions and common insights.

A big insight was many users did not notice the top menu bar to navigate into the service page. Although this wasn’t in our project scope, it was an extremely important challenge to point out for future improvements.

Research background

Quantitative data:

We also assigned users specific tasks to assess their ability to complete them successfully.

From our data, we concluded that the bulletin board was very prominent. 83% of users noticed it and took an average of 24 seconds to notice what was written.

Unfortunately, task 2 still needs some work because none of the 4 users knew they needed to request additional access to perform certain tasks. Our hypothesis is that users might not realize they did not have access because of the assumption that whatever we are asking them to perform should be able to be done.

Our tasks and results

Look at our mockup options.

Interact with our final prototype!

Check out the SRS Website.

Takeaways

• Appreciate the process. This project made me appreciate the UX Process much more than I thought it would. Without it, nothing would make sense and we would be creating designs for fun.

• You don’t know what you’d discover in usability testing. The entire SRS team did not expect that users were having a hard time just navigating into the services page. All of us thought that having a top bar was pretty straightforward but we obviously need to look more into that now.

• Teamwork is the heart of a project. Our project started off a little rough since we are all interns and strangers. However, the more we knew each other and the more we work together, our project blossomed with our efforts. Teamwork is a must.

Final thoughts

Occasionally, I get suggestions to go into UX Research instead of UX Design but I would stand firm on the latter. I also had this debate with my mentor asking me which side I prefer in one of our first meetings. This entire summer was me debating with myself which side I’d prefer - the UI, the UX, or the research.

In our last mentor meeting, I said: “Honestly, everything is turning to a blur as one.” My mentor agreed and said that everything in UX is intertwined. We can’t, or rather shouldn’t, see it as separate. The research proves the design and the UX is shown by the UI. Without one, there’s no purpose for the other. Kind of like a sappy romance story haha.

That settled the debate.

Local ->