Building Faults Reporting System For Makkah Municipality

Decrease building's faults reporting to 5 minute

Holly Makkah Paper Prototype

Holy Makkah Municipality - Facilities Maintenance Department



My Role

Entire product design from research to conception, creating user interfaces, testing and converting to High fidelity prototype.


April 2016 - May 2018

The Client

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:

  • Deals with contractors to repair any fault show up.
  • Approve and accept the fault repair and make sure it is functioning as it should be.
  • Monitoring Makkah municipality buildings and the equipment inside them.
  • Accept and pay the repair bills from the contractor.
  • Evaluate and rate each contractor depending on the work results, so municipality can extend his eligibility to work with the municipality.

Understanding The Challenge

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:

  • Deficiency reporting takes a long time.
  • Reporting consumes the efforts.
  • They use paper to fill the deficiency information then send the photos using what's App to the contractor this causing a huge delay in the starting of the fix.
  • Difficult communication between the contractor and the workers' chief.
  • Buildings' managers are hardly monitoring the fixing process and they get involved at the late stage in the fixing process which giving them small space to help or modify.
  • Buildings' managers find it challenging to pick any contractor for the next year due to a lack of reporting.
  • Contractors receive late deficiency notifications (close to deadline time) which causes them to lose valuable time leading to a high chance to get a penalty.
  • Contractors receive deficiency notifications missing some mandatory information such as location, type of the deficiency, and type of the broken machine.
  • Holes in estimating penalties against the contractor due to a lack of documentation.

The Process

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.

Number of students participants and their categories Princess Nourah Application
The Process We Used


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.

Persona for Makkah Project

Buildings Manager: (Sample Questions)

  • How might we keep the buildings manager updated with the status of his buildings?
  • How might we reduce the steps needed for the buildings' manager side and making sure no negative effect on the process?
  • How might we help managers to make sure that fixing results as standards?
  • How might we help managers in choosing which contractor to keep working with each year?

Fault Submitter: (Sample Questions)

  • How might we increase the speed of fault and fixed fault submitting?
  • How might we make the fault explanation clearer and easy to understand while submitting?

Contractor: (Sample Questions)

  • How might we help to reduce the number of re-open fixing orders?
  • How might we help contractors in defining orders to worker's chiefs?
  • How might we help contractors in reducing the number of fines they receive?
  • How might we help contractors in automation most of his responcibalities?

Workers Chiefs: (Sample Questions)

  • How might we simplify the initiation of the work?
  • How might we help workers chief in finding the exact location of the problem?

"Buildings manager should ensure that all building facilities and its equipment are operating at the best level to serve the public"

-- Ammar Qurashi (Buidlings Manager)

Story Board

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.

Holy Makkah Municipality Fault Submission Story Board
Fault submission story board

User Journey Maps

We mapped out our findings and ideas into users' journey maps to identify opportunities to simplify users' tasks.

Detailed Persona Journey Maps

Kick-Off Meeting

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:

  • Reduce the time of submitting a fault from 1 day to few minutes.
  • Simplify finding the fault location by adding GIS (geographic information system) to the application.
  • Reduce the number of steps needed to approve the fix.
  • Adding an automatic schedule for worker's chief and fault submitter to make sure no fault missed.
  • Simplify the fix accepting and allow the Buildings Manager to monitor and interfere when needed.
  • Ease the tasks for both Fault Submitter and Buildings Manager, even if that means to make increase the complexity for the contractor and his team.
  • Add the last activity time for all users except the buildings manager.

Design Principles

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.

  • Memory in interface design: People do not remember all the information displayed according to George Miller, short-time memory can only hold about 7 (+-2) chunks of information (Miller’s Law). Also, short-time memory can hold information is between 15 and 30 seconds. After that, the information is either committed to LTM or forgotten. For this, we simplified the submitting a fault steps to very few steps.
  • Follow the user's mental model: Most of the users are exploring the interface just based on their intuition. For example, when users face a button, they will think this button will be triggered to meet their needs. But if this button gets triggered in some other operation rather than the user's expectation, it must be a faulty design. We got inspired by some features used in their daily use apps such as voice notes and images uploads.
  • Speaks Users Language: As engineers, they have their terms to identify some issues such as Actuarial analysis which means Statistical analysis of failure data to determine the age-reliability characteristics of an item. We added this language to our application.
  • Less is More: Originally proposed by architect Ludwig Mies van der Rohe, it is a design philosophy that promotes simplicity and opposes over decoration. As it was clear to us that reducing fault reporting time is essential to all users we did our best to automate most of the required information such as utilizing GIS and QR code.
Nourah University Students App. - Professor Journey Map
Make it easier for the users to retrieve equipments informations and reports

Our Solution

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.

Mobile Application:

  • We used QR Codes readers in the Mobile Application to facilitate information inputs and to make sure that the user is in the right location; the Buildings manager complained that users file submissions without visiting the deficiency location.
  • Develop Mobile Applications for the contractor and fault submitter since their jobs require mobility. With the ability to access the web application for monitoring and reporting purposes.

Web Application:

  • Buildings manager & the contractors can access the web application to do his tasks.

Users Flow

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:

Holly Makkah Application Users Main Tasks Graph
Pirortized users tasks (Enlarge)

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:

The Holly Makkah Municipality Fault Reporting System Users Tasks Flow
Pirortized users tasks (Enlarge)

Paper Prototype

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.

* Videos will not be visible on mobile view here. To view videos please click on the URLs below:
* Fault Submission
* Approve A Repair



Learnings & Takeaways

  • People love to impress others especially when someone is watching them. I have to do my best to convince them that I am evaluating the process and not them, and the process should be simple to reduce their effort in a short time to complete their tasks.
  • Steady design is achievable when there's a system set up from the beginning.
  • Understanding the user context will help in crafting a better solution.

Future Steps

  • Allowing the municipality employees to have access to the mobile application to submit any deficiency, for faster fault reporting. we did not include this step at the current because project stakeholders decline it due to it is out of our project scope and can affect the current role of faults submitters.
  • We can add fault submitters' anonymous ratings by the municipality employees to have better evaluation.