Washington 211 Usability Testing

Washington 211 is a state-run nonprofit web and phone service that connects people to critical community resources. WA211 primarily serves those who are experiencing crises and are low income. Usability testing was conducted to guide upcoming iterations of the website.

• What are the major frictions and confusing experiences encountered by users when searching for resources?

• How does WA211.org compare with 211CT.org?

• What are the recommendations that can be made based upon the usability test?

The Team

4 UX researchers and 1 WA211.org stakeholder

Duration

10 week usability course in the Human Centered Design and Engineering program at the University of Washington

Methodology

Participants

With stakeholder direction, we developed a screener to target users that fit the following demographics:

• having a cognitive disability and/or

• having limited English proficiency and/or

• having minimal tech literacy.

We deployed the screener to several different online communities and within the WA 211 network of agencies. We quickly discovered that participants who met the target users were difficult to recruit, partially due to the pandemic. Due to the strict timeline of the course and our inability to safely engage with participants face-to-face, we broadened our participant pool to include proxy and pilot users. These users had the following demographics:

• 100% reported using the internet daily

• 100% were between the ages of 18-26

• 85% identified as female

Despite this limitation, we were able to identify critical barriers to finding and utilizing resources.

Comparative approach

In this usability test, WA211.org was compared to 211CT.org, which was chosen because of:

• similarities in UI, taxonomy, and functionality between WA and CT

• previous comparative analysis of WA and CT by WA211.org stakeholders

• WA211.org utilized 211ct.org in their web development plan

Participants were randomly assigned to start with either wa211.org or 211ct.org to control for experience bias.

Test Plan

We developed and implemented a pre-test interview questionnaire, three tasks to be completed on both wa211.org and 211ct.org, and post-task ratings of difficulty.

Findings

Finding 1: Difficulty starting search

The visually busy nature of the homepage pushed the “find help” button below the viewport requiring scrolling to begin searching. Additionally, the homepage did not include a search bar which participants anticipated and the search bar was two clicks away from the homepage. The covid-19 chatbot occasionally obscured the “find help” button.

Recommendations

• Remove, shrink, or provide a means of closing the covid-19 banner information.

• Decrease the prominence of the covid-19 chatbot.

• Move the search bar to the homepage and place within viewport

Finding 2: Accessibility icon unrecognized

Participants had varied interpretations of the accessibility icon including:

• A dark mode

• A means of hiding aspects of the website

Recommendations

Utilize the international symbol of access. Hover effects and tooltips should state “accessibility”

Finding 3: Text-heaviness of resource page

Participants had difficulty understanding certain categories of information on the resource page and had to reread the content several times to understand. The text was dense and lacked definitions of key words.

Recommendations

In order to allow participants to quickly and efficiently browse resources we recommended that:

• bulleted lists be used to delineate information

• improve the visual hierarchy so users can determine important information faster

• increase the line-height to increase readability

• implement tooltips for hard to understand words and phrases

Finding 4: Lacking resource connection and next steps

Resource information was available to participants, but when they decided to pursue a resource, the links provided routed the participants to the resource homepage and not the next appropriate step to take to utilize the resource.

Recommendations

• Provide a direct link to an application or next steps on the external website .

• Provide information on the necessary application materials.

Next steps

A formal report was provided to the stakeholders of wa211.org. They reported that the implemented several of our recommendations. Further usability tests should be conducted on these recommendations

What we learned

This 10 week project from our initial stakeholder meeting to the final report was fast-paced and challenging. It was complicated by being fully remote due to the COVID-19 pandemic and the strict timeline of the course which prohibited us from recruiting target participants, however we learned a lot:

• The importance of flexibility and adaptability when a project doesn’t work out as planned.

• Open communication, especially in a remote world, is vital to meeting timelines.

• Qualitative data, such as user quotes, can be more informative than the quantitative clicks and taps.

• How might we make it engaging to minimize individual waste?

• How might we help people determine what is recyclable?

• How might we build a community to support waste reduction?

  As climate change intensifies, it is more important than ever to build a more sustainable world. We care deeply about this issue and we know we are not alone, so we set out to design a product that can support people in taking collective action on one piece of this large puzzle: minimizing personal waste.

The Team

4 user experience designers

Duration

10 week Human Centered Design and Engineering school project at the University of Washington

Where do we start?

We began the project with a simple question: How might we minimize personal waste? Preliminary research helped us better understand the market and where a potential waste management mobile application might fit. A competitive analysis found that half of the mobile applications viewed had categories to help users determine what was recyclable, but did not use the camera to allow for quick and easy to access information. We also discovered that these applications did not include any social aspects, such as community support or connection to events. Finally, we determined that all of the applications were informational in nature and did not include any gamification or badges to help motivate waste reduction. With this information, we proceeded to user interviews to better understand our potential users needs.

Talking with the people that matter

We interviewed 5 different potential users of a waste reduction application. Our main target audience were people that are interested in reducing their personal waste. After talking with them for about an hour each, we got together via a Zoom meeting and went over our main takeaways from each interview. Talking through each interview and breaking down the information into Motivations, Goals and Needs, and Hesitations and Pain Points was essential to fully understanding our users commonalities and what our product needed to provide.

User interview insights

Time for some questions

Concurrent with user interviews, we developed survey questions and distributed it to our networks. By utilizing both interviews and surveys, we were able to get in-depth information from some users and a breadth of information from a lot of users. Both aspects were important to understanding waste reduction behavior and beliefs.

Survey insights

• 70% of respondents lived in Washington state

• Most respondents were aged 18-40

• Most believed they recycled correctly

• Respondents recycle a variety of items

• Respondents reported placing items in the recycling even when unsure if they are recyclable

Defining our users

Using these insights, we developed one primary persona, one secondary persona, and two supplementary personas. Each of these personas were slightly different. Kyle, the primary persona, is focused on building a community and social responsibility. Sarah, the secondary persona, is focused on her family relationship, minimalism in buying, and the impact of waste reduction. Our personas also struggled with maintaining and developing good habits in their busy lives. We used these personas to guide our design work moving forward, targeting our primary persona and referencing the others frequently when thinking about the direction of our product.

Our design problem, refined

User research helped us focus in on the biggest barriers our users faced and provided a clearer definition of the problem we wanted to solve. Ultimately, our users wanted to do the environmentally-conscious thing, but sometimes life got in the way or they didn’t know the right thing to do. They wanted to form good habits, but being environmentally-conscious was time consuming and messy. Our users wanted to have a community and a way to show others that they were accomplishing their environmental goals. These essential insights helped us refine our design problem.

How can we meet our users needs?

The refined design questions gave us several directions we could take our product. We determined that the next step would be sketching potential ideas that solved these better defined problems our users faced. We each took an hour to sketch different ideas for our mobile application. When we came back together, we reviewed our sketches to see the common ways we tried to solve our users’ problems, as well as the best solutions.

We determined that an application that utilized badges, points, and other aspects of gamification might motivate our users and engage our users in waste reduction, as well as build good habits. Ultimately, we needed to design something that overcame the negative aspects of recycling, like cleaning, sorting, and storing items, and allowed for good habits to take hold. This also filled a gap in the competitive analysis conducted at the beginning of our design project.

A camera function that analyzed an image and provided information on recyclability would help users with quick and accurate information, and also filled a competitive analysis gap. In addition, we wanted to provide a means for users to verbally ask questions and receive answers, so we considered voice interaction with an AI character similar to Oscar the Grouch. This also provided an alternative for visually impaired individuals to determine recyclability of items.

Finally, a community tab that included a forum, friends, and an interactive game board map would allow users to build a community of environmentally conscious friends in a fun way. Once again, we could solve a user concern and fill a gap in products available.

How does this work in the real world?

This application just had to make sense in our users’ day to day lives. Recycling, as our users stated and personas reinforced, wasn’t something that they did once per day or week. It was integrated within the context of their daily lives. And frequently, the hustle and bustle of their lives got in the way. For that reason, we determined that drawing up storyboards would help us understand how our users might fit this application into their lives. This helped us build empathy for our users and remember that they had complicated lives.

Yeah, but how do they get from A to B?

With basic sketches of our three different solutions and better empathy towards our users’ busy lives, we proceeded to user flows. This was an important step to solidifying how our users would move through our application to accomplish their goals. At the same time, we determined that we would have three main navigation options (Home, Scan, and Community) in the bottom navigation and within each tab there would be top navigation with elements that related to that main tab.

From A to B 2.0

With our personas and user flows in mind, we started wireframing potential screens for our application to explore different directions and layouts quickly. We worked individually on each tab: Home, Scan, and Community. As wireframing progressed, we realized that some functionality detailed in sketching and the user flows was not what users might expect in a native application. Initially, the Home tab sketch had kebabs to select whether a user would explore the badge or the challenge. Creating a top navigation allowed us to avoid modals and bottom sheets, and provided a more linear process for users. It also allowed users to see a clearer difference between individual badges and challenge badges, i.e. individual badges don’t always match up with challenge badges and vice versa.

Furthermore, in our initial user flows for the community tab, we had fairly extensive GPS locating and assignment of communities and events that locked the user into a particular community. Upon further iteration and reflection on our personas, we realized that locking a user into a community before presenting them with events to join was prohibitory to their waste reduction. We determined that events should be based upon proximity to the users’ current locations and not hometowns or other permanent locations, along with event topics the users subscribed to and events their friends had joined.

Finally, when thinking about the possible outcomes after a user scanned an item, we determined that we needed to include a means for the user to request information about a specific unidentified or unknown item. This allows the user to provide feedback and point out gaps in the application’s database of products.

It’s all about that iteration

With refined user flows, we were able to start wire framing and iterating our screens. We determined that we would begin iterating at the level of wireframe fidelity because we wanted to have a strong layout and visual hierarchy before adding in colors and images that might distract. This also allowed us to move quickly from layout to layout, examining visual hierarchy and placement to form a solid scaffold to build upon.

Earning badges was a key motivating factor to our design, so we wanted to ensure we provided enough user feedback about their progress towards the badge. We designed several different ways of demonstrating this progress, as well. We determined that a simple circle with a closing ring was familiar to users and allowed the user to see the whole badge without obstruction and see their progress visually.

Is this usable?

Given the time constraints of the project, we conducted usability testing with three users on the Scan tab and four users on the Home tab.

Scan tab usability testing insights

• Users were confused about the phrasing of location to recycling receptacle

• User was unsure about what action to take after analyzing completed and information presented

• User wanted to scan multiple items at a time

• Users struggled with the microphone option because the prototype did not allow for actual speaking

• Users were unclear if an item was recyclable when information was presented

• Users did not readily see the microphone option

Words matter

As we began to finalize our designs and get further design feedback, we talked about how to clarify the meaning of some navigation. In order to address the general confusion about what “Scan” meant (“Is it QR codes? How about barcodes?”), we changed the tab’s label to Analyze. We need further usability testing on this term change, but ran out of time.

As a team, we discussed what Home meant in navigation in other applications. Based on our personas, we determined that our users might expect a Home tab to be similar to Facebook’s running list of friend’s posts or Instagram’s scrollable images posted by friends. Our Home tab did not contain that information, so our users might have different expectations with a Home label. In order to provide clarity to our users, we renamed the tab to My RiCi to exemplify that the tab contains information about the user and their waste management behaviors. We need further usability testing on this term change, but ran out of time.

We also had discussions about what Events consisted of and where they should exist within the application. We determined that our understanding of Events was two-fold: Events in the Community tab were in-person lectures and gatherings and Events in the newly re-named My RiCi tab were digital competitions similar to challenges in other applications. Because users were familiar with challenges in other applications, like exercise applications, we determined that My RiCi’s Event label in top navigation should be renamed Challenges. This label change provided familiarity to users and was confirmed in usability testing.

The look and feel of the product

Material UI icons were used throughout the prototype to provide a cohesive look and feel to the product. Many users are familiar with these icons, as well, so it is easier for users to understand the iconography and meaning in our application. We determined that green would be a good brand color as green is associated with the environment and we ensured that we met color accessibility standards when selecting the hue. Finally, we utilized Open Sans for the font for its readability and friendly feel. We designed a style guide that would ensured correct colors, text hierarchy, button sizes and other user interface elements would be implemented correctly by potential developers.

Hi-Fi(ve!)

After completing usability testing, making changes, iterating, and defining our navigation we solidified our designs and created a high-fidelity prototype of our application. We all worked hard on our individual tasks, and open communication was integral to our success. We met frequently via Zoom meetings to provide design feedback, Figma tips and tricks, and discuss next steps in the project.

Looking back on what our users wanted, we can see that we created something that met their needs and that they enjoyed using. During usability testing, many users commented that they needed this application in their lives and said that they would love to earn badges while doing something good for the planet.

Next steps

If we had more time, we would want to continue usability testing on our most recent iterations. We also would like to explore how to better differentiate between badges earned during individual endeavors versus badges earned in community challenges. With badges being integral to engaging the user over time, we would like to design more variety, as well as consider different ways of presenting them to the user such as sticker sheets with outlines to be filled in when badges are earned.

Many users also wondered if they could take an image of a pile of recyclables and have the application automatically add the individual items to the badges. We would need to explore this concept further before knowing if it is technically feasible.

When considering the Analyze tab, we did not consider an important fail case and did not provide a solution for it. It would be beneficial to design a form that users could complete if an item was unidentified. For example, if a water bottle was analyzed, but not identified, a user could be direct to screen with drop down menus that propagate based on previous entries. So the user could select water bottle, then the next drop down content would be populated with vital information for identification and so on until a proper identification and information could be provided.

Finally, because some users were overwhelmed with top and bottom navigation, it would be beneficial to explore moving some top navigation elements into the bottom navigation, such as moving challenges, individual badges, messaging, and notifications down. With these considerations, it would also be helpful to conduct a card sort on our revised information architecture to ensure we met users expectations.

What we learned

This 10 week project from inception to high-fidelity prototype was fast paced and very rewarding. It was complicated by being fully remote due to the COVID-19 pandemic, but we all rose to the challenges and designed a functional, useful, and beautiful application. We learned a lot:

• The importance of open and frequent communication, especially when working remotely.

• Definitions of words make a big difference in how a user understands the product.

• Sometimes initial user flows don’t make sense after fully understanding user expectations.

• You can’t always accomplish everything. Get to the stuff your users need right away.

• User research is the best way to understand what design questions you should be asking.

Micro-business CRM and Scheduler

A small cleaning business in Idaho was experiencing growing pains and difficulties with responding to customers after hours. Partnering with engineers and another UX designer for a bootcamp project, we discovered the unique concerns of a small business owner and delivered a product that allowed for business growth and enhanced customer service.

• How might we streamline and digitize a pen and paper file system?

• How much we reduce customer response time?

• How might we allow for business growth?

My Role

• UX/UI Designer

The Team

• 2 UX/UI Designers

• 5 Developers

Duration

8 week school project

Understanding the cleaning micro-business

I developed questions for and led the stakeholder interview. Developing quick rapport with the business owner, understanding his current pain points, and ensuring we had a thorough understanding of his desired outcome was at the forefront of my mind.

Stakeholder Interview Insights

• Currently uses Google Calendar for scheduling

• All customer files and records are kept in a pen and paper fashion

• Difficulty responding to after-hours customer concerns because they cannot access records

• Does not need employee records management

• Desires a means of technicians uploading images in the field, as well as clocking in and out of jobs

How many users?

After talking to the stakeholder, we quickly realized that the web application had a user base of four users at the time of design and development. We had direct contact with the stakeholder and the administrator and planned on reaching out to the technicians as the project progressed. Because we had the real deal a phone call away, we did not develop personas or customer journey maps. We could reach out and ask their perspective, and did nearly every Friday during our stakeholder meeting.

How should the content be arranged?

It was vitally important to me that whatever we designed made sense to the user and integrated seamlessly into their pre-established work flow. I interviewed the administrator/receptionist to better understand her current process of job assignment, technician management, and response to customer complaints. After our first meeting with the stakeholder, my UX colleague and I determined the information architecture and user flows of the web app. We understood there were two different aspects to the web app: administrative and in-field.

Administrative

• Assign technicians to jobs

• Schedule jobs after receiving a phone call from a customer

• Manage after hours customer complaints

How do other business scheduling dashboards work and look?

In order to better understand our product’s niche, I assessed the competition. There were various business dashboards that could meet the user’s needs, but the biggest barriers were financial. The stakeholder repeatedly mentioned that he did not have extra funds as he was growing his business to spend on products. Furthermore, many of these products provided services that the stakeholder did not want or need at this time such as billing, maps, invoicing, and credit card processing.

Initial attempt at designing for stakeholder needs

We determined together with the developers that the main dashboard view would be a great place to start. We wanted to ensure that the user had everything readily accessible from a single click on the dashboard side navigation. We also tried to provide options to customize the dashboard views with real-time tracking of in-field technician work, ratings of technicians, and customer information.

The take home message from our first attempts

My favorite part of this while process was that as we got closer to the stakeholder’s ideal, he would fine tune his desires and give us even more clarity. The stakeholder provided us with fantastic feedback again and again. Initially, we fell into the trap of trying to over complicate and over design the whole product. We had to revisit our information architecture and simplify the tabbed navigation. I had to simplify and strip down our user flows to their bare essentials, remembering the real world workflows we were trying to integrate with.

More stakeholder feedback

• Rating technicians was not desired

• Job notes needed to be associated with each customer, and linked together

• Live feed was not practical or necessary

• Viewing the schedule of up to 15 teams individually was essential

• Quick and easy to see gaps in the schedule

• Scheduling is based on zip code

The look and feel of the product

UI decisions were made using Material Design as the design system. Iterations were key to making this product really shine. Design critique, “hallway” chats via Slack and Zoom, preference testing with users, developer collaboration and stakeholder feedback all played a role in fine tuning. When considering color palette, users were quick to point out a purple/red color was reminiscent of spilled wine and hard to get up stains - not a good look for a cleaning business web app.

Reality check: does this work?

Usability testing insights

• Users wanted to click on the calendar and not the New Appointment button

• Users sometimes did not even see the button

• Icon meaning was guessed when navigation was closed

• Separate screens for editing and adding broke user flow

• Confusion regarding icon meaning within individual customer view

• Once a user was within a tab, they were

  able to accomplish tasks

Initially, I had designed separate screens for many actions, like editing or adding a new technician. This broke the flow for users and lead to a disjointed and difficult to navigate experience. Following Material UI’s Guidelines, I incorporated more modals/dialogs so users could stay on the page they were currently working on. This lead to greater focus on tasks for the user. It also made more sense in the technician tab because of how little information needed to be updated and gathered.

What about mobile?

Mobile responsiveness was difficult with the amount of information in some tables. We had to make decisions regarding the most important information for the stakeholder based on our conversations with him. We understood that checking customer records was the main task he would undertake after-hours. We also knew that he wanted technicians to clock in and out of jobs and upload job images in the field. Initially, I attempted to make a more responsive looking mobile web app. This lead to vital content being pushed down below cards, harder to navigate accordion style cards, limited view images with small areas for notes, and overall a difficult user experience.

Design critique and iterations made the difference in taking the mobile web app from mediocre to meeting stakeholder needs. Removing non-vital information, turning cards into a table format, full-screen images, and using more intuitive gestures like swiping to archive and edit lead to a better user experience. Placing the navigation on the bottom mimicked the ever-present side navigation of the desktop, allowing users to quickly switch between tabs.

Pixel perfection delivered

Throughout this process, I worked directly with developers. They had a lot of great insight into what was and was not technically possible. In one instance, they caught a user experience problem - increased load time due to images. With that information, I was able to iterate the table view of customers to allow for fast loading times, which are critical to a well run business.

Sometimes what we were able to design was not able to be built in the time available. This was the case when it came to the calendar view. My colleague and I had many long discussions about the calendar and scheduling keeping stakeholder needs in mind. He created a scrollable, multi-view agenda calendar which the stakeholder approved. However, the developers were only able to create a single calendar view with a drop down to select the cleaning team view.

What impact did this have?

The stakeholder was pleased with all the designs delivered and the attention to detail. He repeatedly called our UI “the dream.” I anticipate that the stakeholder/business owner will be able to view customer details easily after hours and respond to concerns hours or days sooner. Technicians will have a seamless means of uploading images to a database, adding notes as they go, ensuring good customer service. Scheduling by zip code will allow the administrator to decrease drive time for technicians, as well.

Next steps

If we had more time, I would have loved to fully iterate and integrate the in-field technician functions. This was slightly beyond scope for the first feature release, but was a key desire for the stakeholder. I’m contemplating turning the technician cards into a table view, similar to the customer view. The stakeholder mentioned he liked the images of the technicians, but I wonder if the product would feel more integrated with all table views. The developers also contemplated a React Native App, but did not have the time to build it. It would be interesting to design more functionality based on a native application. Finally, there are many buttons in the app that may be better served with iconography - a trash can instead of a delete button. This may streamline the app even more, leading to less text information for the user to process.

What I learned

This 8 week project from inception to shipped product was full of ups and downs. I delivered a design that was iterated through 100s of screens based on design critique, stakeholder feedback, developer collaboration, and Material UI Guidelines.

• The importance of managing stakeholder needs and desires with technical and time constraints.

• Iteration is key to making a product that not only looks good, but works.

• Design isn’t a linear process, sometimes you have to start over because you didn't understand.

• Less is more - don’t try to do everything. Just do what you need to.

• Collaboration makes a world of difference.

English language learning school web application

SpeakOut Bahrain is an English language school that helps children overcome economic barriers by providing English lessons. The school needed a means of collecting payments online and users needed to trust the payment process. Exploring cultural implications played an important part in my design process.

How might we reduce barriers to learning English in Bahrain?

Knowing English is the key to economic security in Bahrain, but there are many barriers to children learning it. SpeakOut aims to conquer those barriers by providing online access to registration, tuition payment, and eventually classes.

Understanding Bahraini culture

Stakeholder Interview Insights

• There are many barriers to children attending classes, including lack of transportation, parental time and money

• Families discover SpeakOut through Instagram

• Most Bahrainis use BenefitPay for debit card transactions

• Most families and teens use mobile devices and do not have laptops or personal computers

• Highlighting native English speakers is important to her company

A prototypical Bahraini father and daughter

Based on the stakeholder interview, we determined that users of the website could be parents and older tween and teen children.

The timeframe, distance, and language differences could potentially impact our ability to design with the user in mind. Proto-Personas and customer journey maps were integral to maintaining empathy, cultural sensitivity and direction during the design process. I collaborated with another team member to develop a father and daughter customer journey maps.

Discovered cultural implications

• Hijabs on women and young girls

• Personal connection in business interactions

• Business relationships take time to build

• Communication is more formal and hierarchical

• Right to left motion and reading of Arabic

• There were cultural implications to color choice

A lesson in content and information architecture

I strongly suggested that we conduct a card sort on the information architecture developed to ensure our users could find information when they came to the website.

Despite the initial IA success with minor variations, we had to reconsider the information architecture not once, but three more times. We had hoped to group more content on certain pages, but when we got to the mobile wireframes we quickly realized that the amount of content per page led to a lot of scrolling.

With that in mind, we reorganized the information and broke down the content into easier to access categories. Using the fourth iteration of the information architecture, we developed a site map and user flows through the MVP of tuition processing and registration.

Exploring possibilities through sketching

Landing Page

I completed a couple rounds of Crazy 8s, trying to encapsulate the content above the fold for mobile as most users only have mobile devices and this redesign would be responsive.

In order to build consensus, we gathered all our sketches together and dot-voted. We were nearly unanimous on the landing page that best fit stakeholder and user needs.

More sketches and notes about the payment process

Before I progressed into wireframes, I quickly drew a few sketches and wrote some notes on the research I discovered about BenefitPay. I assumed most users would worry about the security of websites asking for credit card information, so I wanted to ensure that I presented them with a process that was expected and used the debit card transaction company in which they were familiar. I wanted the users to understand exactly what they were paying for, as well as have confirmation and a Thank You page for the payment. It was important to me that the user flow was intuitive and built trust, much like the porto-persona and customer journey maps portrayed Bahrainis.

Wireframes to test our ideas

In order to solidify our designs from our sketches and conduct initial usability testing, we moved into wireframes. I included without any redesign the BenefitPay Company gateway screen exactly as the parents would see it when paying online. I included a progress bar above so that users would know exactly where they were in the process and how many screens it would take to complete the transaction.

Reality check: does this work?

With all the wireframes complete and prototyped together, we used usertesting.com to have six people test our mobile design and five people test our desktop design.

Usability fixes

• Confusion about whether SpeakOut was an online school

• Who takes the placement test? Child or adult?

• Continuity within the design is important even in the wireframe phase

• User remarked tuition payment was “No sweat!”

• Users appreciated the progress bar

Perhaps the biggest problem with usability testing was the lack of Bahraini or Arabic families. With many cultural implications, I would have liked to complete testing with target users to ensure that we were meeting their expectations, building trust, and had an intuitive process.

Visual accessibility: who can use this site?

Collaborating with another designer, I used Material Design as the inspiration for the design system. When I started designing buttons and text hierarchies, I checked the color contrast accessibility through WCAG and found that both the red and the blue in the logo did not meet AA standards. I used a slightly darker version of red that was accessible and within the color palette.

This was possible through collaboration

Working with 7 other designers on a project for two weeks was difficult, amazing, and fulfilling. It was wonderful to see how other people viewed the problem and wanted to address stakeholder and user needs.

I was able to provide a succinct and user-friendly Tuition Payment process. Another group pushed hard to have an amazing registration process, considering multi-child families. We pushed ourselves to include online test taking and completely redesigned the website from landing page to content pages. Two team members also completely designed a dashboard in which families can track student progress.

I was focused on ensuring that our website was visually accessible to all people. I was also motivated to ensure our landing page was the best it could be given the time and image constraints we faced.

What about the Arabic version?

After shipping the English version of the design, I decided to spend some time making the Arabic version. I thought about the Right-to-Left (RTL) aspect of the language and motion. I also used Google to translate the English text into Arabic, so there may be mistakes. One of the best aspects of the typography, Mada, chosen by the team is that it has an Arabic version that appeared readable and with different weights. When I was converting from English to Arabic, I had to create more vertical space between lines of text due to the dots under some letters. I also had to change space between columns to create a more pleasing visual flow. It was interesting for me to remember learning about F and Z eye patterns and how for Arabic websites those patterns are reversed. Finally, I had reached out to someone who speaks and reads Arabic to check in about the check mark orientation. She was quick to point out that the check mark should not be RTL, but the progress bar should be.

More iterations

After shipping the product, I decided to spend some time perfecting the design. I changed the blue text to a more neutral “black,” removed the red line that separated the header from the body and made links look more clickable to help users better interact with the app. I also iterated the progress bar, exploring different ways of informing the user of where they were in the process. Trying out different options allowed me to see which was informative without being visually overpowering to the user - the progress bar should be informative while not distracting from the user’s main task.

Next steps

Given more time, I would want to conduct more usability tests on a few aspects, including recruiting Arabic or Bahraini families, and iterate. However, I feel that the results of our usability tests and changes implemented will allow all users to pay for tuition, register their children, view progress, and learn as much as they’d like about the school before registering.

As a team of 8 designers, we worked hard to ensure that people like Naveed and Amira would have a great experience with the website, build trust, and spread the word about SpeakOut to their friends and family.