Jess L McPeak

Designing re:UNION, a mobile app for workers

re:UNION is a mobile app for workers, unionized or not, built around four jobs: explaining labor rights and how unions actually operate, hosting a union's internal affairs (discussion, meetings, elections), organizing strike votes and picket logistics, and keeping collective bargaining negotiations visible to the members those negotiations are about. I designed it as the final project for DES 112 (UI/UX Design: Principles and Practices) at UC Davis under Kathreen Fontecha, who asked us to build a mobile app around a social or political issue we cared about.

American union membership was 10.9% in 2018, according to the Bureau of Labor Statistics. In the United Kingdom that same year it was 23.4%, and in the US in 1983 it was 20.1%, so the rate has roughly halved inside a single working lifetime. The consequence I designed around is a knowledge problem. Because so few American workers ever encounter a union directly, most of what they believe about unions comes from news coverage, television, and film, and because labor law is written in legalese, plenty of workers do not know which protections they already have.

Narrowing an enormous idea down to four tasks

My initial research was an affinity map and a SWOT analysis, and both landed on the same problem: re:UNION as I had pitched it was far too large for ten weeks. Education, internal governance, elections, strike logistics, and bargaining are each their own product with their own users. I saw two workable responses (narrow the scope hard, or design an onboarding flow careful enough to route each kind of user to the part they need) and I chose to narrow, because onboarding that sophisticated is itself a term's worth of work.

The research also showed me that voting turns up everywhere in union life, in forms ranging from procedural to genuinely consequential, so that interaction had to be fast and unambiguous about what was at stake. I scoped the project to four tasks, covering both the unauthenticated and the authenticated experience:

• Learn about unions as a guest user
• Join an online union meeting as a member
• Vote to strike as a member
• View collective bargaining history as a member

Everything else (in-meeting tools, meeting scheduling, content authoring, and the security model an app for organizing workers would genuinely need) I wrote up as out of scope instead of sketching it thinly.

Flows, wireframes, and the prototype

I worked from task flows into user flows and wire flows before touching visual design, then built the four tasks as an interactive Figma prototype. Working in that order meant that by the time I was choosing type and color, the open questions were about legibility and tone, and the structure underneath was already settled.

The interface had to hold two moods at once. re:UNION carries urgent and sometimes adversarial content (a strike vote, a bargaining update, an employer's counteroffer), and it also has to feel unthreatening to someone who is not a member yet and may be nervous about being seen with it open. I leaned on plain language and generous spacing for the guest-facing side, and kept the denser, more utilitarian layouts behind authentication where the user already knows why they are there.

This was also where Figma itself stopped being an obstacle: layered auto layout and prototyping overlays are the reason the second draft came together in a fraction of the time the first one took.

Usability testing with six participants

I tested the prototype with six design undergraduates from my UI/UX cohort, in the classroom, giving each participant one or two of the four tasks. I explained what the project was, asked them to think aloud, started the relevant prototype flow, handed over my laptop, and took notes without intervening. Afterward I asked each of them about the experience.

Every participant completed every task they were given, which made task completion the least useful measurement in the study. The interesting result is that all four problems I found were problems of wording:

• Two participants went to news when they were looking for collective bargaining history. In the debrief they explained the logic: history sounds like the user's own history (search history, previously viewed), while news sounds like the things that apply to your current situation.
• One participant could not distinguish the unions tab from the news tab while trying to learn what a union is, and did not register that the what is a union card was tappable at all.
• Three participants stalled on the waiting screen after casting a strike vote, because nothing on that screen indicated whether they should wait or leave and check back.
• One asked whether declining camera and microphone permissions would still let her into the meeting, which the permissions dialogue never answered.

The pattern that worked better than I expected was the pop-up dialogue. Several participants said it put them where they needed to be quickly, and in both the meeting task and the voting task it did more of the navigational work than the tab bar did.

What the testing changed

• Renamed the union page's history tab to updates, which is much closer to the words participants used when describing what they expected to find behind it.
• Added a countdown to the strike vote waiting screen, so a member can tell at a glance whether to stay or come back later.
• Logged two more changes I ran out of term to make: a read and unread indicator on union updates, and replacing the bargaining label terms with something concrete like the store's proposal.

I think the tab rename is the most useful thing in this project. It cost nothing, it survived into the final prototype, and I could not have reasoned my way to it, because it came out of six people saying out loud where the line falls between what is old and what still applies to them.

Where re:UNION would go next

If I picked this back up, the next round would start with reference research on the parts I scoped out: online meeting services (Discord, Zoom, and iClicker for live polling) for the in-meeting tasks, and scheduling tools (Google Calendar, When2Meet) for organizing them. I would also want a subject matter expert on the content, because labor law advice that is confidently wrong is worse than none, and I would need to understand how the interface decisions interact with security, given that an app for organizing workers is an obvious target for the people being organized against.

I pitched re:UNION over two safer ideas because Fontecha told me to pick the one I actually cared about, and I think she was right that a portfolio should show what a designer is willing to spend attention on. The lesson I took from building it is narrower than its subject, though: six people and one class period were enough to find every real problem in the prototype, and every one of them turned out to be a word.