Now · Instructional Manager · 300+ staff across 9 sites

Hello, I am Tina

A learning designer who builds with AI.

10+ years designing training and onboarding, helping teams adopt new tools, and building the apps that support them.

San Francisco, CAetin0427@gmail.com

Résumé ↗ View work ↓

95%of staff log in and use their dashboards regularly

+1.31skill gain on a 5-point scale in a 5-week training pilot (15 staff)

−50%onboarding time with role-based pathways

1 monthto build and pilot a multi-site web app

Work

Learning DesignFacilitated training

STEP Inclusion Training Series

A 5-session series that prepares substitute staff to step into unfamiliar teams and support the lead's plan.

+1.31skill gain, 5-pt scale

5 of 5skill areas improved

Learning DesigneLearning

Self-Paced eLearning Modules

Turned SME knowledge into self-paced modules and job aids, so every new hire learns the same content.

300+staff reached

20%post-assessment gains

Learning & DevelopmentOnboarding program

Role-Based Onboarding Pathways

One onboarding for everyone became a path for each role, so people work independently sooner.

+8%satisfaction

−50%onboarding time

EnablementDigital adoption

Data Dashboard Adoption

Turned raw data into dashboards for each role, then trained staff to use them for daily decisions.

95%adoption

4 waysadoption measured

Product & AIWeb app

Consultation Service Tracker

A web app that replaced the spreadsheets a consulting team used for visits, deadlines, referrals and reports.

8reports

1record per person

1 monthto pilot

Product & AIWeb app

Café Reservation System

One dashboard for a café that handled bookings across four channels.

4 → 1channels

4 → 2steps to confirm

Skills

Learning Design

Turn expert knowledge into training, eLearning and job aids people use on the job, then measure whether it worked.

Needs analysis
Storyboarding
Scenario-based learning
Facilitator guides
Assessment design
Pre/post evaluation

Learning & Development

Build and run learning programs: onboarding pathways, competency frameworks, LMS setup, tracking and reporting.

Onboarding programs
Competency frameworks
LMS administration (Moodle)
SCORM publishing
Enrollment and completion tracking
Content migration
Adoption reporting

Enablement

Get people ready for new roles, tools and processes, with buy-in from the teams around them.

Role-based training
Digital adoption
Stakeholder alignment
Train-the-trainer
Performance support

Product & AI

Scope, design and build internal tools with AI, from user research to a tested release.

Product scoping (RICE)
User research
Prototyping in Figma
AI-assisted development
Testing and verification
Privacy by design

Tools

Articulate 360
Moodle
Claude
Google AI Studio
Figma
Canva
Asana
Final Cut Pro

Languages

English, fluent
Mandarin Chinese, native
Japanese, basic

← All work

Learning design · Facilitated training

STEP Inclusion Training Series

Substitute staff were placed into unfamiliar teams and had to read situations fast, then support the lead's plan instead of overriding it. I designed a 5-session series, using AI across the design process, and piloted it over five weeks.

My role: Instructional designer Facilitator
Learners: Substitute staff joining new teams
Format: 5 live sessions, 90 min each
Pilot: 5 weeks, 15 participants

+1.31Understanding what drives behavior, 2.69 → 4.00 on a 5-point scale

3.00 → 4.00Confidence joining a new team

5 of 5skill areas improved, confirmed by Coach

From unsure to confident in five weeks

Before

No shared way to read behavior
Unsure how to support the lead's plan
Low confidence in a new team

STEP series5 sessions

5 weeks, 15 participants, live practice and on-shift homework

After

2.69 → 4.00Understanding what drives behavior

3.00 → 4.00Confidence joining a new team

5 of 5Skill areas improved

Self-ratings before and after the series, confirmed by coach assessment.

Problem

Stepping into a team you don't know

Substitute staff moved between teams and had to read situations fast. Data showed inconsistent handling, not low effort.

No shared language

for reading what drives someone's behavior in the moment

No guidance

on supporting a lead's plan instead of overriding it

Low confidence

walking into a team they didn't know

Solution

Designed backwards from one goal

I used action mapping. Starting from one goal, I listed what substitutes must do on shift, then gave each action its own practice and only the information it needs. Interviews with substitute and lead teachers showed which gaps training could fix and which it couldn't.

Goal

Substitutes are ready to handle challenging behaviors from day one in any classroom

01Check in with the lead before entering

Practice

Prep checklist homework: confirm 3 things before a shift

Info

Check-in questions: who needs extra support, how to help in transitions, allergies, breaks

02Observe before reacting

Practice

Video reflection and open discussion

Info

Positioning: pause, observe, stay nearby
Ask: "How can I support right now?"

03Identify what drives the behavior

Practice

Video scenarios and role play
Observation log: name the likely function

Info

Functions: to get or avoid, sensory, attention
Gentle approach: get low, slow, calm voice

04Respond in line with the lead's plan

Practice

Strategy homework: how I stepped in to support
Role play

Info

Follow the teacher's strategy; ignoring is not disengaging
Unsafe behavior: block, remove, report

05Raise concerns the right way

Practice

Scenario sort: disagreement or inappropriate?
Script role play and a 3-step action plan

Info

Disagreement vs. inappropriate
Talk-it-through scripts; report channels; document facts

Not a training problem

Interviews showed subs often got no briefing, didn't know who to ask, and feared not being rebooked if they raised concerns.

Fix outside the sessions: a one-page role and decision guide that covers when to step in, how to ask, and where to report.

Evidence

+1.31understanding what drives behavior

3.00 → 4.00confidence joining a new team

5 of 5skill areas improved

How the sessions build

Each session starts from what people already know and ends with a task to try on their next shift.

Session 1FoundationWhat they already bring

Sessions 2 to 4Apply and navigateVideo scenarios, role play, real situations

Session 5CapstoneShow the skill

Observe on shift→Reflect→Bring it back to the group↺

The weekly homework loop turned one-time training into practiced habit.

What I built

5-session curriculumFacilitator guides with timing and promptsVideo scenarios and role playOn-shift homeworkSelf and coach evaluation tools

Process

How I built it

Discover
Data showed inconsistent handling, not low effort. AI helped surface root causes.
Define
Sequenced from existing knowledge to confident practice.
Design
Storyboarded every session so any facilitator can run it.
Develop
Guides, decks, scenarios and homework. AI drafted, I decided.
Evaluate
Paired self-ratings with coach observation.

Results

Before and after the series

Self-ratings from the pilot cohort. Coaches rated the same areas using defined indicators.

BeforeAfter

012345

Self evaluation & Coach assessment

Facilitator guide: session overview, prep checklist and a lesson plan with timing, prompts and example answers

Curriculum map: topics, objectives, frameworks and activities for each session

Session decks: one for each of the five sessions, plus the personal project

Evaluation tools: participant pre/post self-evaluation and the coach growth assessment

What I learned

← All work

Learning & Development · Onboarding program

Role-Based Onboarding Pathways

New hires and promoted staff all went through the same onboarding, whatever their role. The goal was to give each person the tools and confidence to work independently in their own job, sooner.

My role: Lead learning designer
Learners: New hires and promoted staff, all levels
Partners: HR, department leads, site managers, SMEs
Timeline: 3 months

+8%Onboarding satisfaction

−50%Onboarding time

1 standardSame quality across roles and locations

From one path to a path per role

Before Same content for every role, every level Too much info, discrepancies found After Shared core Role A path Role B path Promotion path Mentor Mentor Mentor Ready Ready Ready

Week 1Checkpoint

Week 2Checkpoint

Day 90Working independently

Simplified. Each path maps to that role's competencies. Checkpoints at week 1 and week 2, then a mentor until the person works independently.

Onboarding schedule and timeline for one role

Schedule for one role: orientation, shadowing, then check-ins and surveys from 30 days to 6 months, each with an owner

Onboarding contents: one checklist for every new employee, plus items specific to each position

Problem

Why onboarding wasn't working

Scattered scheduling

Each subject matter expert scheduled onboarding on their own, so sessions were scattered across calendars

Slow to independence

Onboarding dragged on for weeks before people could work independently

One size for everyone

Same content for every role and level: too much information, and discrepancies between sessions

What new hires told us

From a new-hire survey across roles and one interview per role. Each finding shaped one part of the new pathway.

They saidWhat changed

Schedules were out of dateSome Zoom links were missing, or the meeting was not inserted.

One cohort calendar, with every session sent to the new hire's calendar

Too much packed into one dayToo long, almost 6 or 7 hours per day.

Sessions spread across week 1 and week 2 in half-day blocks

Who you met depended on luckI didn't meet with Fiscal nor Coaches.

A shared core every new hire completes, with a set time for each department

Nothing to refer back toI would've liked written documentation about certain tasks.

Job aids and eLearning on the LMS, open anytime

Follow-up depended on one personI wish I had more responsive and timely support from my supervisor.

A work buddy for the first 3 months, plus 30- and 60-day check-ins

Solution

A pathway for each role

Competencies by role

A competency framework tied to each role

Shared core + role paths

A shared core plus role-specific pathways, with week 1 and week 2 checkpoints

One cohort calendar

A cohort schedule that replaced one-off SME sessions

Resources and a work buddy

eLearning assets and job aids on the LMS, plus a work buddy (mentor) for the first 3 months

Process

How I built it

Discover

Surveyed new hires across roles and interviewed one employee per role
Mapped how each SME scheduled their own sessions, and where new hires waited
Gathered manager and SME input on critical competencies and pain points

OutputGap analysis

Define

Defined role-specific competencies and success criteria
Prioritized what each role needs in week 1, week 2 and after
Set onboarding goals aligned with operational expectations

OutputCompetency framework

Design

Designed a shared core, role-based pathways and a cohort schedule
Created journey maps, learning objectives and checkpoints
Built eLearning modules and job aids in Storyline

OutputPathways and journey maps

Implement

Integrated learning assets into the LMS
Replaced one-off SME sessions with one cohort calendar across locations
Aligned managers, SMEs and mentors on what each checkpoint means

OutputLMS pathways and cohort calendar

Evaluate

Collected learner feedback and manager observations
Measured satisfaction, LMS engagement and onboarding time
Refined resources and delivery from the findings

Output+8% satisfaction, −50% onboarding time

What I learned

← All work

Learning design · eLearning

Self-Paced eLearning Modules

New hires learned the basics from subject matter experts in person, on the SMEs' schedules. I worked with SMEs to turn that knowledge into self-paced Storyline modules and job aids, so every new employee gets the same content and SME time goes to practice. I was the designer and one of the SMEs.

My role: Instructional designer and SME
Learners: New hire staff
Tools: Storyline 360, Moodle, SCORM
Rollout: Rolled out to all new employees

300+Staff reached through the LMS

20%Post-assessment gains

ReusableOne build, deployable across roles and locations

Before and after the modules

BeforeAfter

01Who taught the basics

Depended on whoever was availableSMEs repeated the same content for each new hire, on their own schedules. If someone was out, another person taught it differently.

Same modules for everyoneNew hires start right away with consistent content. SME time goes to practice and questions.

02After onboarding

Seen once, hard to revisitLittle way to reinforce what was learned

On the LMS, open anytimeStaff revisit modules and resources when they need them

What I built

Storyline 360 modulesJob aidsRole-based learning pathsStoryboards reviewed with SMEsLMS resource hub

Each row pairs one problem with the change that fixed it.

Solution

Key design decisions

Each choice answers a specific problem new staff had.

Role ARole BRole C

Only what Role A needs

Pick your role

Problem: One set of content for every role, so people sat through what didn't apply to them.

How it works: Tabs let each person open their own role's content and skip the rest.

One idea at a time

Problem: Handouts were dense walls of text that were easy to skim and forget.

How it works: Animated text reveals one idea per screen, so learners move at a steady pace.

Practice before the real job

Problem: New hires heard the rules but had no safe place to try them.

How it works: Branching scenarios and knowledge checks give feedback on each choice.

Job aids for after the module

Problem: Details faded once people were on the job, with nothing quick to check.

How it works: One-page references live on the LMS next to the modules.

Process

How I built it

Discover

Interviewed SMEs and sat in on live sessions to capture what they repeated for every new hire
Reviewed existing handouts and onboarding materials
Identified knowledge gaps and what new staff need first

OutputContent inventory and gap list

Define

Wrote learning objectives and success criteria by role
Agreed with SMEs on what moves online and what stays live
Mapped content to role-specific competencies

OutputObjectives and scope agreed with SMEs

Design

Storyboarded short, job-focused sequences
Designed role tabs, paced text and knowledge checks
SMEs reviewed storyboards for accuracy before build

OutputStoryboards signed off by SMEs

Develop

Built Storyline 360 modules with branching scenarios and knowledge checks
Created job aids for quick reference on the job
Published as SCORM packages to Moodle

OutputModules and job aids on the LMS

Evaluate

Collected learner feedback and tracked LMS completion
Measured post-assessment results
Refined modules with SME input

Output20% post-assessment gains

Storyboard: scenes, on-screen design notes and narration script, reviewed with SMEs before building

Storyline build: click-to-reveal layers and triggers let learners explore each area at their own pace

What I learned

← All work

Enablement · Digital adoption

Data Dashboard Adoption

Staff entered data every day, but the system only showed raw records. To see a report, people exported several tables and stitched them together themselves. I worked with IT to build dashboards for each role in IBM Cognos, then ran the training that got staff using them to monitor their work and make decisions.

My role: Enablement lead: training and adoption
Users: Staff across sites, by role
Partners: IT and managers; UX designers joined in stage 2
Stage: Stage 1: Cognos dashboards. Stage 2: merging into the internal platform

95%Of staff log in and review their dashboard regularly

By roleEach role sees the reports that matter to its work

4 waysAdoption measured: logins, learning groups, manager monitoring, surveys

From raw data to a report each role can use

Before

Data entry systemRaw records only, no reports

→

Export table A

Export table B

Export table C

→

Stitch them together in a spreadsheet

→

One-off reportSlow, hard to compare, built again next time

After

Data entry systemSame data, entered as before

→

Role-based dashboardsIBM Cognos pulls the tables together

→

Program staffAssessment progress, strong and weak skill areas

Support staffHealth record completion

ManagersAttendance across sites

→

Daily monitoring and decisions

What I built

Report needs by roleRole-based dashboardsTraining seriesNavigation guidesAdoption tracking

Simplified. Each role's dashboard shows the few reports that role uses most.

Guide detail: callouts show staff how to read each chart (sample data)

Pages from the step-by-step navigation guide I wrote for staff

Solution

Training and measuring adoption

A dashboard only helps if people read it and act on it. Training ran as a series of sessions and follow-ups, moving from how to open it to how to use it for better work.

Introduce

Meet the dashboards

Where to find your role's dashboard
What each report covers

Follow up

Read the reports

Filters, trends and comparisons
Spotting what is high, low or missing

Keep it going

Use them at work

Turn a report into a next step
Make monitoring a daily habit

LoginsTracked by role

Learning groupsOne per role

Manager monitoringReports used in daily work

SurveysSelf-reported use and feedback

Process

How I built it

Discover

Talked with each role about the decisions they make day to day
Reviewed how staff exported and combined tables to build their own reports
Gathered the data needs and pain points shared across roles

OutputData needs by role

Define

Chose the key reports for each role
Mapped which tables each report needs to pull together
Defined success: regular logins and reports used in daily work

OutputReport list and success measures

Design

Worked with IT to build role-based dashboards in IBM Cognos
Reviewed layouts with staff so each report answers one clear question
Drafted navigation guides with annotated screenshots

OutputRole-based dashboards and guides

Implement

Ran an intro training, then follow-up sessions on reading the reports and using them at work
Set up learning groups by role
Shared step-by-step guides for self-help

OutputTraining series and learning groups

Evaluate

Tracked logins by role
Managers monitored how reports were used in daily work
Surveyed staff on how they use the reports and what to improve

Output95% log in and review regularly

What I learned

← All work

Product I built · Web app

Consultation Service Tracker

A team of consultants tracked visits, compliance deadlines, referrals, reports and notes across shared spreadsheets. I built the web app that replaced them, as product owner and builder, using AI-assisted development.

My role: Product owner and builder
Users: Consultants and admins, multi-site
Timeline: Aug 31 to Oct 1, 2026
Status: Pilot, deployed

8Reports, each scoped to a site and date range

1Record per person, across years and sites

1 monthFrom first commit to pilot

From scattered spreadsheets to one system

Before

A spreadsheet per site, per year. Totals rebuilt by hand, history split across files.

After

Each consultant sees only their sites
One record per person across years
Deadlines tracked automatically
8 reports from connected data

Problem

Why the spreadsheets stopped working

Spreadsheets worked for one site and one year. As the program grew across sites and years, four things broke. Access control was the biggest.

Access

Each site needed its own spreadsheet so people only saw their sites. Totals had to be rebuilt by hand in another sheet.

Each new year

A new spreadsheet every year. A returning person's history and past notes stayed in last year's file.

Roster changes

Moves, drops and new enrollments were edited by hand. After a move to another site, the old data sat in a different spreadsheet.

Reports

Each report could only use what was in one sheet, so combining visits, deadlines and referrals meant copying data around.

Solution

One system built around how the work runs

Each fix answers one of the four problems, in the same order.

Access by site

Each person sees only their assigned sites. Totals across sites are calculated automatically.

One record across years

Returning people come back with their history and past notes.

Roster import and dated moves

The record follows the person from site to site.

Connected data

8 reports combine visits, deadlines, referrals and notes in one click.

See it in action: compliance at a glance

Everyone must be screened within 90 days of enrolling. The app works out each deadline and flags who is close.

Screening compliance report

Person	Enrolled	90-day deadline	Days left	Status

Recreation with invented sample data, as of Oct 1, 2026.

Process

Three decisions that shaped the build

Building it surfaced three problems that needed more than code: one about access, one about history, one about privacy.

01Each person sees only their own sites

Consultants should only see the sites they are assigned to. A check of the first version found a gap: someone with no assignment could see every site.

ReportedThe fix was reported as complete.

CheckedA re-check showed only half was. An unassigned user could read all three sites.

FixedOne global access check that traces every request back to its site.

Break the 90-day rule on purpose4 tests fail

Disable the site access check2 tests fail

A test that passes against broken code isn't a test. When building with AI, checking the claim is the job.

02History stays with the person

In spreadsheets, a new year or a move meant a new file, and past notes stayed behind. The app keeps one record per person and adds each year and each move to it. Try it:

Start a new year: Sample 014 returns and moves to Site BSample data

Spreadsheets · a new file every year

App · one record per person

Person Sample 014

Person

Who they are. Never changes year to year.

Enrollment

One per year. Deadlines attach here.

Placement

Which site and group, from which date. A move is recorded, not overwritten.

This design came from asking how often people return or move mid-year. The answer was "often," which the code could never have discovered on its own.

03A notes box that keeps sensitive details out

Consultants write visit notes, and policy allowed names but not birthdays, addresses, contact details or other sensitive personal details. Blank text boxes invite exactly that, so the box itself guides what to write.

The visit log, before and afterRecreated, simplified

Before · two boxes, no guidance

Discussion with group A

Discussion with group B

After · one guided box

What was discussed today

Keep it general — the themes you worked on, not personal or sensitive details. Anything about one person belongs on their own record.

You can't validate your way out of a free-text field. The label and placeholder are the privacy control.

Also in the build

Roster import, made to survive real files

✓Clear error when no site is selected✓Excel's CSV file type✓Stray commas✓Duplicate name columns✓15 date formats✓Pre-import checker

Built inside firm boundaries

No link to the company loginNo cloud resourcesSecrets never committedLogin built from scratchAccess revocable instantly

Stack

Python · FastAPI · SQLiteReact · TypeScript · TailwindDocker · Railway

How AI fit in

AI wrote much of the code. The decisions that shaped the system came from knowing how the work runs: people move mid-year, deadlines recur every year, names are allowed but sensitive details are not. My job was to supply that context, decide what to build, and check that what was reported as working actually worked.

Results

Where it stands

Deployed as a pilot. These are the known limits to work on next.

No migration tool (team decision)SQLite, fine at pilot scaleEmail invites pending DNS setupSingle sign-on on holdStable IDs not yet confirmed with IT

Visit log: one guided notes box that keeps sensitive details out

User access: admins assign each consultant to the sites they cover

Tracking sheet: services and sessions by person and month, from connected data

One record per person: deadlines, services and session history in one place

What I learned

← All work

Product I built · Small business

Café Reservation System

A café handled reservations across four channels (a Google Form, a calendar, a seat chart and phone calls), and staff dug through submissions to confirm or change bookings. I ran discovery with the owner and staff, prioritized with RICE, prototyped in Figma and built a bilingual web app with AI that works on phones and iPads.

My role: Product owner, designer and builder
Users: Owner, staff and customers
Tools: Figma, Google AI Studio, Canva
Status: Tested and ready to launch

4 → 1Channels into one dashboard

4 → 2Steps to confirm a booking

From four channels to one dashboard

Before

Bookings spread across four channels. Every change meant checking each one by hand.

After

Every booking in one dashboard
Confirm in 2 steps instead of 4
Monthly report: busy days, regulars, no-shows
Chinese and English, on phone and iPad

Customer side: home, add-to-home-screen guide, booking, menu and calendar

Customer side: home, add-to-home-screen guide, booking, menu and business calendar

Staff side: seating chart and bookings, business hours, menu manager and settings

Problem

Every booking change meant four channels

Staff found each request in a Google Form, checked the calendar and seat chart, called the customer to confirm, then updated the calendar again.

Before · 4 channels

Find the request Google Form
Check availability Calendar & seat chart
Confirm with customer Phone call
Record the change Calendar & seat chart

After · 1 dashboard

Open the request Dashboard
Confirm Dashboard

Simplified. Every booking change touched the form, the calendar, the seat chart and a phone call.

Key design

What made the cut

Impact for staff →

High impact · low effortBuilt: Reservation central dashboardBuilt: admin managing reservation tools

High impact · high effortSkipped: POS integration

Lower impact · low effortBuilt: menu in booking flowBuilt: business calendar in the app

Lower impact · high effort

Low effortEffort to build →

Simplified view of the RICE trade-offs. POS integration was cut on purpose: the café already runs a well-developed POS across kitchen, drink bar and service, with its own sales reports. Connecting to it would add complexity without solving the booking problem. The business calendar stays on Instagram and now also sits next to booking in the app.

Design decisions

Each choice came from how the café actually runs.

A web app saved to the home screen

Why: A store app means review, fees and updates the café would have to maintain, and customers would need to download it first.

How it works: One link opens in any browser. A 3-step guide shows customers how to add it to their home screen, so it opens full-screen like an app.

A Chinese / English toggle

Why: The café has many foreign customers, who couldn't easily use a Chinese-only booking form.

How it works: One tap at the top switches booking, menu and calendar to English.

Designed for phone and iPad

Why: Customers book on their phones, and staff manage bookings on a phone or iPad.

How it works: Layouts adapt to each screen size, so the same app works for both.

A monthly report export

Why: The owner had no easy way to see patterns across a month.

How it works: Staff export the month's reservations to spot the busiest days and times, frequent customers, and no-shows.

How I built it

From discovery to a tested app

Discover

Talked with the owner and staff about how bookings came in and what slowed them down
Walked through a booking change across the form, calendar, seat chart and phone
Found the real bottleneck: not taking bookings, but checking availability and confirming changes

OutputPain points and booking workflow

Define

Listed every feature request and scored each with RICE
Kept one dashboard, admin tools and the menu in the booking flow
Cut POS integration, since the existing POS already covers orders and sales reports

OutputPrioritized scope

Design

Prototyped the customer and staff screens in Figma
Walked the owner through the prototype before writing code
Designed the language toggle, the home-screen guide and layouts for phone and iPad

OutputFigma prototype approved by the owner

Build

Built the web app with AI in Google AI Studio
Added the seating chart, business hours, menu manager and monthly report export
Put the business calendar in the app, next to booking

OutputWorking bilingual web app

Test

Tested booking, confirming and changing reservations on phones and iPads
Checked both languages and the add-to-home-screen flow
Iterated on feedback from the owner

OutputTested and ready to launch

What I learned