Case Study - detailed analysis:

The Project

Project Scope

Open Room: Shelter for Homeless - Social Good Mobile Phone Responsive Application for Accommodation Booking

★ Designer's personal challenge (DPC): 

To create a fully functional dedicated responsive application (all flows and frames)

✦ Although the brief was to design a responsive website and application, I decided to focus on the responsive application only, and to design all possible frames for a holistic functioning product. I haven't had this opportunity before apart from designing the critical path user flows only, but this time I explored all potential frames and user flows.  

Project Overview

The product:

A dedicated responsive application (full product - all user flows) to help homeless people find and book accommodation in advance, especially during extreme safety and weather conditions. Open Room is a fictional charity to help homeless people through the development of the responsive application for booking accommodation. This is going to be very beneficial to the homeless community and it will help the individuals to have more access to protected sheltered areas, instead of rough sleeping.

Project duration:

November - December 2023

The problem:

Homeless people many times have difficulty in finding an available shelter in close proximity, or if they find a place it is fully booked. This is very frustrating and unsafe for the homeless community, especially during extreme safety and/ or weather conditions.

The goal:

★ This is a social good project (dedicated responsive application) and the goal is to enable and empower the homeless community to use technology for finding local shelters and booking available accommodation/ facilities in advance. 

★ This dedicated responsive application will utilise Internet of Things (IoT), for finding and listing the empty accommodation, including real-time updates, travelling distances and more related information.

My role:

★ UX designer

★ UX researcher 

★ UX writer, and 

★ UI designer 

[For all Phases - “Product Development Life Cycle”: Conception (Phase 1) to Delivery (Phase 5)].

My responsibilities:

★ Defined strategic project scope

★ Conducted strategic research

★ Conducted design research

★ Prepared empathy maps

★ Prepared personas

★ Prepared user journey maps

★ Prepare problem statements

★ Accessibility considerations 

✦ Languages

✦ Assistive Technologies (AT) 

✦ Building Accessibility Features

★ Prepared sitemap diagrams

★ Conducted interviews

★ Conducted usability studies

★ Designed paper wireframes

★ Designed digital wireframes

★ Designed low-fidelity prototype

★ Designed medium-fidelity prototype

★ Designed components to enable compliance with sticker sheet (design system)

★ Designed sticker sheet (design system)

★ Designed mockups

★ Designed high-fidelity prototype

★ Designed connections

★ Designed triggers and interactions (component graphics, motion and animation)

★ Incorporated findings from usability studies

★ Incorporated and coordinated design iterations 

★ Graphic design

★ Logo and branding design

Understanding the user 

User research: summary

I have done a few assumptions at the beginning of the project, such as:

★ Most homeless people have and know how to use smart phones.

★ They have constant internet access, and

★ They will be able to provide ID evidence documents in advance (for online ID verification).

I have conducted a survey in my local area and neighbourhood in South-East London, and in some parts of central London. I spoke to a few homeless people of various backgrounds, ethnicities, and genders and I have asked them a few qualitative and quantitative questions.

After conducting some interviews and doing some research in other applications and websites, I have concluded the following outcomes:

★ Homeless community might not have smart phones, and/ or know how to use them.

★ They might have smart phones and know how to use them, but they have very limited access to charging facilities (low battery). 

★ They might not have access, or very limited access to the internet, through their smart phones.

★ They might not be able to provide ID evidence documents in advance, and/ or when arriving at the shelter/ hostel, as most people don't have the documents or lost them.

★ Vulnerable populations might be included in the homeless community that need special safety and security measures.

★ Alternative arrangements and facilities are not included in other applications and websites. 

✦ During extreme weather conditions, it is crucially important to be included.

User research: pain points

1  Homeless community might not have smartphones or know how to use them. 

 Or they might have phones and know how to use them, but run out of battery. 

2  They might not have access, or very limited access to the internet, through their smart phones.

3  They might not be able to provide ID evidence documents in advance and/or when arriving at the shelter, hence access to be denied.

4  Vulnerable populations information to be included that need special safety and security measures.

Persona: Jane

Problem statement:

Jane (and her mother) is a homeless teenager, who needs immediate and reliable access to homeless accommodation in case any other arrangements fail. Because she and her mother need to protect themselves, from extreme weather conditions and any other unsafe situations. 

User journey map

Mapping Jane’s and her mother’s user journey has revealed how helpful and life/ safety critical would be for users to have access to an application, for viewing the availability and booking empty rooms/ bed spaces in sheltered areas (hostels, shelters, covered public spaces, etc.). 

Starting the design

Paper wireframes

★ The UX design must have very quick and simple use, no unnecessary steps, functions, heavy graphics that take time and consume internet data and cloud/ phone space to download. Possibly, most users don’t have their own phones or not enough battery, thus especially the "Accommodation Booking user flow" has to be very straightforward.

★ Accommodation search results to be presented on a map graphic (showing their location), in case the user is not familiar with the area street names and the approximate distance, and as a list, too. 

★ Further to the above items, quick access to latest searches and bookings to be provided to enable users to rebook the same place/ spot in the future (signed-out feature), and skipping the search part. Then additional searches and booking information to be integrated in the user’s profile for more analytical information and past results (signed-in feature).

★ A number of accommodation filters and options to be incorporated during the search part, and to include as many as possible users/ user types, in order to select their own "bespoke and preferred" safety and personal preferences. Safety and Accessibility (Language and Assistive Technologies) features to be visible constantly and accessible throughout all steps (frames of the responsive application). 

In conclusion, incorporation of the following centralised features is very important:

★ Logo (branding, colours, visual identity, etc.)

★ SOS - Safety feature/ alert (to 3rd party nominees)

★ Accessibility (Languages and Assistive Technologies)

★ Hamburger menu (for all other user flows, apart from the Accommodation Booking one)

★ Profile (avatar)

★ Favourites

★ Home and Return (navigation)

Below, I attempted to design 6 different options, and to choose the one best serving the aforementioned criteria. 

Sitemap

Below is the initial Sitemap, including the following features:

★ The sequence of tasks, activities and frames, integrating critical user flow paths and sign-in milestones, to enable full use and holistic operation. 

★ The user can complete the critical task of Accommodation Booking without signing in, but for full operation, more personal profile and privacy/ security related options, a sign-in access is required. 

★ Accessibility (Languages and Assistive Technologies) and Safety features, to be always visible for every frame (see yellow and orange features in the diagram below). These are some of the centralised features to be included in the design of all of the typical frame templates.

★ The critical user flow is the Accommodation Booking flow, where it consists of the following high-level steps:

✦ Identify user's location (GPS)

✦ User to chose accommodation and preference filters 

✦ Accommodation search and results (in accordance with the selected filters)

✦ Select preferred accommodation from the results

✦ Book accommodation

✦ Make payment (if required)

✦ Confirm booking 

UI design (some initial ideas)

★ The user interface (UI) design must follow the simplicity and fast results of the UX design. To mostly deploy vectorised graphics in Figma, rather than a number of high definition images that take time to download, view and consume battery.

★ The visual theme is to create an emotional reaction around the concept of home, personal space, safety and home-making. In consequence, to make the user more comfortable and willing to use the application and to promote a sense of a warm and welcoming environment.

★ Minimal text and mostly pictorial/ icon/ symbol graphical communication has to be incorporated to make the application overcome any language barriers, to be very easy to engage with, and pleasant to use.

Digital wireframes - Centralised features template

The design of the main template (critical path: Accommodation Booking user flow) is derived from the Sitemap design, where Accessibility (Languages and Assistive Technologies), Safety, favourites and basic navigation operations (home, return buttons, etc.)] are all integrated into the same frame template.

I gave emphasis to a very simple and practical design template, where the application content can change in accordance with the user flow requirements. Additionally, I made sure the zone of graphics and text are included within the "above the fold" area, to be visible to the user at all times. 

The safety feature is going to be added as a widget (to the user's screen) to enable quick access and activation without opening the application. It is going to be an independent function, and irrelevant to any user's bookings, in order to promote safety and to provide alerts in an emergency. 

Digital wireframes: Accommodation Booking user flow

This user flow is the starting point (Homepage) of the application, where the user's location is identified and followed by the steps shown below:

1. Homepage - Identifying users location

2. Selecting & apply accommodation filters

✦ Selecting accommodation filters 

3*. Accommodation results

✦ Selecting accommodation results (3 options) 

✦ Sending accommodation availability enquiry 

4*. Receiving accommodation availability enquiry results

✦ Selecting preferred accommodation (single option) 

5. Add personal preferences (to selected accommodation)

✦ Type preferences 

6. Insert payment details (if required)

7. Payment summary

8. Booking reference (including reservation number)

✦ Added as a widget for quick access without opening the full application, and 

9. Travelling directions

✦ Additional features of safety & travelling directions, included as widgets for quick access without opening the full application.

*Steps 3 & 4 can possibly combined at some stage in the future, however my approach was that high-level accommodation search doesn't need to be detailed (to reduce internet data and battery consumption). Once the user selects the shown options (reachable accommodation), then more details can be revealed and a detailed internet search. However, as I don't have any development and engineering experience, this is something that I would like to explore at a later stage after liaising with the front end and back-end engineers.

Low-fidelity prototype - static*

At this design stage, the components library is very basic, hence the design was developed a bit more as duplicated frames to show the basic UI and graphic interactions to the actual frames. They will be are incorporated (at a later stage) as components to the high-fidelity prototype, but I wanted to start thinking the UI strategy in advance. 

Below is the static screenshot of the low-fidelity prototype (including the duplicated frames of UI elements), where a few centralised connections are not visible, for example:

★ The hamburger menu button included at the top bar, has a centralised connection to the hamburger menu frame (top-left). It was set up at the beginning and copied to all frames. Therefore, there is no need to add individual connection to each frame separately, as it was arranged in a centralised function.

*static = graphical representation

Usability study findings (R1)

For this project, 2 rounds of usability studies have been conducted to ensure improvements in the UX and UI elements. The first round was conducted on the low-fidelity prototype and I received the following very constructive feedback:

Round 1 (R1) findings:

USR1 - 1. SOS button to be emphasised. It can replace the profile button, as sign-in is not required while booking accommodation and the SOS feature is life-saving. 

USR1 - 2. Facilities provided within the accommodation are not included in other applications and websites, and homeless community would like to know if sanitary facilities, kitchens and any other facilities & services are included within the shelters.

USR1 - 3. Temporary/ pop up premises are not included in other applications and websites, and during extreme weather conditions is very important to be included.

USR1 - 4. Cost or any required payments and payment methods, to be included in advance (during accommodation search/ results). Users would like to know in advance the payments that have to do for every accommodation option. 

Designer's observations (R1)

Apart from the usability study findings, at this stage I spent some time challenging myself, and bringing forward all the learning outcomes from my last 2 projects (Econ Bank & Future Art). I did the following list of improvements, to be incorporated in the next iterations:

Round 1 (R1) observations:

DOR1 - 1. Timed start frame to be added (landing page). A branded timed frame can be added to promote the charity's purpose, and then the users to be directed to the Accommodation Booking user flow.

DOR1 - 2. Timer frame to be included in-between search results and external actions (IoT, payments, etc.), while the user is waiting for the results will give them more re-assurance.

DOR1 - 3. Lower bar - create different button shapes/ clusters for Accessibility buttons (Languages and AT) and include favourites button (in the accessibility cluster).

DOR1 - 4. Lower bar - Retain home & return/ back buttons location and shapes. To be easily distinguished from the Accessibility buttons, and their shape to identify with the navigational functions of the application.

Improving the design

Digital wireframes (R1) - Centralised features template

Usability study findings (USR1) & Designer's observations (DOR1)

The following revisions took place to the centralised features template frame:

★ USR1 - 1: SOS button to be emphasised.

★ DOR1 - 3: Lower bar - create different button shapes/ clusters. 

★ DOR1 - 4: Lower bar - Retain home & return/ back buttons location and shapes.

Digital wireframes (R1): Revised and new frames only

Following the revision of the centralised features frame template, a few more frames have been revised to incorporate the following revisions:

★ USR1 - 2: Facilities provided within the accommodation.

★ USR1 - 3: Temporary/ pop up premises.

★ USR1 - 4: Cost or any required payments and payment methods. 

★ DOR1 - 1: Start frame to be added (landing page).

★ DOR1 - 2: Timer frame to be included in-between search results and external actions (IoT, payments, etc.).

Below are shown the revised and new frames, but not the full Booking Accommodation user flow frames. 

Digital wireframes (R1): Accommodation Booking user flow

Combining all the above iterations, the Accommodation Booking user flow, has been amended accordingly:

0. DOR1 - 1: Timed start frame to be added (landing page).

1. Homepage - Identifying users location

2. Selecting & apply accommodation filters

✦ Selecting accommodation filters 

2A. USR1 - 2: Facilities provided within the accommodation.

2B. USR1 - 3: Temporary/ pop up premises.

3. Accommodation results

✦ Selecting accommodation results (3 options) 

✦ Sending accommodation availability enquiry 

3A. USR1 - 4: Cost or any required payments and payment methods.

3B. DOR1 - 2:Timer frame

4. Receiving accommodation availability enquiry results

✦ Selecting preferer accommodation (single option) 

4B. DOR1 - 2:Timer frame

5. Add preferences (to selected accommodation)

✦ Type personal preferences 

6. Insert payment details (if required)

7. Payment summary

7A. DOR1 - 2:Timer frame

8. Booking reference (including reservation number)

✦ Added as a widget for quick access without opening the full application, and 

9. Travelling directions

✦ Additional features of safety & travelling directions, included as widgets for quick access without opening the full application.

Medium-fidelity prototype (R1) - static*

Similarly to the low-fidelity prototype phase:

★ The components library is developed a bit more but still very basic, hence most frames are duplicated to show the UI elements as graphic/ static interactions to the primary frames. While developing the UX part of the application, in parallel I was thinking some UI ideas and I wanted to record and monitor them, against the overall design development.

★ A few centralised connections/ interactions are not visible to the static screenshot below.

For example, alongside the hamburger button ... the SOS feature (top bar) has a centralised connection with the SOS frame (top-left), therefore no need to add all individual connections for every single frame.

*static = graphical representation

Usability study findings (R2)

Evolving the design to the next and final stage of mockups and high-fidelity prototype, I conducted the second round of usability studies, by testing and improving the medium-fidelity prototype. I received the following constructive comments, and I fully implemented them within the design. 

Round 2 (R2) findings:

USR2 - 1. Multiple accessibility features/ sections to be incorporated, so the users have more flexibility in choosing the right ones for them. 

★ Multiple selection of Languages (two languages) and Assistive Technologies (AT)

USR2 - 2. Add a by proxy feature, so if a homeless person/ group of people, don’t have a phone/ internet connection or enough battery life, another member of the general public can book a place on their behalf. 

USR2 - 3. More filters to be included regarding personal belongings and requirements, especially for extra bedding and sleeping items, medical requirements, etc.

USR2 - 4. Payment confirmation screen to be added after payment summary. Possibly to be integrated in the same page as the booking reference number? It will further help the users to fully understand what they have paid. 

Designer's observations (R2)

Apart from receiving the above feedback, I had the opportunity (list below) to do some of my own observations and further calibrate the design. 

Round 2 (R2) observations:

DOR2 - 1. Favourite button to be away from accessibility buttons. User to be able to focus on the accessibility cluster in an independent way. Favourite button to be clustered with the other navigation buttons. 

DOR2 - 2. Personal and proxy booking screen to contain the following options:

★ For the individual

★ For a group of people

★ Improvement: To identify numbers of people (per booking) in advance. This element will help further down for the search of available spaces, too. Only suitable options will be presented, in accordance with the number of people booking through the application.

DOR2 - 3. Multiple selection of Languages and Assistive Technologies to be visible in the low bar, and user to have the opportunity to switch easily between the two selected Languages or between a combination of Assistive Technologies features.

DOR2 - 4. More flows to be included (fully operational application), as per the initial Designer's Personal Challenge (DPC) (see above and below).

Refining the design

Moving forwards ... from the digital wireframes and the medium-fidelity prototype, towards the mockups and the hi-fidelity prototype ... the "Designer's personal challenge" parameters have been incorporated, for the full operation of the application, including the main user flow (Accommodation Booking), and a number of subordinate user flows.

Designer's personal challenge (DPC)

Bringing forwards the Designer's personal challenge, the following items were considered and embedded:

★ DPC - 1. Development of a fully operational application - all flows and frames.

★ DPC - 2. As consequence from item 1 and a more complex application (multiple user flows), to integrate some visual accessibility enhancements.

DPC - 1. Development of a fully operational application - revised Sitemap: 

The following user flows are going to be brought in together:

★ DPC - 1a. Existing Accommodation Booking user flow (critical path) that has been developed so far, including the following features:

✦ Accessibility

✦ Safety 

✦ Favourites

and

★ DPC - 1b. Additional subordinate flows (Hamburger menu):

✦ Safety nominees

✦ Safety forecast

✦ Weather forecast

✦ Profile

✶ Register/ Log in

✶ Personal details

✶ Account details

✶ Payment details

✶ Full past booking list

✶ Full past favourites list

✶ Full past donations list

✦ Donations

✦ About Menu

✶ About

✶ T&Cs

✶ Privacy

✶ Careers

✶ Feedback

✦ Contact

✶ Contact details 

✶ Contact form

In consequence, below is the revised and final Sitemap diagram combining: 

★ The Designer's personal challenge (DPC) outcomes (all new flows)

and the following outcomes:

★ The first round usability study findings (USR1).

★ The first round designer's observations (DOR1).

★ The second round usability study findings (USR2).

★ The second round designer's observations (DOR2).

DPC - 2. Visual accessibility enhancements: 

This challenge is about enhancing the visual accessibility features of the application, in addition to the operational Accessibility features (Languages and Assistive Technologies). As the application expanded, clear and compliant visual graphics have to be embedded to improve legibility for the users. 

The following items are incorporated:

★ DPC - 2a. Visual contrast to comply with WCAG requirements. 

✦ See colours below.

★ DPC - 2b. Tactility - size of button to be in accordance with WCAG (44px)  - smallest round buttons designed as 45px.

✦ see buttons below.

★ DPC - 2c. White space to enable the user to read easily through elements (Gestahlt principles).

★ DPC - 2d. Large text font, distinguishable headings and normal text variations, to enable clear visual hierarchy. 

★ DPC - 2e. Light and dark modes to be considered (but not embedded for the high-fidelity prototype).

★ DPC - 2f. Logo and branding to be carried through the full application. 3D visual components to be integrated to enhance the perception of space/ room, and to create an emotional reaction to the home-making experience. 

UI design elements: Sticker sheet (Design system)

At this stage, as the UX design was expanded, the UI design elements have been developed, in parallel. A number of components were incorporated to reduce the number of frames and enhance the user's interface experience. 

Mockups - Centralised features & Accessibility templates

The centralised features templates, after combining all the aforementioned elements (UX and UI design development), have been revised to bring forwards all the user flows and the designed visual agenda. Additionally, the Accessibility templates are fully developed as shown below, where:

★ Multiple Language and Assistive Technology options can be selected.

★ Two active languages can be chosen at any time.

High-fidelity prototype - static*

The high-fidelity prototype design has been evolved after adding the connections and interactions to the mockups, and by incorporating the following parameters:

★ First round usability study findings (USR1).

★ First round designer's observations (DOR1).

★ Second round usability study findings (USR2).

★ Second round designer's observations (DOR2).

★ Designer's Personal Challenge (DPC).

★ Latest Sitemap diagram, where all sub-flows are incorporated.

★ UI design elements - sticker sheet (design system).

All the above elements have been graphically naturalised, in the application's colour theme of cobalt blue tones. 

Below is a static representation of the revised and final Accommodation Booking user flow, and all the other sub-flows derived from the objective of the Designer's personal challenge. There are more than 50 frames in total, to demonstrate the complexity of the product, during full operation by its users. 

The components library has been developed to its full extent (see sticker sheet above), hence the frames are not duplicated to show the UI & interactive elements; In contrast with the low and medium-fidelity static prototypes.

Last but not least, I tried to make the Accommodation Booking user flow as responsive to further enhance that technical skill and check how the design works in various larger screens from the original Android Small frame (360 x 640px). Most frames worked well, but I concluded to some very interesting design considerations and learning outcomes in the paragraphs below. 

*static = graphical representation

Responsive design considerations

Accommodation Booking user flow 

I have applied the responsive design to the Accommodation Booking user flow only. However, in the future I would like to have the opportunity to make whole application or a website responsive. It has been a challenging procedure, especially when the scaling of elements is not done proportionally, and I am still learning how to use the auto layout tool.

I have noticed when I tried to change the original frame size (Android Small 360 x 640px) to the largest possible frame (iPhone 15 Pro Max 430 x 932px) in the high-fidelity prototype, the frame wasn't picking up directly the responsive elements and it was showing the original frame (Android Small 360 x 640px) to the large mobile phone handset. For that reason, I decided to duplicate the user flow by changing the size of all mockup frames to the largest possible handset to run them as a high-fidelity prototype and improve any mistakes. 

I am not sure if this is the right way to run the prototype, but this was the only solution I could think of, and somehow worked. However, bare in mind that some links might take you to the initial frame size (centralised features such as: Accessibility, SOS, Hamburger menu and some navigation button), as not all screens were designed responsively. 

Some basic principles that I followed:

★ For the top and bottom bar I have managed to stretch the bar to "left and right" without changing the proportions. And I made sure that the left and right buttons have the right vertical and horizontal alignment. 

★ I had to revisit the components variants, as some constraints had to change for the default variant and had to be reflected to the rest of the variant versions.

★ In a few instances, I have used the auto layout feature and it was very handy for some expanded and enlarged dimensions. However, if for example two buttons were grouped as auto layout, and were not the same size, then by using the "Fill container" option, the buttons were becoming the same size and clashed with the text (smaller than the text frame). Visually, it would have been better to enlarge the buttons proportionally to the responsive frame size, but I am not sure if Figma has this kind of feature.

Going forward

Takeaways

Impact:

This is an attempt to bring more ease at extremely difficult moments, for homeless people in need. Hopefully, a very democratic and inclusive application, to help the homeless community, and bring comfort and safety. Homelessness is something to be tackled a lot more effectively through this application, as the user is going to have better insight and can be more proactive in planning their overnight stay.

The strategic goal is to reduce the number of rough sleepers, and any associated crime within local communities. At the same time, to create a reliable platform, where the user can find accommodation anytime. As a result to feel increased levels of safety, security and assertiveness, by booking in advance.

Possibly the application can be deployed in other extreme situations, such a countries with war and/or famine, where people have lost their homes and belongings, and are desperate for safe accommodation. 

Learning Outcomes:

This project has been a very satisfying learning and exploring opportunity. I had a very steep learning curve in empathising with users, and integrating their needs in a very succinct and straightforward manner. In parallel, I have learnt and experimented with various tools in Figma and tried to incorporate more aspects of built-in and integrated Accessibility features. 

I believe that I challenged myself in the following aspects, and user flow frames:

★ I created all frames to meet the requirements of a fully functional application. In consequence, I designed all possible user flows to cover all user needs, while using the application:

✦ Searching, booking and paying for accommodation

✦ Favourites

✦ Profile features

✦ Communication

✦ Careers

✦ Feedback

However, all these user flows are my own assumptions (Designer's personal challenge), and possibly when the full product is tested, additional needs will be revealed, and have to be considered for future revisions.

★ I created multiple components and combined components for more complex triggers, interactions and animations, by providing pleasant and engaging UI interactions.  

★ I have incorporated a few 3D visually designed elements, and I downloaded a number of plug-ins until finding the right tool to convert the text in 3D. 

★ I did some animations by combining variations of components and trigger styles.

★ Some design aspects required design with conditions (I have been advised), but I only have the free Figma version and couldn’t practice more. In the near future I would like to learn more about conditions. 

★ I was thinking to design the full application in dark mode as well, but I have seen a video tutorial on YouTube by setting up colour variables. Again this is a feature that the free Figma version doesn't have, and I would like to invest more time in learning and experimenting with this tool. 

★ I created centralised connections for the function of the prototypes (low, medium and high). So, instead of connecting every button to the relevant frame, I connected the initial component to the relevant frame, and then the connection was carried/ multiplied over. This saved a lot of time while doing the prototyping, and it is a technique to implement on my professional projects.

★When designing, I have used the "small to large" approach, but unfortunately the phone frame I chose it wasn't the smallest one. Hopefully, next time I will have the opportunity to design using the smallest frame first, and then scale up to all larger smart phone frames, for the full responsive experience. 

★ Responsive Design: this is something I am still exploring and trying to understand. I have used the constraints and auto-layout Figma tools, but I need to understand better the various parameters and design a more responsive application, especially when using components. How various scale related components react in different frames? 

★ Security GDPR and saved favourite options, outside someone's profile (signed-off): 

✦ This is something that I am not aware if it's possible to be done, and if the application and/ or the user's phone device have the capacity to save locally some information. If yes, then is this compliant with GDPR and the current security technologies? I assume working in a professional context with engineers and developers, this parameter can be further discussed and explored. 

★ I embedded all accessibility features I could think of, since the beginning of the design, but I am certain there are more to be added and their back-end requirements. For example, if a user selects the "Bigger Text" option, how does the application text changes? I assume this is something that has to be considered by the UX/ UI designer. So, again another realm where I need to get more experience.

What I could have done better:

★ I haven't incorporated an identification (ID) method yet, as this is something I am not very aware how to incorporate. I assume as a basic "ID checks" step, a user can enter manually their Passport or Identity Card details. However, most users might not have those document with them, so another method has to be used or invented. However, this is a feature to be incorporated in the following revisions after doing more research. 

★  I could have added a timer feature frame at the donations payment flow; While the user is waiting for their payment to be progressed. 

★ I could have added the user flow for adding names in the group booking option. Not a long user flow, but very important for booking accommodation as a group. 

★ I would like to understand better the technical side of the application, especially if data can be saved locally so users don't need to sign in, and  to retrieve their latest 3 booking and favourite accommodation options. 

★ I haven't used the smallest screen when I was designing the application, and when tried to shrink the design some elements were colliding. Next time I would use the smallest possible screen for building a responsive application and all responsive elements to be magnified rather than shrink.

★ I could add another frame in Accessibility, so the users can save their preferences centralised and permanently, rather than setting them up every single time. Similarly full sign in is required for this function.

★ I could add another frame in the profile menu to incorporate centralised payment details, so the user doesn't have to enter them every single time. This feature will require a full profile sign in.

★ More research needs to be done for visual contrast in dark mode. Is there a requirement to comply with WCAG or not? I have done very little exploration, but it was very difficult to provide all the required contrast. 

★ A responsive website can be designed in the near future, as some people within the homeless community might not have smart phones. Those people can use either local libraries, internet coffee shops and other public buildings to book their slot. Again technical parameters such as security, identification and GDPR have to be considered for the website design, as well. 

★ I am not very familiar with the Internet of Things (IoT) technology, and if there are any requirements or protocols, they have to be incorporated. However, I could have done more research in advance, and to integrate this element into the design, too. 

★ Responsive design: 

★ Spend more time learning about various types of mobile phone handsets:

✦ Unfortunately, the location of the top bar logo, coincided with the camera for some large frames . And some phones have a wide camera opening almost blocking the logo completely (i.e. iPhone 15 Pro Max). Hence, in the future a wider top bar strip has to be considered and the logo location to be chosen very carefully, and to be coordinated with the hardware characteristics.

✦ Some handsets have generous radius bullnose edges and some call-to-action buttons are not very visible (or half visible) and harder for the user to touch. Their size becomes less than the 44px diameter, and not as per the WCAG requirements, which is limitating the users of accessibility requirements.

★ Doing the responsive design, in many instances the Figma constraints didn't provide a proportional (aspect ratio) scaling of the graphics. I have installed a plugin "Scaler" that helped me locking the proportions. Thus, when changing the frame sizes the graphics/ constraints etc., have not been distorted. However, when I closed the plugin down, the settings were removed from the file and the graphics were scaling not proportionally, again. I am not sure if this is a good or the right way to do UX/ UI, and certainly I would like to know the developers'/ engineers' opinion. In the end, I decided to remove the plugin and to locate elements by using the constraints, despite being slightly problematic in a few instances.

★ Figma provides some responsive functions, but without any centralised proportional scaling capacity. I assume this is something to be considered in my future projects and learn how to overcome the obstacle.

★ The Accommodation user flow consists of some frames longer than the typical frame and a scrolling function is required while running the prototypes. I am not sure how exactly this feature works in responsive design. Although I was able to proportion all items to the desirable responsive design, when changing the size of the frame (the long/ vertical dimension) it wasn't reflected in the amended frame and I had to manually extend the frame. I created a second version of the accommodation flow by having a larger frame to see how exactly all elements are working. 

★ For some "fixed" scrolling elements in the prototype mode, some of the constraints features were not working. I had to temporary change the scrolling type, then chose the required constraints setting and set it back to fixed prototype mode. I assume that some of the constraints are disabled due to the chosen scrolling or fixed option but this is something to be considered in the design of the frames.

★ In a couple of screens, when one element is selected then it has to be visible to another part of the same frame (almost as an interconnected element. For example for the results frame, when the user selects the preferred accommodation, then it is shown bolden on the map (top part of the frame), as well. I have done both interactions as two separate manual selection tasks but in reality it should be done automatically. When the user selects the accommodation to be shown on the map directly. I spoke to some YouTubers and they mentioned that this can be achieved by using conditions. However, this is something not offered in the free Figma version, and a feature to explore in the near future, certainly. 

★ When making the graphics responsive, the connected components variants had to be done too. In some instances I haven't considered the implications, and this is something to be tested at early stages rather than after the component is built.

★ When testing the prototype the constraints were working as designed for the original frame size, however, I couldn't run the prototype for another frame size, although the mockups were fully responsive when changing the frame sizes. I copied the frames and changed their size to run  larger frame size. However, it seems to work adequately, but is this the right way to test responsive designs? It doesn't seem to be very efficient. This is something to else to learn in the near future. 

★ Doing the responsive design was a good learning curve but a bit disappointing that the text is not responsive. This is something to be considered, also some white space and gaps where enlarged and the visual integrity of groups has been lost. Again something to be explored in detail in the future. 

Edit: recently I found a YouTube video of creating responsive text by using variables. I will definitely watch, and consider to implement this method in my future projects.  

Next steps

1. Conduct another round (R3) of usability study, and recruiting two different user types, at least:

★ Homeless people that have and use their mobile phone &

★ People of the general public that a homeless person has asked them to search for facilities and book a spot on their behalf (by proxy).

The outcome of the third round usability study is going to be very interesting and the received feedback can be incorporated, as well. 

2. Simplifying some parts of the graphics to make the download and use feasible with very little internet data.

I have mostly used Figma and SVG graphics (icons), rather than large images. However if more graphics can be reduced and simplified for the benefit of the fast application function, then this route has to be further explored. 

3. Integrate an offline translator of basic communication sentences for homeless people that don’t speak English.

This feature is to enable communication for people that have booked accommodation and need to communicate while in the premises. 

4. Log in and security options

Back-end engineering and legal consultancy input is required for these features, especially if the 3 favourite spots and latest bookings can be saved locally, so the user doesn't have to sign in to their profile.

5. Create portal to add temporary and pop-up facilities.

This is for premises and estate managers/ owners that can add quickly the relevant premises when available. For example, organisations like Transport for London might keep open some stations during cold winter nights so the homeless community can find shelter over there. 

6. War and famine inflicted areas

Possibly some more features and tweaks can be integrated, so the application meets the needs of that type of users, too. 

Visual Conclusion - Sitemap with frames

For this project, I decided to depart from a written conclusion, but I wanted to integrate a visual conclusion. Hence, below is the Sitemap diagram showing the frames, and how they are interconnected together for the full and holistic operation of the application.  

Thank you for your time! ✿◠‿◠

★★★★★

More Projects