Digital bayanihan: build a skill that helps someone beyond you

Learning becomes easier to sustain when usefulness is close

Bayanihan is often associated with people helping one another move forward. In digital work, that spirit can appear in quieter forms: organising information, reducing repeated effort, explaining a tool patiently or making a process accessible.

This does not mean offering unpaid labour without boundaries or treating a community as a portfolio opportunity. It means learning with consent around a real problem, producing something modest, and allowing the person affected to decide whether it is useful.

The conclusion

• Ask about a nearby problem before designing a solution.
• Choose a small intervention with clear consent and data boundaries.
• Build a first version that can be tested quickly.
• Record feedback, limitations and changes as part of the evidence.

1. Find a nearby problem by listening

Start with a person or group you can approach respectfully. Ask what task repeatedly takes time, causes confusion or leads to avoidable mistakes. Listen for a specific moment rather than proposing your favourite tool. “We lose track of which enquiries received a reply” is more actionable than “We need digital transformation.”

Confirm who owns the problem and who can approve a test. Ask what information is involved, whether any personal data should remain out of the project, and what a useful improvement would look like. If consent or safety is uncertain, recreate the situation with fictional data instead.

For example, a volunteer group may need a clearer handover sheet. A small business may want a simple way to categorise customer questions. A colleague may need a repeatable checklist for a monthly task. None requires a grand platform.

Imagine the person using the first version without needing you beside them. The quiet moment when a task becomes less confusing is a better definition of usefulness than an impressive feature list.

2. Build the smallest responsible solution

Define the first version in one sentence: “This will help ___ do ___ with fewer ___.” Limit the build to the core path. Use tools that the user can access reliably and that you are authorised to use. A spreadsheet, form, template, guide or simple dashboard may be more appropriate than custom software.

Create a before-state and an after-state you can observe. The measure may be fewer missing fields, less time spent searching, clearer ownership or fewer repeated explanations. Do not invent numbers or claim impact before the tool has been used.

Document design choices. Why did you remove a field? Why is a mobile view important? Why should sensitive information not be collected? These notes turn service into evidence of judgement.

If a course assignment supplies a method, adapt it transparently. Say which part came from guided learning and which decisions arose from the local problem. A certificate may mark completion, but the responsible adaptation shows whether you understood the method.

3. Ask for feedback and improve together

Watch the person use the first version if they agree. Avoid explaining too quickly; points of hesitation reveal design problems. Ask what felt easier, what remained confusing and what should not change. Their preference has priority over your desire to add another feature.

Record feedback without turning a person’s situation into marketing. Remove identifying details from any portfolio case study unless you have clear permission. If the solution is not adopted, say so and explain what you learned. Honest non-adoption can reveal more about fit than a forced success story.

Make one focused revision, then check again. The case study can show the original problem, consent and constraints, first version, observed feedback, change, result and remaining limit.

You end with two forms of growth: another person has something more useful, and you have evidence that your skill can respond to reality rather than only follow instructions.

Summary: usefulness creates motivation and credibility together

Listening keeps the project grounded in a real need. A small responsible build makes testing possible. Feedback turns the work into a shared improvement. This is digital bayanihan when the relationship remains respectful and the learner does not claim more impact than the evidence supports.

The project does not have to change an entire community. Helping one person complete one recurring task more clearly is already a meaningful place to practise.

To move closer to the person you want to become

• Ask one person about a repeated task before proposing a tool.
• Write a one-sentence first-version boundary.
• Use fictional or permitted information only.
• Observe one test and record the user’s words accurately.
• Make one revision and state the remaining limitation.