Directory of Services —
CodeYourFuture
CodeYourFuture (CYF) is a UK-based non-profit organization that trains some of the most deprived members of society to become web developers and helps them find work in the tech industry.
Headquarters
London, UK
Industry
Education, SaaS,
Non-profit, Web
Duration
3 Months
Role
UX Designer
Team
2 x Designers
1 x Project manager
Responsibilities
—
UX Audit
—
User Research
—
Information Architecture
—
UI Design
—
Prototyping & Testing
• Identified user needs and business requirements from UX audit and user interviews.
• Produced user research reports, user personas, information architecture, and other design deliverables to support the design process.
• Conceptualized wireframes, UI designs, and prototypes.
• Validated designs at various stages of the design process.
Discovery
Every minute, 24 people around the world are forced to flee their homes in the hope of finding safety and a better tomorrow.
The UK is home to approx. 1% of the 25.9 million refugees, are forcibly displaced across the world.
In the UK, 48% of decisions made in the year ending September 2019 resulted in a grant of asylum or other forms of protection.
People seeking asylum are often living on Home Office support equivalent to just over £5 per day.
Services Directory strives to become a resource for caseworkers assisting refugees and asylum seekers, enabling them to discover and effortlessly share accessible services for refugees throughout the UK. The platform will be community-driven, allowing users to apply for Editor roles and modify or update information directly.
Pre-existing insights
A study conducted by Help Refugees and Refugee Council utilized focus groups, interviews, and surveys to gather valuable information regarding refugees and asylum seekers. Their needs varied from necessities like food, water, and shelter, to long-term requirements such as integration and employment opportunities. These individuals heavily relied on caseworkers for assistance and were often unaware of available apps and directories. Additionally, caseworkers themselves frequently depended on Google searches, Google groups, and word of mouth to discover and disseminate information on accessible services.
Key goals
To meet basic needs (food, shelter, education)
To signpost & help clients navigate systems
To help their clients integrate into society, through education, employment, and language.
We also discovered numerous findings regarding the tools in use, the obstacles encountered, and the potential of technology to assist them.
User interviews
Along with this research, the team also conducted qualitative research by interviewing 6 caseworkers from a range of refugee organizations. Interviewees were asked questions about their organization, their role, day-to-day activities, what tools they use, how they use those tools, etc. These interviews were later summarised and used to create our user personas.
Pre-existing Solution
When we started working on the Service directory website, there was already a simple version of the website designed and developed by the CYF students as a part of a hackathon. The website worked well and was already being used by a few organizations across the UK. Even though it was a great and very helpful tool; from a user interview session, we found out about the problems the users were facing. In the user interview session, we also conducted design validation sessions where 6 caseworkers from a range of refugee organizations were asked to share their views about the existing solution.
Key takeaways from the design validation:
Updates: The directory needs to be regularly updated. Updates need to be signaled in an obvious way.
Location: The location of service in relation to the client should be as clear as possible when searching or filtering.
Consistency: Any service information needs to be consistent in format.
Search: Search should be simple and easy to use.
Sharing: Caseworkers share the results of the search as a printout, in email or over the phone.
Experience: Overall, interviewees liked the simplicity of the design, the vision and value of the service directory in saving and creating time.
Market research
We started researching similar features in other existing websites, their implementation, and how well they worked. We looked at organizations working with refugees and other disadvantaged groups like RefAid, Help In Leeds, Church of England, MiCLU, and A church near you; as well as a range of general websites with similar features like Airbnb, NHS website, Wikipedia, Asos, eBay, etc.
Key finding:
Combinations of one to three search parameters were a simple and effective way to narrow down search results. Other search parameters were given with the search results to filter the results even further.
The option to view items on a map along with a list helped find their location and proximity.
The ability to change search parameters without going back made it quick and easy to search.
Some websites like Wikipedia, and MiCLU showed the last update status but many of the other websites like UK Gov websites, Divide, Charity Choice, etc didn't show the status.
Some websites allow to sharing of results via email form.
Some websites had lengthy documents about editing and some had video explanations.
Define
Prioritizing features
After researching we decided to work on four key areas of the website: Search, Results, Share, and Edit. These were the primary functions performed by the caseworkers on the website.
Search: Caseworkers can quickly search for a relevant service based on the client's needs and location. Navigation should be simple and easy to understand for new users.
Results: Caseworkers can skim through the search results and read relevant information like service type, contact details, etc without opening the result. Results and information should be consistent across the website.
Share: The Caseworker can share the relevant services with the client primarily offline but sometimes online. Clients don't need to register to view the service.
Edit: Caseworker can request to be an editor. The approved caseworker can edit existing and add new services to the directory. The caseworker can view the updated status of each service.
User interviews
Along with this research, the team also conducted qualitative research by interviewing 6 caseworkers from a range of refugee organizations. Interviewees were asked questions about their organization, their role, day-to-day activities, what tools they use, how they use those tools, etc. These interviews were later summarised and used to create our user personas.
Personas
Next, We used all of the qualitative data we gathered during the research process to create three personas. We referred to them throughout the entire product development process.
User Flow
We mapped out the users’ steps to see how we could simplify their journey to help them reach their most important goals with the directory as quickly and efficiently as possible.
Design
Wireframing
Based on our research and analysis, we started working on wireframes. We decided to work on the search and navigation first. We had multiple brainstorming sessions along with the design firm Fello, where we sketched out navigation and different layouts. After multiple iterations we decided on two designs that we found to work best, followed by wireframes for A/B testing.
First wireframes
Wireframe iteration
After the A/B testing, we found that some elements of both designs worked well. Some of the key findings:
The map feature was found very helpful to quickly locate a service.
The top navigation was better than the side navigation.
In design 2, the collapsing search was found confusing and harder to navigate.
Selecting multiple categories for the search was very handy.
Based on the testing results, we designed another wireframe which consisted of the features that worked well in the previous design as well as some new improvements. After designing the new wireframe, we did a design validation and it was found that the design worked well as compared to the original design. Users were quickly able to narrow the search and locate the services. Navigation was also found to be much clearer and simpler to use. It was also found that the ability to use the website without login would also be very helpful for new caseworkers and also make it easy to share the services with others.
Final wireframe prototype
High fidelity designs
Next, we started working on the search results and onboarding experience. Again we had multiple iterations for designs and finalized two designs each for testing. For search results, we designed a grid card list and a dashboard-style vertical list. For the onboarding, we designed a version with direct login and another with a welcome screen for a more personalized experience. We also designed other elements of the dashboard.
Search results design
Prototype
Then we combined all the final design ideas to develop two final prototypes with different layouts, onboarding styles, search results, card designs, etc for design validation.
Design #1 prototype - Landing page first
Design #2 prototype - Results first
Test
Testing process
We started testing early in the design process. Firstly we tested the preexisting platform that was developed by CYF students with 6 caseworkers. Then we tested our first set of wireframes for A/B testing followed by another user interview session with 4 different caseworkers. Later we tested our final set of prototypes. We also conducted usability testing sessions within the CYF team throughout the design process to get quick feedback for rapid iterations.
Design validation #1
The first round of design validation was conducted at the start of the design process as a part of the UX audit. The preexisting version of the service directory was tested with 6 caseworkers from a range of refugee organizations.
Design validation #2
After the research, we designed two sets of wireframe prototypes to test new layout ideas, navigation, and search functionality. A design validation session was conducted with multiple caseworkers from different refugee organizations. We got some valuable feedback with this usability session which was used to improve the design and develop a final wireframe that solved a lot of the problems caseworkers were facing.
We also conducted user interviews with 4 different caseworkers working in refugee organizations to gain more insights into the challenges they faced.
Design validation #3
The final design validation was conducted with 7 caseworkers from various refugee organizations. The sessions were conducted remotely over the Google Hangouts call. We tested various features of both designs such as onboarding, navigation, search, results, sharing, and editing.
Key highlights of these sessions were:
Design 1 (Landing page) was unanimously preferred to Design 2 (Results first).
The main highlight was a strong preference for a landing page, which after logging includes a personalized message.
Search and navigation were much simpler than the previous designs.
Maps were highlighted as a crucial addition in every round of user testing. The split map with results was preferred over the full-page map.
The use of pins on the map was currently found to be confusing as the correlation to the services was not clear.
There were some challenges with the categories of the naming convention and grouping.
The new results design was very intuitive, clear, and easy to skim through.
As a result, different services by the same organizations were found to be confusing.
Location search was found to be very restrictive in some cases.
The process of becoming an editor was not clear and required more information for caseworkers requesting to become an editor.
Printing out the results was the most preferred way of sharing. The results needed to be better optimized for printing.
Takeaway
Handover
After the third round of user testing, it was found that the project's scope had grown and CYF did not have the resources to drive adoption of the project. It was handed over to a large agency. It was saddening to let go of the project but it also made me happy that we built the foundation of the platform which will help thousands of refugees, asylum seekers, and migrants.
Improvements
Due to the lack of time and resources, we were not able to produce an overall functional design. Based on the user and industry feedback, three main priority areas were found that could be improved.
Version control: Keeping services up to date was essential for the caseworkers. The directory required a better way to manage the adding and editing for the services by the growing number of editors and admins. We looked at various ways other systems like Wikipedia, Google Docs, and Github manage the history and versions of the items. The services required a clear indication of the time of the last update.
Search: Comparing the new designs with the initial design, the search had improved a lot. It was much easier for caseworkers to quickly search for a service but with the new design, we had new challenges as well. Different search parameters like categories, location, distance, and search keywords are required to be more consistent and better regulated. A universal search like Google search was discussed which could filter results better based only on the search keywords.
Virtual rewards: The directory was a crowdsourced directory where the caseworkers were supposed to keep the services up to date. We need them to feel encouraged and valued for making contributions. The aim is to gamify the experience for Editors and make the idea of contributing/editing as appealing as possible - looking to introduce some sort of virtual rewards for crowdsourced inputs (e.g. a ranking board of most contributions, a ‘health’ bar of how up to date the system is, etc.). We want Editors to feel motivated to make contributions, to refer their friends to become Editors, etc.
Learnings
Working on a service directory project was an amazing experience. I was able to work with some of the most amazing people and learn a lot. The most challenging aspect was learning to work remotely for some of the design processes, especially when conducting user interviews and design validation sessions over the Google Hangouts call. Also, the majority of my previous experience was designed for mobile. Many times I found myself sticking to the mobile design patterns which didn't make much sense when designing for the web. Over time I became better at designing for the web, ensuring adequate accessibility.
Working along with developers (CYF students) who did not have a background in software development was inspiring. It reminded me of my journey of becoming a software developer and designer as I was mostly self-taught. It encouraged me to learn new skills and get over the imposter syndrome which held me back.
