The Ultimate Agos e-Bayanihan Case Study + Design Sprint

I had the most-awaited opportunity to design a platform inline with my passion & advocacy. Here’s what I did.

Believe it or not, this project is the biggest reason why I joined Symph. If you read my first article, you would know what Agos is. I was first introduced to this platform during college and I had no idea who built it. I just knew it was awesome because it enabled the community to share valuable information during a calamity. Little did I know that after two years or so, I will be joining the company who developed it. And eventually, redesign it myself. Pinch me, please.

Back when I was still a neophyte, I didn’t know what an effective design is. Like any newbie designer, I thought design is all about the aesthetic value. It took me a year to realize that design is more than just that. Along with that realization, it occurred to me how big the potential of Agos is if only it was designed in a human-centric way — personal, intuitive, simple and obvious.

We need to maximize crowd-sourcing of information and organize them in a way that’s valuable to the users

Why do we have to?

The reasons why the team thought that a redesign + Design Sprint is necessary:

  1. To find out the real problem
  2. To maximise the data we currently have and present them in a valuable and evident way
  3. To find out loopholes and parts we can improve on

and hopefully, this will..

  1. Improve and hasten the process of filtering, verifying, and responding to reports
  2. Create a way to track progress of rescues
  3. Attract more users and eventually convert them to volunteers so we can act better during crisis and calamities
  4. Improve and give support to the current workflow of the volunteers, the government agencies, and the local government units (LGU) during crisis
We believe in the platform’s potential to catalyse change on how the community functions during crisis.

The Ideal Process (image)

  1. Research
  2. Plan
  3. Design
  4. Test
  5. Build
Reality vs Expectation

What Actually Happened (image)

  1. Collaborate
  2. Research
  3. Plan & Brainstorm
  4. Design
  5. Big Presentation
  6. Turning Point
  7. Shift & Iterate
  8. Test
  9. Build


Knowing the key people involved in the project is essential to the success of the product. These are the experts who lead teams and knows the product and people involved best.

In this phase, we did not only discover their internal workflow and project timeline, but also built good relationships with them. This is one of the important things designers miss — reason why some find it hard to empathise and understand why clients act the way they do and why they make certain decisions that may not make sense to us (but certainly, they do in a way or two).

To better understand the problem, I flew to Rappler’s office and experienced their company culture, interviewing leads along the way.

Project Introduction

I spent the 1st and 2nd day working closely with the product owner. We talked about the background of Agos, where it all started, and what sparked the idea. We have to make sure that I clearly understood the purpose, current processes, internal workflows, and timelines of the project so I can effectively communicate that through product design.

The heart of redesigning a big platform is understanding it clearly from the viewpoint of the product owner

This is the generally what happens during crisis in the Philippines:

Unnecessary panic due to incorrect information

or this

Underestimation of crisis due to lack of information
And we want to fix that

I was introduced to people involved and got the chance to interview them one by one. One important thing I discovered is how the reports were received through Google forms — a tedious process and a bottleneck in the rescue process.

This helped us decide whether a Sprint is necessary or not.


Finally, we decided that a Sprint is necessary to take advantage of my short stay in their office. Because of the stakeholders’ hectic schedule, I strategically compressed the 5-day Sprint into a 2-hour Sprint, consisting only the essential activities that will help me sketch promising solutions.

A night before running the sprint
We gathered 6 members involved in the project: the Product Owner and Chief Technology Officer who acted as Deciders, Data Researcher, 3 Head of Volunteers during crisis, and 2 Lead Developers. Together, they formed the Sprint team.

We also managed to kidnap 2 roam-ies and invited them to talk during Ask the Experts. Because it was an impromptu, we were able to get honest and solid insights from them. It was incredibly enlightening to the team.

Note and Vote

The team have strong yet slightly opposing ideas and the Sprint brought out the most promising of all without having to undergo long debates and charismatic vote-buying (thanks to Note and Vote). To me, the Sprint was the perfect framework to use in order to decide which ideas are worth mixing and pursuing. By the end of the Sprint, we gathered 2–3 of them.

Important notes from the Sprint:

  • Localisation and presentation of data is our priority
  • Find a way to validate and respond to rescue reports
  • People have little to no access to the internet in the real scenario of a calamity
  • Teachers make use of codes to report and give updates via text
  • We aim to make everything modular development-wise


User Survey

We summarised the results of the Sprint on the 4th day.

Because we aim to make everything modular for scalability and maintainability, we needed to find out which groups of information can be combined and fall under each crisis mode.

This helped us declutter, organise, and prioritise information, back my initial design with real data, and justify the use of modular and reusable components.

Here’s what we found out after running the survey in 3 days:

We identified and assigned 4–5 grouped information for each modes

Prepare happens before the crisis (e.g. flood, storm). This is when the team receive the news that there’s an incoming storm. We later on combined here Peace (no crisis, everybody’s okay).

  1. News & articles
  2. Weather or Crisis (typhoon, earthquake, etc) updates
  3. Workshops and events
  4. Prone to hazard areas

Respond happens during the crisis. The most critical time when the storm have already hit part of the Philippines and people are panicking, blasting their social media with updates. We receive multiple informational reports and requests for rescue. This is also the time that volunteers and LGUs are most active responding and bringing aid to affected areas.

  1. Weather or Crisis (typhoon, earthquake, etc) updates
  2. Helpful Hotlines
  3. Shelters
  4. Safety Check
  5. Helpful news and articles

Recover happens after the crisis. This is the time where we summarise the number of casualties and manage donations.

  1. Where to Donate
  2. Safety Check
  3. Helpful news and articles
  4. Weather or Crisis (typhoon, earthquake, etc) updates

Plan & Brainstorm

Initial Sketches

Having sufficient knowledge, I started drafting initial sketches, created medium fidelity mockups, and presented them to the CEO, Product Owner, and CTO.

Long story short, we got a positive feedback. We polished concepts and prepared for the Stakeholder’s Meeting where we’ll be presenting our UX study and final solution.

That night, I decided to get in touch with the former designer to get insights of what had gone wrong and areas we can improve on.

Conversation between me and the former designer. We had few learnings too ❤ Will summarise and replace this with condensed version
Surprise, the solution is more user research. Every design decision must make sense and add value to the product. It must answer to every why, why, and why.
The designer creating the mockups


Initial Design Breakdown

User flows, mood board, user survey results, use cases, recorded audio of interviews and meetings, and mockups.

User + Page flows


Stakeholder’s Meeting

Big day is here. I stayed up late polishing the high fidelity wireframes. I barely got enough sleep but I was so excited! The result was more than what I expected. I mean, just look how happy we are with the outcome.

Key Learnings

  1. Get the right people inside a room. Listen and collaborate. Get ideas that are floating around and mix them.
  2. Research and interviews will save you time.
  3. Most of the time, presenting high-fidelity mockups are necessary to put your point across clearly. This provides a better understanding to non-tech people.
  4. Being able to explain your design decisions and sell your idea is important. Storytelling is a hard skill a designer must learn.
  5. Balancing excitement and nervousness is a challenge. Sleep well.
When you start to lose patience, pretend it’s your first day again.

Lastly, Enjoy and learn (again and again if you have to).

— Big Turning Point

No one talks about the Turning Point. Am I missing something? I’ve read case studies and I haven’t come across a similar story to ours.

As it turned out, we can’t pursue the designs I’ve presented. Not because it sucked, but because the team underestimated the timeline and manpower. There are limited features currently existing in the platform. Meaning, we can’t yet pursue some components such as safety check and nearby shelters and volunteers. Delivering an MVP of the website in Phase 1 weighs less important compared to building the Volunteer Platform.

Which I agree to — even during the Sprint — it was clear that our target user is the volunteer. Therefore, prioritising the Volunteer Platform over the website is rational. Plus, it would fit the timeline perfectly given our available resources.

Turning Point is the Aha! and the Uh-huh.. moment of the project. It slaps the team with late realisations, it provides them with options, and it helps them take necessary actions — to ensure success.

What’s good though is that we were able to focus on the target user and moment (based on the Sprint) and manoeuvred asap to creating what’s really important during a crisis — the Volunteer Platform. Making use of features that are readily available was a challenge. The team shifted from ideal to resourcefulness.

The Final Solution

Want to know how the project’s shift in focus affected the outcome? Here’s a case study we did.

Key Learnings

  1. We overlooked and failed to see that the real problem lies on the target user and moment, but we learned.
  2. Don’t hesitate to shift during the discovery phase. This is the most flexible part of the project and least expensive.
  3. The reason why we have a UX study in the first place is to find loopholes and opportunities. Don’t be afraid to commit mistakes along the way. In fact, this is the best time to commit mistakes as much as you can — and iterate.
  4. Just keep going and you’ll get there!
I hope you enjoyed this lengthy piece! Your round of applause is highly appreciated! 👏

Hey, don’t you know we can also run Design Sprints with your team? Let Symph help you!