Social Startup Portal: Volunteers at Scale

Overview

A volunteer management web app that helps nonprofit and company users manage their opportunities and volunteers — bringing together three very different user groups, each with their own needs, on one platform.

Volunteer

The person giving their time to a cause.

Focus of this case study

Nonprofit

The organization managing opportunities and the volunteers who fill them.

New

Company

Builds culture and engages employees/customers by enabling their people to volunteer for nonprofit sectors that matter to them.

This case study showcases a feature built for the nonprofit user — but every design decision also considers how it ripples into the volunteer’s experience on the other side.

Designing for multiple user groups at once was challenging, but it exercised a skill I see as essential going forward: finding solutions that work across more than one dimension at a time.

Lets nonprofits seeking volunteers on Meaningful Work do four things:

Manage opportunity postings

Manage volunteer applications

Track progress of accepted volunteers

Write testimonials for outstanding volunteers

Problem Statement

The nonprofit management feature didn't have one specific problem — it had a multitude of undiscovered ones. Before I took it over, only a very basic flow existed, untested for over a year. I knew immediately there was a lot of ground to cover, starting with pushing for real user testing.

Starting out, 2 obvious questions stood out about the feature's flow:

1. Is the progress review loop clear
for both sides?

A "progress" modal let volunteers log hours and completed milestones, then submit them to the nonprofit for review and approval. The open question: how do we make that back-and-forth review process — sending feedback, requesting revisions — clear and effective for both the volunteer and the nonprofit, across real use cases?

Katie Smith's Progress modal on the Opportunity Dashboard with milestone logs and approve actions

2. Should one slow response hold up
every volunteer?

Originally, an opportunity couldn't begin until every invited volunteer responded — accepted or declined — even if one or more had already accepted. A single unresponsive applicant delayed the start for everyone else, creating irritation and a poor experience on both sides.

Opportunity Dashboard showing accepted and declined volunteer offers with Begin Opportunity action

Users and Audience

Of the platform’s 3 user groups — volunteers, nonprofits, and companies — this feature targets the nonprofit user. Every decision still weighs the volunteer’s experience too; company needs are considered least, since no features have been designed for that group yet.

Let’s take a look at the nonprofit user

  1. Posts a volunteer opportunity on the platform, hoping to attract interested applicants.

  2. Receives applications from volunteers interested in the posting.

  3. Reviews applications and sends offers or rejections, as they see fit.

  4. Monitors the progress of volunteers throughout the opportunity.

  5. Writes a testimonial for the volunteer at the end of the opportunity.

Roles and Responsibilities

When I started this feature, I worked alongside another designer on wireframing, prototyping, and user testing. When they left before the design was finished, I took over the handover to development — reviewing and wireframing missing states, componentizing modals into our design system, checking spacing and layout consistency, annotating specs and user flows, and running dev/design meetings to keep decisions aligned through a successful handover.

Scopes and Constraints

There weren’t any specific constraints for the management feature, other than the fact that it was difficult to find a lot of nonprofit users for user testing. Moving forward, it would be ideal to grow our user base for future user testing.

Process - Part 1

Pre-Design

The gap: opportunity postings don’t redirect volunteers to similar postings when they skip the one they’re on — a missed chance to fix Meaningful Work’s ongoing retention problem. Found by walking the test app as a nonprofit user across multiple passes.

Make the meta tags on a volunteer’s profile page clickable — redirect to opportunities sharing the same tags.

Volunteer profile Goals section showing impact areas of interest and personal development goals tags
Profile — Goals

Same behavior on the opportunity page — clicking a skills or impact area tag redirects to similar opportunities.

Opportunity details page showing opportunity type, skills, and impact area tags
Opportunity — Skills / Impact

It is important to go over the 4 different parts to the management feature and how they work (prior to my involvement) before we dive into the design process.

Both the management page and opportunity dashboard have their preliminary design done before I started on the feature:

1. Management Page

The Management page is where nonprofits manage all their opportunity postings on Meaningful Work’s platform. They can view all the posting drafts they created, the “open” opportunities – the ones accepting applications from volunteers, and “ongoing” ones – the ones currently in progress, etc.

Meaningful Work Management page showing opportunity postings with draft, open, ongoing, and closed statuses

2. Opportunity Dashboard

The Opportunity Dashboard is where the nonprofit user can manage its applicants that applied to its opportunity posting. On the Applicants tab, they can view each applicant’s application and choose to either schedule an interview with them and send them an offer or rejection message. On the Progress tab, the nonprofit user can track the status of the applicants that the nonprofit has extended an offer to. If all volunteers have accepted their offers and responded (even if its “decline” offer), the nonprofit then could begin the opportunity where they could now manage the volunteers’ progress on the Progress tab.

Meaningful Work Opportunity Dashboard showing Applicants tab with applicant statuses and offer actions

3. Progress Tab

The Progress tab allows the nonprofit to view each volunteer’s progress on the opportunity. The idea here is that every volunteer onboard with the opportunity would log their progress when they completed each milestone/goal in the opportunity. Once all logs are completed, they would submit for the nonprofit to review and approve.

Meaningful Work Opportunity Dashboard Track Progress tab showing volunteers waiting to respond to offers

4. Impact Story/Completing Opportunity

Finally, the Impact Story is a “testimonial” written for the volunteer once they have completed the opportunity (after the nonprofit approves of the progress). The writing of the testimonial is optional, hence, if a testimonial is not written, the nonprofit would be asked if they could provide feedback on what could have been done better. Afterwards, the nonprofit would then complete the opportunity so that the opportunity would now be marked as a “closed” opportunity on the Management page.

Meaningful Work Track Progress tab with Progress Approved status and Create Impact Story action for volunteers
Meaningful Work Track Progress tab showing Opportunity Completed status with View Impact Story action and Close Opportunity button

After having walked through the test app myself, I discussed with the management team in terms of what needs to be designed.

Since the Management page and Opportunity Dashboard are well established, I took on the Progress tab.

This is how the Progress modal looked in the beginning:

The nonprofit user views the hours and milestones a volunteer logged for an opportunity, as a list of progress logs — each showing the milestone and hours dedicated to it.

Send back for review

Leaves general feedback on everything logged so far, so the volunteer can make revisions.

Approve

Used when everything looks good — completes the opportunity on the volunteer's behalf.

Katie Smith's Progress modal showing milestone logs, project attachments, and send back for review or approve actions

The progress modal has to work for 2 user groups at once — the volunteer logging progress, and the nonprofit reviewing and approving it — so the back-and-forth needed to stay clear and enjoyable for both. Here's the first ideated solution, wireframed for the team to review.

Screen 1 — Progress List

  • A checkbox on each log lets the nonprofit comment on individual entries — feedback gets more specific and clear.

  • A status column shows whether a log is reviewed, revised, or completed.

  • Clicking a log opens its full milestone details.

  • Once every log is marked complete, the nonprofit approves the modal — closing out the opportunity.

Katie Smith's Progress
Screen 1 Progress List wireframe showing Katie Smith's progress logs with status column and checkboxes for nonprofit review

Screen 2 — Log Detail & Revisions

  • Where the nonprofit lands after clicking into a progress log from screen 1.

  • Shows both the nonprofit's feedback and the volunteer's comments on their revisions, side by side.

  • The nonprofit can send another comment, or mark this specific log "complete."

Katie Smith's Revision(s) for Milestone 2
Screen 2 Log Detail and Revisions wireframe showing Katie Smith's milestone revisions, comments history, and mark complete action

Management's pushback: the design was too complex. Their assumption was that reviewing and commenting on every individual log would overwhelm the nonprofit user — so their proposal was to review everything at once, after all milestones are submitted, leave one comment, and approve if it looks fine.

The progress modal going for user testing instead:

Referenced screens: 3-state progress log flow Select Feedback Revision

Step 1

  • The nonprofit selects the log(s) they want to give feedback on — after all progress has been submitted by the volunteer, rather than reviewing as each milestone comes in.

    Katie Smith's Progress modal for user testing with progress log selection and comment box for send back for review

I disagreed with that rationale, and still do. Letting the nonprofit comment as progress is logged catches errors earlier and keeps both users more engaged — I also pushed for a revision comments history so both sides could reference past feedback later. Since we didn't align, I pushed for user testing to validate the simplified version instead.

Since there weren't any user testings conducted on the management feature since a year ago, this would be considered the first user research/testing in a long time. It would be the opportunity to validate a lot of design decisions, not solely for the progress modal that I pushed for, but the overall management feature in general.

This is the opportunity to understand our nonprofit users better and make design decisions beyond us designers or the management team.

Process - Part 2

After the Progress modal, management wanted chat modals for rejecting volunteers — letting the nonprofit send a personalized, kind message both when rejecting someone individually and when mass-rejecting everyone not accepted for an opportunity.

Sending a personalized message to every rejected applicant might seem excessive — the nonprofit has to reject and message everyone before starting the opportunity with accepted applicants — but the stakeholder's intent was clear: keep volunteers encouraged to apply again, not discouraged. Another reminder that this feature has to balance nonprofit, volunteer, and stakeholder needs all at once.

Rejection Chat Modal (Individual)

1st wireframe — designed by a co-designer, with my feedback

Individual — Screen 1

  • To reject an applicant, the nonprofit user clicks on “not the right fit” on the applicant’s application (application modal designed by another designer)

    Katie Smith's Application modal on the Opportunity Dashboard with Not the right fit link to reject an applicant

Rejection Chat Modal (Mass Reject)

Mass Reject — Screen 1

  • If the nonprofit user has enough volunteers who accepted their offer, the nonprofit can click on “Begin Opportunity” to start the project with the accepted volunteers. Clicking on the “Begin Opportunity” button would trigger the modal to reject all remaining applicants that were not reviewed, accepted, and whom have not responded to their offer yet to pop up

    Opportunity Dashboard with Begin Opportunity button to start the project and trigger mass reject for remaining applicants

Schedule Interview Chat (preliminary design)

Other than the chat modals, there’s also a modal for scheduling a meeting/interview with the applicants. Here, we see a preliminary design for scheduling interview (designed by another designer – gave feedback on design) which I would further design later in the process:

Schedule Interview — Screen 1

  • Nonprofit user clicks on “schedule a meeting” to book a time to speak with an applicant that they’re interested in

    Katie Smith's Application modal with Schedule a Meeting link to book time with an applicant

In preparation for user testing, I helped build a testing doc covering all 4 parts of the management feature. For post-test questions, if participants struggled with the progress tab, I'd dig deeper into why — since that tab is what sparked the need for testing in the first place.

In retrospect, our questions should have been more open-ended, letting users explore the flow themselves rather than guiding them (e.g. "how would you delete a draft from this view?"). We aimed to test specific features, but self-exploration would have been more realistic and valuable.

Some questions from the user testing doc:

Q1

How would you delete a draft opportunity from this view?

Q2

Walk me through reviewing a volunteer’s logged progress.

Q3

How would you message everyone you’re not accepting?

Q4

How would you know an opportunity is ready to begin?

Another use case that we’ve identified as a team is that volunteers who have been extended an offer by the nonprofit to an opportunity may reject or won’t respond to an offer. This could be due to life plans and commitments that don’t allow the volunteer to volunteer anymore for the opportunity that they applied to.

In this case, the original design was to have a 7 day time limit for the volunteer to respond to their offer.

Volunteers extended an offer sometimes reject or never respond — often due to life plans or commitments changing. The original design gave volunteers a 7-day window to respond.

Opportunity Dashboard Track Progress tab showing offer sent 7 days ago and Offer Expired status on volunteer cards
How the 7 day timestamp looks like previously before the redesign (initial design):

The 7-day window prevents the nonprofit and already-accepted volunteers from starting the opportunity. With multiple volunteers offered at different times, this compounds: if Volunteer A accepts immediately but B (3 days in, 4 left) and C (just offered, 7 left) both use their full window, A ends up waiting 7 extra days anyway — frustrating for everyone.

It also creates a business risk: knowing offers can sit for 7 days, nonprofits would likely extend fewer offers at once to avoid a backlog. That works against their actual interest in onboarding more volunteers — too high an opportunity cost for a flexibility roadblock.

I've brought this concern to the team and presented a new user flow that I created that would address this problem:

The problem, worked through

Volunteer A Accepted immediately but still waits
Volunteer B Offered 3 days ago 4 days left to respond
Volunteer C Offered today 7 days left to respond

If B and C both take the full window, A — who said yes right away — still waits 7 more days to start.

Knock-on business risk: knowing offers can sit for 7 days, nonprofits would likely extend fewer offers at once to avoid a backlog — directly working against their interest in onboarding more volunteers.

The fix I proposed

First-come, first-served onboarding — no timestamp at all. Whoever responds first gets onboarded; once capacity is filled, everyone else is automatically rejected.

User flow diagram showing first-come-first-served volunteer onboarding with rolling acceptance and automatic rejection once capacity is filled
The idea with this user flow is that applicants would be onboarded on a first come first serve basis. There would be no timestamp. Whoever responds first would be onboarded to start – and once volunteer capacity has been filled – all other volunteers would get rejected.

Another part that's part of the feature is the Impact Story. An Impact Story is essentially a testimonial written by the nonprofit to the volunteer to appreciate the hard work that they've put in for the volunteer project/event.

This is a simple impact story flow that I designed before the testing:

A “Create an Impact Story” modal immediately appears after the last volunteer’s progress has been approved by the nonprofit. The nonprofit could either create an impact story or choose to close without a testimonial for the volunteer (an automated impact story that records the volunteer hours and impact value would be created without the testimonial)

Impact Story — Screen 1

  • Create Impact Story modal on the Opportunity Dashboard prompting the nonprofit to write a testimonial or close without one after progress is approved

The idea behind the impact story flow was that the user would be prompted to create an impact story once the volunteer’s progress has been approved. Iterations would be made to the impact story flow later on as it would prove to be not clear enough.

After the design changes have been made to the progress tab, chat modals, and having determined the flow to when a volunteer rejects/doesn’t respond to an offer – the feature is ready for prototyping.

Open on YouTube

At the same time that I was working on the prototyping of the management feature, I continuously gave feedback on how the progress tab would look like on the volunteer’s side to make sure that the features and designs are consistent.

My Opportunities My Progress tab showing volunteer progress logging, nonprofit feedback, attachments, and send for review

1st Round – Internal: (7 participants)

Opportunity dashboard / chat modals
Mass rejection chat modal

Unclear recipient; wants auto-generated template; needs clearer “rejecting” indicator.

Individual rejection chat modal

Skipped the message field — prefers it automatic.

View volunteer profile

Expected a name click to go straight to the profile.

Applicant review flow

Rejected-applicant interaction felt jarring; most just want to move fast.

Progress tab / impact story / closing
Impact story creation

Needs instructions/tooltips, both sides of the experience.

Closing an opportunity

Should auto-close once the last impact story is completed.

Progress tab

State changes unclear; wants per-milestone submit-and-approve.

2nd Round – External: (3 participants)

Opportunity dashboard / chat modals
Applicant review flow recurring

Chatting with rejected volunteers before accepted ones felt out of order.

Chat modal recipient clarity recurring

Assumed messages were going to accepted volunteers.

Opportunity dashboard — progress cards

Only shows accepted volunteers — confusing with declined applicants mixed in.

Progress tab / impact story / closing
Impact story

Positive — shows the volunteer’s success; compared to LinkedIn skill endorsements.

Progress tab recurring

Unclear when the modal counts as “completed” — too many states.

During the design of the feature, there were opportunities for both the design and developer team to come together to do a QA of both the volunteer’s user profile and understanding how a nonprofit user would go about creating an opportunity on the platform.

It was a great opportunity to see if the current experience for both the volunteer and nonprofit makes sense when we use the application ourselves (potential feedback to be incorporated into the new version of the design), and to detect any bugs within the process.

Process - Part 3

Based on the feedback from the first 2 user testings above, iterations needed to be made on the chat modals to make sending a message more efficient and personalized. As for the impact story, one participant mentioned that there were no clear instructions on how to create an impact story (“how do I create an impact story, where does the impact story get sent to, where can I find the impact story afterwards”). Since only one participant reported the concern during the first user testing, I wanted to see if there were more responses in the next 2 user testings before I make any iterations.

Based on the 2nd user testing’s feedback (external user) for confusion around not sure when the opportunity ends, hence, there is a need to make clear of the stages of going through the progress for the nonprofit user.

The intention of the progress stepper is to indicate at which stage of the progress the nonprofit user is on, the action they have to take next, with a hover-over tooltip to guide them along the way.

I also asked the CTO if this is implementable technically speaking.

(Below is the flow of the progress stepper – initial design):

The 1st progress stepper shows “Offer Accepted” – this is the first and default state in the progress stepper. Once a nonprofit begins an opportunity, the progress stepper card appears for the volunteer in their progress card under the “Volunteer Progress” tab. At this stage, the stepper shows that the volunteer has accepted the offer but has not taken any further action yet.

Progress Stepper — Screen 1

  • Volunteer progress card showing Offer Accepted stepper state with Progress Logged status and View Progress action
Opportunity dashboard / chat modals
Progress stepper clarity

Unclear what a greyed-out state means — needs a clearer color change.

Rejection messaging preference

Should be up to the nonprofit whether to message rejected volunteers; one participant only wants to see who they’re working with.

Progress tab / impact story / closing
Impact story — awareness & preview recurring

Neither participant was sure they’d created the story — sharing happened suddenly, with no confirmation or preview beforehand.

  • Confirm creation, show where to find it, before sharing.
  • Preview for first-time nonprofit users.

I asked the participant whether or not a change in the progress stepper colour would make it more clear to know what it means – and the participant said yes.

Here is the iteration to the progress stepper below (before and after):

Before: Stepper’s in progress colour was highlighted grey instead of yellow or orange due to another designer’s feedback that yellow is not part of our brand guidelines. Hence, the orange/yellow colour I chose for the 1st design of the stepper was changed to grey.

Progress Stepper — Before

  • Progress stepper before iteration showing in-progress step highlighted in grey with Offer Accepted tooltip and Progress Logged status

After the 2nd Internal User Testing – The Impact Story Preview:

During the 2nd internal user testing, there were 2 participants who suggested that they are still confused with how to create an impact story/testimonial for a volunteer, and that it would be nice to have a preview – hence, a preview is added to the modal so that the user can see in real time how an impact story is being created.

I incorporated the impact story and closing (because closing is also not intuitive as well), and after brainstorming as a team – we decided to close the opportunity automatically once an impact story has been created for every volunteer.

It is important to note that creating an impact story is optional – if a nonprofit decides not to write a testimonial they can leave the testimonial blank and a default impact story would be created (just the impact hours volunteered and the impact value).

Below shows an impact story flow with testimonial:

1. Written testimonial in the input text field box appears on the preview of the volunteer’s impact card on the left. This makes it clear to the nonprofit user what an impact story is, how to create one, and who the testimonial is being sent to.

Impact Story Preview — Screen 1

  • Create Impact Story modal with live preview showing Katie Smith's impact card updating as the nonprofit writes a testimonial in the input field

Impact story without testimonial:

1. If the nonprofit chooses not to provide a written testimonial for the volunteer’s impact story, then an impact card with only the volunteer hours and volunteer’s impact value gets populated and shown on the impact card.

Impact Story (No Testimonial) — Screen 1

  • Create Impact Story modal with empty testimonial field and impact card preview showing only Katie Smith's hours and impact value

4th Round – Internal: (2 participants)

Confirmed working
Progress stepper

Orange reads as “in progress,” green as complete.

Impact story preview

Both participants understood what it is, who it’s for, and where it appears.

New issue
Progress visible pre-submission

Felt odd to see progress before it’s submitted — one participant wanted to comment immediately, and questioned the point of “submitting” at all.

Changing the stepper to orange, and adding the impact story preview, both resolved the confusion they were meant to fix.

According to similar feedback in the 1st and 2nd user testing session – the idea of unsure when progress ends and the experience being tedious since there is a lot of back and forth (to check, give feedback on progress, and volunteer resubmits for review before approving), the 4th and last user testing session ensured the need to actually make the progress tracking flow more clear.

The removal of the state revision submitted suggests that the volunteer can submit their progress whenever (not submitted in the end) and the nonprofit can give feedback whenever. This aligns with my original idea (in the very beginning before all the user testings – that the nonprofit would prefer to be able to give feedback on each progress as the volunteer logs rather than give a generic comment in the end).

Below is the comparison in the change in the progress flow:

Open on YouTube

Open on YouTube

Although the purpose of the user testing is to not necessarily prove that the designer is right, it is however to note that had the designer not pushed for the change and to validate the idea through user testing, then a confusing experience might be shipped out.

Attachments Flow (missing previously) – Componentized into Design System

Within the progress tab, there’s also an attachments pill that opens up upon click to show the attached documents and links submitted by the volunteer to include alongside the progress they logged for the nonprofit.

Previously, the management feature is missing an attachments flow, now it’s included in the feature – below is the attachments flow:

When the nonprofit clicks on the attachments pill, the images/files attached drop down and are shown.

Attachments Flow — Screen 1

  • Katie Smith's Progress modal with Opportunity Attachments pills expanded to show three attached image thumbnails and two links
Notifications

Five moments that trigger a notification to the nonprofit.

New application

Notifies the nonprofit when a volunteer applies — prompts them to view the application.

Notifications list showing Katie has applied to the Customer Relationship Management CRM Advising Call opportunity with a View Application link
Offer accepted

Notifies the nonprofit that the volunteer accepted — prompts them to begin the opportunity.

Notifications list showing Katie has accepted the offer with a Begin Opportunity link
New follower

Notifies the nonprofit that a volunteer started following them — the volunteer gets notified of future postings.

Notifications list showing Katie Park has started following the nonprofit and will be notified of new opportunities
Progress logged

Notifies the nonprofit that the volunteer logged progress — prompts them to view it.

Notifications list showing Katie tracked progress for the CRM Advising Call opportunity with a View Progress link
Impact story reminder

Reminds the nonprofit to create an impact story after approving progress, to complete the opportunity.

Notifications list showing a reminder to create an impact story for the Customer Relationship Management CRM Advising Call opportunity

Once all the core designs are done, I started componentizing the modals and cards within the design flow – below are the modals and cards that I componentized into the design system for ease of moving the flow into the handover file for the development team later on.

Accepted

The volunteer accepted the nonprofit's offer.

Volunteer application card showing George Yang accepted the offer with View Profile and message actions
Waiting

Offer extended, and the nonprofit is waiting on the volunteer to accept or decline.

Volunteer application card showing Waiting for George Yang's response with View Profile and message actions
Declined

The volunteer declined the offer.

Volunteer application card showing George Yang declined the offer with View Profile and message actions

I componentized the dashboard’s header so that the state of the opportunity, button, and image/text can be interchanged conveniently to show the different instances.

Componentized Opportunity Dashboard header showing interchangeable opportunity status, Begin Opportunity button, and Volunteer Progress and Applicants tabs at large breakpoint

Some missing states were also added:

Applicants table — declined state

Componentized the missing “declined” state in the applicants table to show when a volunteer declines an offer. Also added a notification letting the nonprofit know.

Opportunity Dashboard Applicants tab showing Cindy MacDonald with Declined status and a notification that she declined the offer
Management page — closed vs. completed

Previously, opportunities only had a “closed” state. Componentized a new “completed” state so the two are clearly distinguished:

Closed

No applications received, or the nonprofit closed the posting manually without beginning it.

Completed

The opportunity began, progress was approved, and impact stories were created for every volunteer — it then auto-completes.

Management page table showing Completed and Closed opportunity states with distinct status badges and actions
Management page — beginning an opportunity

The nonprofit can now begin an opportunity directly from the management page, alongside the opportunity dashboard — starting whenever they judge that enough volunteers have accepted, even with no new applicants pending.

Management page table showing CRM Advising Call with 3 Applicants Onboarded and a Begin Opportunity action

Since data tables are prevalent throughout the design flow, it is essential to ensure that paginations are added for every screen that has a table – with the number of pages matching the table header for the correct number of pages that makes sense.

Applicants table showing Accepted and Offer sent statuses with pagination controls below
Added pagination for all screens with a data table
Opportunity Dashboard Applicants tab header showing 1-5 of 5 Applicants count aligned with table pagination
Fixed the table header to reflect the number of rows and pages correctly; also added a search bar within the table header

Another design fix that I had done was making the volunteer’s name to be a clickable hyperlink so that the nonprofit user could view the volunteer’s profile easily. Previously, the nonprofit user would have to click on the hyperlink text “View Profile” to view the volunteer’s profile. According to the feedback from the 1st user testing session, that wasn’t intuitive and seemed redundant when the name could be a direct entry point to the profile itself.

Applicants table before fix showing Joseph Gropologus name with separate View Profile link below
Before: “View Profile” clickable hyperlink text underneath the volunteer’s name
Applicants table after fix showing Benjamin Davis and Katie Park names as clickable profile hyperlinks
After: Removed the text underneath the volunteer’s name; made the volunteer’s name as the clickable hyperlink text instead should the nonprofit wants to view the volunteer’s profile

After making sure that everything design wise is included in the flow, I started the process of checking all the screens in the feature:

I checked the spacing to make sure that all the frames are consistent in their spacing and labeled everything accordingly (all the layers) to make sure they’re clear for other designers in the future and for developers who will be working on the designs pretty soon.

Figma layers panel and Applicants tab screen for Applicant accepted the Opp showing labeled frames, data table structure, and spacing guides
Example of screen properly labelled and laid/spaced out consistently with the rest of the feature flow

Final Thoughts

This feature is now complete and in handover with a developer.

I would say the challenge for this project is to take into consideration the different user groups involved – the nonprofit and volunteer users, and the stakeholders (management team). It's especially challenging to design new features on top of an existing design (especially a design that has not been tested for in a year's time). Designing for this feature had me carry a lot of doubts about designing on top of a design that might be highly flawed since it's not been validated through user testing.

How I understand design to be is to follow the design process of conducting UX research and speaking with our users first. If a designer jumps head first into design without having the opportunity to understand the scope of the problem, the actual problem(s) they're solving for, who their users are, and what they're building for that user group – then it requires a high cost later on in both time and effort to backtrack and improve on the design then.

Therefore, in my next design, I pushed the management team to allow me to speak with the company users first and actually take the time to brainstorm and ideate before jumping straight into design.

You can now find this new project named "Web-App: Team Volunteering Feature for Company Users" under the UX Portfolio Tab (currently in progress).