As it is written, so it shall be done.

Overview. AWS User Notifications centralizes alerts across accounts, regions, and channels. I was the sole content designer on it from launch, owning content strategy end to end: UX copy, documentation architecture, a cross-service writing template, and post-launch iteration.

The problem. Before this service existed, getting notifications meant manually configuring EventBridge rules, CloudWatch Alarms, and SNS topics: fragmented, inconsistent, and easy to get wrong. Alerts arrived in disconnected formats, there was no unified view of account health, and raw SNS emails offered little context. The goal was to consolidate all of that into one experience people could understand and adopt quickly.

Process. Pre-launch, I worked with PMs, engineers, and a UX designer to shape the content strategy alongside the service architecture, iterating on console copy, error messages, and notification templates before anything shipped. For launch, I authored the full user guide and getting-started content, and built a cross-service documentation template so any AWS writer could document their own service's integration consistently. Post-launch, I deployed docs alongside engineering from GitHub, tracked feedback and performance, and later added API and CloudFormation guides for more integration paths.

Key decision: managed vs. user-configured notifications. When AWS introduced notifications delivered automatically by default ("managed"), the existing guide only covered the kind users set up themselves. I restructured the guide into two clearly named sections, managed and user-configured, within the same document, so the distinction was immediately clear regardless of which type a reader arrived looking for. The naming was deliberate: parallel terms that tell users exactly who controls what.

The cross-service template. Since User Notifications integrates with nearly every AWS service, dozens of other writers needed to document their own service's integration. I built a standardized template with required sections and customizable fields, which kept documentation consistent across AWS, saved other writers significant time, and cut down my own review overhead.

Outcome. A complete documentation set (user guides, UI text, conceptual content) built from zero and ready at launch, on a framework designed to scale as new notification types and channels were added without a rewrite.

Overview. Amazon Q in chat applications (formerly AWS Chatbot) is a generative-AI assistant built into Slack and Microsoft Teams for monitoring, troubleshooting, and running commands against AWS resources. When it expanded from read-only commands to mutative ones (actions that could change or delete resources), the product needed a permissions model it never had before. I was the content designer responsible for introducing that new conceptual layer without breaking the mental model existing users already had.

The problem. This wasn't just writing about new features. It meant naming concepts with no prior reference in this product's vocabulary, building a mental model two different audiences (administrators and end users) could each enter from their own side, and doing it without contradicting documentation people already understood.

Naming the concepts. I introduced three terms: Channel Roles, User Roles, and Guardrails. The first two mapped cleanly onto existing enterprise-software conventions. Guardrails was the harder call: I found precedent in AWS Control Tower's use of "guardrails" for policy-based account controls, which gave the term a documented basis in the AWS ecosystem and made a stronger case to stakeholders than inventing new vocabulary. Consistency with the platform's existing language is what lets users transfer what they already know.

The information architecture problem. Channel roles and guardrail policies both apply at once, and guardrails always take precedence regardless of role. The line that made this legible to administrators: "What your users can do is the intersection of your guardrail policies and what is allowed by their roles." That sentence became the mental model the rest of the page reinforced rather than introduced.

Two audiences, one system. Administrators configure the channel: permission scheme, channel roles, guardrail policies. End users operate inside whatever the administrator set up, and set their own roles if the scheme requires it. I structured the docs so each audience could find their own path without reading content meant for the other, while making sure neither missed context that affected them.

Validation. I validated both the content and the naming with engineering and product stakeholders before publishing, checking the Guardrails terminology specifically against the Control Tower precedent for ecosystem consistency.

Outcome. Channel Roles, User Roles, and Guardrails are live in the product and its documentation today, and the permissions documentation became the conceptual foundation for how administrators understand and configure Q's security model.

Overview. The AWS Console Mobile Application lets people view and manage a select set of AWS resources and receive push notifications, so they can stay connected to their AWS environment while away from a desk.

My role. Content designer, technical writer, and UX writer on the app, working alongside a PM, UX designer, engineers, and an editor, writing for the small, easy-to-overlook moments (empty states, modal interactions) that shape whether a mobile experience actually feels usable on the go.

Full technical documentation is live at docs.aws.amazon.com/consolemobileapp.

User guide and conceptual documentation for Amazon Q's Slack/Teams integration, including the permissions model introduced in Case 05 (Channel Roles, User Roles, Guardrails). The live documentation covers both the user guide and the API guide.

View live doc →

User guide covering the mobile app's resource views, push notifications, and the empty-state and modal copy detailed in Case 06. The live documentation covers both the user guide and the API guide.

View live doc →

The full user guide and getting-started content built from zero at launch, including the managed vs. user-configured notifications split covered in Case 01.

View live doc →

Help documentation for the AWS Management Console, the shared surface behind most of the other services here and one of the highest-traffic doc sets I support. The live documentation covers both the user guide and the API guide.

View live doc →

CloudFormation template reference for provisioning User Notifications resources: the developer-facing counterpart to the console-first docs in DOC-03.

View live doc →

CloudFormation template reference for Amazon Q's chat integration, still filed here under its legacy resource name, AWS::Chatbot.

View live doc →

Overview. A team project aimed at improving the experience of buying and selling used items locally in metro areas, for users 18–35. Early research surfaced convenience, safety, and trust in item integrity as the core pain points, which shaped everything that followed. Team: Nia Lindsey, Anna Malecki, Whitney Nelson, Andy Zhou, and myself.

My role. Research phase: synthesized competitive analysis findings, contributed survey questions, and ran two semi-structured interviews. Analysis phase: helped build affinity diagrams and generate design criteria. Design phase: joined brainstorming sessions, made mock-ups and storyboards for one design alternative, and helped build the prototype in Sketch with InVision for interactivity. Evaluation phase: helped write the evaluation plan and tasks, and recruited participants.

Research methods. A competitive analysis mapped existing solutions against the pain points we were seeing. Semi-structured interviews with 5 participants (convenience sampling) surfaced three recurring themes: convenience, safety, and anonymity. A follow-up survey (68 responses, distributed across Reddit, Facebook, iMessage, GroupMe, and Tumblr via snowball and convenience sampling) found most respondents were 18–34 and metro/suburban, largely neutral on anonymity, generally comfortable meeting a buyer or seller, and split between shipping and meeting locally as the most convenient exchange method.

Synthesis. Qualitative coding of the survey's open responses confirmed convenience, safety, and trust as the major themes, which drove the interview question design. Task analyses for both buyers and sellers, plus personas built from the research, gave the team a shared model of user needs going into design. An affinity map of the interview data, built by "walking the wall," turned high-level pain points into concrete design ideas, both granular features and larger concepts.

Design directions. The team narrowed dozens of sketched ideas down to three concepts for further development: a meet-up helper, a gamification approach, and a locker-agent concept for exchanging items without meeting in person.

Overview. An industry-partner project with Home Depot on associate task management, helping the company balance customer engagement against internal store needs. The team narrowed scope to managers and supervisors, who needed a better way to track associates' schedules and skills and to quantify customer engagement. Team: Anna Malecki, Whitney Nelson, Andy Zhou, and myself.

My role. Research phase: conducted 3 of 7 associate interviews, ran observation sessions, contributed to secondary research. Analysis phase: contributed to qualitative coding, built the task analysis for both associates and supervisors, helped identify design implications. Design phase: joined brainstorming and empathy-mapping sessions, generated multiple rounds of sketches and wireframes. Evaluation phase: helped write the heuristic evaluation plan, recruited participants, helped analyze results, and acted as note-taker/facilitator during other evaluation sessions.

Research methods. The team started with secondary research: Home Depot job descriptions, associate forum discussions (Green Door, Reddit), competing tasking apps, and company news, before observing three different store locations to understand spatial layout and how associates actually used their tools. Key finding: the stores' large floorspace made it hard for one associate to find another, and shared work phones (FirstPhone) meant devices were often passed between associates mid-shift. Semi-structured interviews followed, with 4 associates and 3 managers/supervisors, analyzed through qualitative coding.

Constraints. The two biggest challenges were access, since managers and supervisors run busy, inflexible schedules that made scheduling research time difficult, and technology, since associates share a limited pool of FirstPhones (often without signing out) and aren't permitted personal phones on the floor. Both constraints shaped the design space directly.

Synthesis and ideation. Personas, empathy maps, and storyboards captured user needs and pain points. From brainstorming, the team sketched three directions: a FirstPhone app to check who's on duty, a customer-feedback kiosk that also surfaced associates' assigned tasks, and a digitized version of Home Depot's existing peer-to-peer feedback system (Bravo Board). User feedback sessions favored the first idea, developed further with elements of the third.

Final concept. An app centered on visibility and skill-matching: browsing who's on duty, filtering by skill or knowledge, and sending posts to ask for help or collaboration, addressing the core problem that associates and managers couldn't easily tell who was working or find them in a large store.

Evaluation. Moderated usability testing with 6 Home Depot managers and associates (think-aloud, quantitative + qualitative post-task questions) ran alongside unmoderated heuristic testing with 3 UX professionals against Nielsen Norman's heuristics. Findings drove concrete iterations: an onboarding flow after users missed the filters and status indicators, a redesigned add button after participants weren't sure what it did, and a restructured posting flow after users confused "posting" with "emailing."

Overview. Part one of a study, carried out with Dr. Adrienne Decker, exploring the real effects of representation in video games as a medium, and investigating design methods for well-rounded, impactful representation of Queer People of Color (QPOC). The published paper has since been cited 14 times in scholarly literature. Read it here.

My roles. Experimental designer, researcher, data analyst, writer, interviewer, and survey designer.

Methodology. A mixed-methods study using a convergent design approach: an online survey and a set of one-on-one interviews, run in parallel and brought together during analysis. This first paper focuses on the survey component.

Survey design. The QPOC Representation in Video Games Survey collected demographic data: age, sex, gender, sexual orientation, and race/ethnicity (using the US Census Bureau's race/ethnicity questions for consistency with established measurement standards). Respondents then answered 5-point Likert-scale questions on their agreement with statements about QPOC representation and identity in games, followed by two open-ended questions on identity and representation.

Overview. Information Technology: HUD Can Take Additional Actions to Improve Its Governance (GAO-15-56), a report to Congressional committees published by the U.S. Government Accountability Office in December 2014, examined how well the Department of Housing and Urban Development governed its IT investments and recommended additional oversight actions. Read the report here.

My role. Researcher and data analyst on the engagement, contributing to the analysis behind a report delivered directly to Congressional committees, a different register of stakes and audience than product or academic work, where findings inform federal oversight decisions rather than a product roadmap.

Overview. Information Technology: Key Attributes of Essential Federal Mission-Critical Acquisitions (GAO-20-249SP), published by GAO in September 2020, profiled 16 IT acquisitions the federal government identified as critical to missions ranging from national security to public health to the economy — describing risks to their cost and schedule. IT acquisitions and operations management has been on GAO's High-Risk List since 2015. Read the report here.

My role. Researcher and data analyst, contributing to the analysis behind profiles of some of the federal government's highest-stakes, highest-cost IT programs, the kind of work where a wrong or unclear finding has consequences for agencies spending billions of dollars over more than a decade.

Overview. An internship project at Brookhaven National Laboratory redesigning the application used to display polarized jet data in real time. The redesign's constraints came directly from its predecessor and from the users themselves: the interface had to feel new, but still familiar to people who relied on the original tool daily.

My role. Programmer, designer, and usability researcher, carrying the project from understanding what the original Tcl/Tk application got right and wrong, through redesigning the interface, to building the replacement in the same language so it would integrate cleanly with the lab's existing systems.

The constraint. "New, but familiar" is a harder brief than either half alone: a pure redesign risks alienating users who've built muscle memory around the original, while a too-faithful update risks not solving the problems that prompted the redesign in the first place. Balancing those two pulls shaped every interface decision.

Overview. Gloom Box is a 2D music-driven puzzle-platformer built as an RIT Game Design & Development Master's capstone project in Unity2D and C#, developed under the team name Pentatonic Games. Read more about the game here.

My role. Data analyst, user researcher, and survey writer, responsible for the surveys and playtest data used to iterate on the game, including sessions with professional developers at the Game Developers Conference (GDC).

The data. Playtesting ran across eight rounds from February through December 2017, tracking how the game's mechanics and feel evolved release over release. All playtest data is public for anyone who wants to see the raw results behind the design decisions.

Overview. As a Digital Media Intern at Cartoon Network, I evaluated gameplay experience and UX for the CN Arcade app and its mobile titles, including Steven Universe: Shattered Dreams, Teeny Titans 2, and Smashy Piñata, across iOS, Amazon, and Android.

My role. QA and UX evaluation across platforms, partnering directly with game producers, creative directors, and developers to refine mechanics and interface design, with the goal of improving user satisfaction and interactive quality on every platform the titles shipped on.

Media. Testing across devices was part of the job — checking how the same session held up on a tablet versus a phone, since resource counts, UI scaling, and progress state all had to stay consistent across screen sizes.

Overview. A browser-based tool that audits web content against a published 100-point rubric for Answer Engine Optimization (structuring content so AI systems like ChatGPT and Perplexity can find, extract, and cite it). Designer, developer, and content strategist on this one, built solo with Claude Code. It grew out of the same instinct behind the AWS User Notifications work: find the one framing sentence or structural decision that makes something complex legible.

The problem. Most AEO tools I found measured structure alone (schema present, headings tidy) and called that optimization. The rubric I built against draws a real line between checks a script can verify and checks that need human judgment. I wanted a tool that respected that line instead of collapsing it into one misleading number.

Design decisions. Client-side only, by choice: everything runs in the browser, no backend, no dependencies beyond two web fonts. A request to check a live URL directly ran into a real constraint (browser CORS policy blocks that kind of cross-origin fetch), and rather than bolt on a fragile proxy workaround, I reduced the actual friction instead, surfacing clear "View Page Source" instructions the moment someone switches into HTML mode. The score is out of a real 100, with judgment-only checks marked "pending review" rather than scaled into a smaller, more confusing ceiling. Markdown input is supported too, converted into minimal HTML and run through the same scoring functions as full HTML, so there's only one scoring implementation to keep correct.

A category split, found through testing. While auditing my own tool against the source rubric, I found two checks I'd built as simple keyword-matching that the rubric actually classifies as judgment calls, and one I'd filed under judgment that the rubric treats as mechanical (it just needs a full-site crawl to verify, which is a data limitation, not a judgment one). Conflating those was dishonest about what the tool could actually tell someone. I split them into two labeled categories, "needs review" and "needs more data," and kept the original keyword heuristics visible as disclosed, unscored hints rather than deleting them or leaving them silently mis-scored.

A real debugging story. Testing a "clean" sample surfaced five distinct bugs: a judgment-only check with a hardcoded pass that silently scored every scan; a text-extraction method that broke because it depended on the browser having rendered the element, which a parsed-but-unattached document never does; a paragraph-length check that was counting headings as paragraphs; a hedging-language regex that flagged "it does not depend on X" as vague because it matched "it does" without checking for the negation that followed; and a scoring ratio that counted inapplicable checks in its denominator, so content that maxed out everything it could actually be scored on still failed. Each bug was caught with a real DOM-testing environment and confirmed fixed by re-running the same test.

Testing it against an LLM-written sample. I ran AI-generated content that had graded itself a 52/100 through the tool; it scored 16/100. Most of the gap was legitimate: the sample was a bare content fragment missing the page-level metadata a full document needs. The more interesting finding was what the self-graded 52 likely reflected: an evaluator scoring its own substance and originality, the single most subjective, highest-weighted section of the rubric. My tool refuses to auto-score that section at all, for anyone or anything doing the judging.

What I'd build next. Broader schema-format detection beyond JSON-LD, and crediting well-formed table rows and list items as citable facts alongside prose paragraphs. Both are real gaps I left out of v1 on purpose.

Overview. Gloom Box is a 2D musical puzzle-platformer following Muse as she explores a musical world called Opus, accompanied by her sentient boombox, Gloom. Gloom lets Muse play cassette tapes she finds; each tape holds a different genre of music, and each genre grants a different ability. Play the game · visit the dev blog · third place, RPI's 2017 Game Fest.

My roles. Lead audio designer, game designer, user researcher, and programmer.

Game mechanics. Three core abilities, each tied to a genre: choral makes NPCs bouncy, heavy metal makes monsters heavier and weighs down objects like buttons, and blues makes NPCs cry, producing water. Abilities can be mashed up two at a time: heavy metal plus choral, for example, reverses gravity. Two-ability mashups turned out to be the right ceiling for the number of interactions the game needed without becoming unreadable.

User research. Research ran as bi-weekly playtests using talk-aloud, direct observation, retrospective testing, semi-structured interviews, and surveys, with findings feeding directly back into design. See the full research data here.

A change driven by playtesting. Early on, players struggled to track which ability was active. The fix was color-coding: each genre got a color (blues = blue, heavy metal = red), and a mashup's area-of-effect showed as a blend of both: a heavy metal/blues mashup renders as purple. Beyond clarifying the mechanic, this made the game more accessible to players who are hearing impaired, since the ability system no longer depended on audio cues alone.

Complexity map. A full map of every interaction available in the game (three base abilities and their mashups) was used to keep the interaction space intentional as the design evolved, rather than letting mashup combinations grow unchecked.

Watch it played. A YouTuber's playthrough of Gloom Box:

Overview. Pixalto is a game built around choice: your life is your ammo, so every shot you fire is life you no longer have. That trade-off is the entire tension of the game: more aggression means more power in the moment, and less room for error afterward.

My roles. Lead audio designer, game designer, user researcher, and programmer, the same mix of roles as on Gloom Box.

Mechanics. Facing an enemy, the player has three options: attack (spending life as ammo), befriend a friendly enemy (rewarded with more ammo/life, and the enemy takes on the player's hue), or avoid the encounter entirely. Critically, there's no visual distinction between hostile and neutral enemies, so the player has to decide how to engage without knowing in advance whether it'll pay off.

The metaphor. These three choices were designed as a metaphor for how we handle people in real life: we can attack, which sometimes takes a personal toll but is sometimes the necessary and valid choice; we can befriend and become a little more like the people we let close, carrying them with us; or we can avoid the interaction altogether. The game doesn't privilege one choice as correct; life is about balancing all three.

User research. Playtests ran at the end of sprints or after implementing a new feature, using the talk-aloud principle and retrospective testing to catch how players were actually reasoning through the attack/befriend/avoid choice, rather than how the design assumed they would.

Trailer.

Overview. Two To Tango is a cooperative-competitive board game for 4–8 players, played in teams of two. Each round, partners score by staying physically close to one another and coordinating their dance moves: cooperation within the team, competition between teams. See the listing on The Game Crafter.

My roles. Game designer and user researcher.

User research. The game was playtested weekly. Designers observed players directly and noted pain points or mechanics that needed adjustment, and ran semi-structured interviews whenever a specific mechanic was under test. Players were also free to share how the game made them feel, not just what confused them. See the changes made as a result of playtesting.

Overview. Aurora Borealis is a meditative artistic piece built with cellular automata in JavaScript. The color scheme and backdrop take their cues directly from the northern lights, and the piece is designed to pull the viewer into a state that's both attentive and relaxed at once.

My roles. Designer, programmer, composer, and sound designer: every layer of the piece, visual and audio, built by one person so the two could be tuned against each other.

The experience. The visualized history of the automata creates flashing, shifting light patterns, which sit in deliberate contrast against a hazy, ambient audio layer. That tension between the flicker of the visuals and the calm of the sound is what gives the piece its particular feeling: not purely calming, not purely stimulating.

Overview. Visual design poster concepts created for OMONDI, a New York-based fashion designer, built in Adobe Illustrator.

Three poster concepts for the OMONDI brand.