Building Faults Reporting System For Makkah Municipality
Decrease building's faults reporting to 5 minute
Holy Makkah Municipality - Facilities Maintenance Department
Entire product design from research to conception, creating user interfaces, testing and converting to High fidelity prototype.
April 2016 - May 2018
Holy Makkah municipality is a government organization with an urban area of 850km2 and more than 13M squared meter area of services buildings.
They have more than 200 buildings widespread across the city, with an approximate total area of 1.8M squared meters.
Our project scope was determined by the municipality RFP that this is an internal system that will not be used by the public. We use the same structure as the current process and its personals. For an example how fault submitters know about an issue is not in our scope, we only pre-define a visit schedule. As a result of our work, we developed mobile app and responsive interface web application.
Holy Makkah Municipality facilities maintenance department (HMMFMD) is responsible for buildings equipment that is functioning efficiently.
Main responsibilities of MMFMP in our project scope are:
We decided to travel to Makkah to observe the current process HMMFMD is using for finding the deficiency to finish the repair.
After observing the whole process and interviewing all the involved personals, we highlighted many issues here are some of them:
It was clear that the current solution is lacking the necessary user insights that would help the users achieve their goals. Without these essential insights, the complete team would be guessing the best solution.
To get out of this deadlock, I have to capture and interpret customer needs. To illustrate our creating solution process, I divided it into four distinct phases – Who, What, Solve, and Delivery.
After observing users working on the current process, we understood their pain points, their motivations, and their needs.
To have a better understanding of our persona, and the relation between them in the system, we used empathy map, and defined a few HMW questions for each persona turning the problem into a question can help facilitate ideation.
Buildings Manager: (Sample Questions)
Fault Submitter: (Sample Questions)
Contractor: (Sample Questions)
Workers Chiefs: (Sample Questions)
"Buildings manager should ensure that all building facilities and its equipment are operating at the best level to serve the public"
After a few observing sessions of the current fault submission process, I decided to create a storyboard to identify core functional actions, pain points and to guide us where we should concentrate our energies while developing our solution.
We mapped out our findings and ideas into users' journey maps to identify opportunities to simplify users' tasks.
After we finished our research, we scheduled a meeting with the client to share and brainstorm our findings with them. We did some ice breaker activities then we discussed our findings and our recommendations.
After we completed our analysis, we scheduled a meeting with the client to share and brainstorm our findings and conclusion with them. We did some ice breaker exercises at the start then we discussed our findings and our recommendations.
This meeting has significantly influenced the development of important design decisions and key functionalities. Some examples are as follows:
Our team identified success criteria with comprehensive design principles. Building on these guidelines and with student and peer research in-hand, we fulfilled these UX design principles concentrating on customer-driven digital transformation.
We found out that the municipality has full equipment information saved in a Database, so it was easier for us to generate 6,321 QR Codes and attach the equipment information to it, to help users for automatic information filling deficiencies submission report.
To cite and prioritize all the main users' tasks from users' journeys, we held a workshop with the user's focus group. You can see the results in the graph below:
After a few iterations and discussions, we defined the user's tasks flow in the mobile application and the web application. Check the results below:
We decided to start using paper prototyping to explore more and to validate our design concept.
Unfortunately, when we show our testing participants our paper prototype they did not take it seriously. Accordingly, we used role play by other teams in our company. We initially did 4 paper prototypes and 17 changes.
One of the things we found that we should consider that QR Code reading is not possible for any reason required to add some alternative options was added to our task flow.
What are the ways I can solve the problem?
After few sketches to decide how the page information architecture should be, I flew to Makkah with a college to test our architecture. With the first 3 testing users were not able to interact well with low fadilety prototype so we tried to increase it to mid-fidilety prototype shown below - this is the latest version*. We tested it with 16 fault submitters and made 3 versions.