Turning complex systems into clear, usable experiences.
I research, structure, and write digital content, from campus apps to autonomous-drone control systems, with a focus on information architecture, plain language, and accessibility.
Melody Washington
I'm a UX and content designer with a computer science background and a research focus in Human-Computer Interaction. I work across the whole arc: talking to users, structuring information, writing the words on the screen, and building the front end that ships them.
Day to day I maintain large content-managed platforms in Drupal, where the work is exactly this: making complex program information clear, accessible, and easy to act on for people who aren't experts. I care about plain language, accessibility (Section 508 / WCAG), and designing for the task someone is really trying to finish.
University of Minnesota
Institute of Child Development
Let's work together
Open to UX content design and content strategy roles. The fastest ways to reach me:
Three projects, one throughline: design driven by research.
Each case study moves from user research to a structured, tested interface. Gopher Social is documented end to end; FarmGuard shows complex operational UX; Code-Sync is in progress.
Gopher Social
A campus community platform helping first-year students discover, join, and keep up with student groups, grounded in surveys, interviews, and two rounds of usability evaluation.
Read case study
FarmGuard
The control app for an autonomous drone system that deters deer from farms. As App Team Lead, I designed the workflows farmers use to map their land, schedule patrols, and monitor flights in real time.
Read case study
Code-Sync
The community app for Girls Dream Code, a nonprofit that runs free tech programs for girls. I helped ship the React Native app the students use to stay connected, and this study pairs it with a usability-driven redesign concept.
Read case studyHelping first-year students find their people
The university lists 1,000+ clubs. Students still couldn't tell which were active, how to join, or which fit their schedule. Gopher Social rebuilds that experience around what students actually do.
Students wanted to get involved, then quietly gave up
Through surveys and interviews, the reasons came down to three recurring barriers.
Can't tell what's active
Listings had no status, so students couldn't tell which clubs still met or posted events.
Unclear how to join
60% said they were simply unsure how to join, and many couldn't find a point of contact.
No fit to their schedule
Search couldn't filter by interest or the specific times a busy student was actually free.
Research approach
Before designing anything, we ran a mixed-methods study following standard UX research practice: a survey of first-year students paired with semi-structured interviews of student-group leaders to capture both sides of the problem. Participants gave informed consent, responses were anonymized, and we grounded the work in secondary research on how involvement affects students' adjustment to college. We also did a competitive teardown of the existing tool, GopherLink.
Who we designed for
Two personas, built directly from research data, anchored every later decision.
- Clubs that fit a packed, shifting schedule
- To filter events by the hours he's free
- A community matched to her interests
- A low-pressure way to ask a club questions
The high-fidelity product
The design moved from paper wireframes to a working high-fidelity prototype in Figma. Each screen below reflects a specific research finding, not a style choice.
From insight to interface
The core of this project is the throughline: nearly every screen decision traces back to a specific research finding. A sample from our documented change list:
| What research told us | What we designed in response |
|---|---|
| Students couldn't tell if a club was still active | An "active" status indicator on every club page, scoped to a recent time window |
| Schedules vary day to day; date ranges weren't enough | Per-day time-availability filtering, matching clubs to the hours a student is free |
| Hidden contact info made students give up | Social links, website, and a direct-message button centralized on each club page |
| People didn't know whether to search clubs vs. events | Unified search across both, after users showed no consistent mental model splitting them |
| Hard to remember which days had events | Calendar dots under any date with an event, favoring recognition over recall |
Evaluating & iterating
We ran a cognitive walkthrough on two core tasks (finding a club that fits a busy schedule, and messaging a club you've joined), stepping through each action as a first-time user would. It surfaced real friction: the club-page icon wasn't distinct enough, and there were competing paths to message a club. Rather than smoothing these over, we logged each issue and tied our fixes back to it.
The walkthrough also exposed our own blind spot: as designers we understood every button's intent, which made it hard to see the interface with fresh eyes. Naming that changed how we tested afterward.
What I took from it
Gopher Social is where I learned to treat content and structure as the design, not decoration on top of it. The features that mattered most weren't visual flourishes: an "active" label, a clearer filter, contact info in one place. Each was a small content or IA decision that removed a reason to give up. That's the same discipline I bring to content-managed platforms today.
The control room for an autonomous drone system
FarmGuard protects crops by autonomously herding deer off farmland: no fences, no harm to the animals. I led the app team designing how a farmer sets up, schedules, and monitors the whole operation from one interface.
A real farmer, losing crops to deer she couldn't afford to fence out
Our agricultural partner framed the brief in her own words, and it shaped every design constraint.
"I know deer will damage my crops as soon as they grow, because my farm sees heavy deer traffic. I can't afford to install a deer fence. I'm concerned the time and money I invest will be wasted, which makes me hesitant to plant."
The design challenge
A farmer is not a drone operator. The hard part wasn't the autonomy: it was giving a non-technical user a way to describe their land and intent to an autonomous system, safely. My team structured the app into three clear views so a first-time user could go from "I have a farm" to "drones are patrolling it" without a manual.
Zones Editor
Draw directly on a satellite map of your own property: the patrol boundary, no-fly zones, crop areas, obstacles, exit lines, and docking points.
Flight Scheduler
Pick a patrol area, date, and time slot. The system plans energy-efficient routes from there.
Dashboard
Live weather, a plain-language flight-safety status, active/completed flight counts, deer-detection stats, and a full flight log.
Designing for safety and trust
When the interface commands real drones over someone's property, content and feedback are safety features. We classified conditions into three plain-language states (Safe, Caution, Unsafe) instead of raw numbers, and blocked same-day deployment automatically when wind, visibility, or precipitation crossed set thresholds. The farmer can always recall the drones or take manual control. These were writing and information-design decisions as much as engineering ones.
Feedback from the field
We tested the concept with our farm partner directly, the kind of real-user validation that matters more than a polished mockup.
She found the interface intuitive and the concept well-suited to her farm, while flagging that some zone types, like low-obstacle zones and exit lines, weren't immediately obvious without context.
That feedback drove a concrete next step: an interactive onboarding tour that walks a new user through each zone type with examples before they start, a direct content/IA response to an observed usability gap.
Why this project matters for content design
FarmGuard is proof I can make a genuinely complex, high-stakes system understandable to a non-expert. Mission setup, mapping, scheduling, safety states, live monitoring: I structured all of it into a workflow a farmer could actually follow. That's the same skill enterprise content work demands: take something technical and operational, and make it clear enough to act on with confidence.
Code-Sync mobile app
Code-Sync is the community app for Girls Dream Code, a nonprofit running free tech programs for girls. It's how the students they serve stay connected, reach mentors and resources, and keep building in tech. I worked on the shipped app; this study pairs it with a redesign concept grounded in usability, not just a fresh coat of paint.
The app is live in both stores, built for the girls in Girls Dream Code’s programs. You can try the shipped product while the redesign case study comes together.
The live app today
Code-Sync already ships a warm, on-brand experience: a members directory, curated resources, discussion prompts, and profiles. But it was built to exist, not to pull people back. Here is the current app, end to end.
A great app that people open once and forget
The team’s real challenge isn’t features: it’s activity. Members join, look around, and don’t come back or talk to each other. Three things drive that.
No reason to return
Home opens on a fixed quote and one “Student of the Month.” Nothing changes day to day, so there’s nothing to check.
Posting feels one-way
You answer a prompt and it drops into a flat list, with no reactions, no replies surfaced, no sign anyone saw it.
The community is invisible
Other girls only appear if you search “Find GDC Members.” The room never feels full, so it never feels worth joining in.
Heuristic evaluation
I walked the app against engagement-focused heuristics: habit loops, social proof, feedback, and reward. The pattern was consistent: every screen informs, but none of them invite the next action.
| What I saw in the app | Why it suppresses activity |
|---|---|
| Home is a static quote + one highlight | No fresh, daily reason to reopen, the core of any habit loop |
| Prompts are answer-and-leave, in a flat list | No reactions or surfaced replies, so contributing feels like posting into the void |
| No streaks, goals, points, or badges | Nothing marks progress or rewards showing up, so there’s no momentum to protect |
| No notifications bring members back | The app only exists in the moments someone happens to remember it |
| Members are hidden behind a search box | The community never feels alive, so social pressure to participate is zero |
The redesign: a reason to come back every day
The fix isn’t more content, it’s a habit loop. I borrowed the mechanics that make apps like Duolingo and Mimo sticky (streaks, daily goals, badges, a light leaderboard, and well-timed push), and rebuilt them in Girls Dream Code’s own coral brand so it still feels like their app, just alive. Two new pillars give girls something to actually do here: Code Games, bite-size coding lessons that earn XP, and Build & Host, where they publish a real website or AI model live for the whole community to open and use.
Every mechanic maps to one of the three problems: something new daily (reason to return), visible response (posting pays off), and visible community (others are here, and ahead of you).
From problem to mechanic
Each change is a direct answer to a research-backed engagement gap, not decoration.
| Design move | Why it drives activity |
|---|---|
| Streak counter + daily-goal ring on Home | Loss aversion: once you have a 12-day streak, you open the app just to protect it |
| “Prompt of the day” front and center | One fresh, 30-second action every single open, the smallest possible reason to return |
| Reactions + reply counts on answers | Turns posting-into-the-void into visible social feedback that rewards contributing |
| Tech Challenge of the Month as a step-by-step track | An ongoing goal with a progress bar, not a one-off: progress you don’t want to abandon |
| Earnable badges + weekly leaderboard | Recognition and gentle competition, tied to GDC’s real program milestones |
| Smart push: streak, replies, new challenge | The piece that reaches members when the app is closed, where re-engagement is actually won |
| Code Games: a Mimo-style lesson path with XP | Turns passive resource links into an interactive game girls want to keep playing |
| Build & Host: publish a live website or AI model | Gives real work a public home, so members open the app to see and use what others made |
How I’d measure it
Because this is an engagement bet, success is behavioral, not cosmetic. If the redesign works, these move, and they’re the numbers I’d put in front of the team.
Return rate
Day-1 and day-7 retention, and average streak length: are people coming back, and building a habit?
Interaction
Replies and reactions per prompt, and weekly active members: is the community actually talking?
Pull-back
Share of sessions opened from a push notification: is the nudge system doing its job?
How I’d validate the redesign
Every change here is a behavioral bet, so I wouldn’t ship it on intuition. This is the research plan I’d run to prove each one works, validating the design with real students first, then measuring the change in behavior after launch.
| Method | What it answers |
|---|---|
| A/B test: new engagement layer vs. the current app | Do streaks, daily goals, and push actually raise return rate and interaction? Each mechanic gets a clear hypothesis, tested against a control group. |
| Moderated, task-based usability testing | Can a student find today’s prompt, publish a project, and join the challenge without friction? Measured by task success, time on task, and a SUS score, with think-aloud notes. |
| Cohort retention analysis | Are members building a habit? Tracked with D1 / D7 / D30 retention curves, median streak length, and DAU/WAU stickiness. |
| Funnel & event analytics | Where do people drop off between opening the app and taking an action, and what share of sessions start from a push notification? |
Because Girls Dream Code serves a small, close-knit community, many of them minors, I’d size tests realistically, using longer measurement windows or a staged rollout rather than a strict 50/50 split when the numbers are low. And I’d run all of it on the same ethical footing as my Gopher Social research: informed consent and assent, parental consent where needed, and anonymized data.
What would tell me it’s working: the treatment group shows a meaningful lift in 7-day retention and replies per prompt, streaks reach a healthy median length, and usability scores hold or improve, with no rise in members muting notifications. If a mechanic doesn’t move its metric, it gets cut, not kept for looks.