grounded in user research. every design decision traced to a finding.

TechRise is a student-focused platform with two core jobs: help students book advisor appointments and surface relevant internship opportunities. the product had real utility on paper. but engagement was low, and the team had a hunch the interface was the reason.

i came in to diagnose whether that was true and if so, where exactly the experience was breaking down.

my role was scoped as UI/UX but the engagement required PM work from day one: diagnosing the real problem, running research, making prioritization calls, and owning scope decisions through handoff.

before touching anything, i needed to separate the symptoms from the real problem. the app being "cluttered" was a description, not a problem statement.

this reframe mattered because it shifted the design goal. the question wasn't "how do we clean this up?" it was "how do we make the highest-value actions feel effortless and fast?"

i ran 6 user interviews and distributed a survey to 40+ students to understand where the friction was coming from. i recruited through the TechRise user base directly. i also did a competitive teardown of advisor booking and internship tools to understand what the bar looked like.

user interviews: recurring quotes:

• "it's hard to find advisors that have time to help me."
• "by the time i find the posting, it's too late to apply."
• "switching between different platforms for internship postings gets frustrating."

the interviews kept surfacing the same two pain points: advisor availability was invisible until you were already deep in the booking flow, and internship deadlines weren't visible until you opened each posting individually. those two findings shaped everything downstream.

survey data:
competitive analysis takeaways:

• existing advisor booking tools are functional but built for admin convenience, not student speed
• Handshake has volume but weak filtering; students waste time before finding relevant postings
• common theme: students value speed and clarity over feature richness. this informed a direct decision: surface advisor availability at the browse level, and move deadlines to the card level. both were zero-engineering-cost fixes via information hierarchy alone.

Problem	Severity	In Scope?	Rationale
Confusing navigation / IA	High	✓ Yes	Root cause of most friction
Advisor availability not visible	High	✓ Yes	Directly impacts core use case
Internship deadline visibility	High	✓ Yes	Zero-cost fix via info hierarchy
Notification system	Medium	Future	Backend dependency
Cross-platform aggregation	High (complex)	Future	Out of sprint feasibility

the call to scope out notifications and integrations was deliberate. trying to solve everything in 4 weeks would have compromised the structural redesign.

each decision maps directly to a finding from research. nothing in here was a taste call.

i mapped the three core user flows before touching UI: booking an advisor, finding and applying to an internship, and tracking active tasks/deadlines.

• restructured navigation hierarchy: 50% of surveyed students found the interface confusing. the root cause was too many top-level items with no clear hierarchy. reduced nav items and moved highest-frequency actions to persistent nav.
• advisor availability surfaced on browse: 60% of students struggled to book appointments. the friction was that open slots weren't visible until 4+ taps in. surfaced availability in the directory view, reducing booking to 2 taps.
• deadline prominence on internship cards: "by the time i find the posting, it's too late to apply" was the most consistent interview quote. moved deadlines from the detail page to the card-level summary so students see them before clicking in.
• task tracking simplified: students were getting stuck on complexity, not lack of features. categorization reduced to three buckets (to-do, in progress, done) based on what students actually described doing with tasks.

• redesigned navigation and information architecture across student-facing screens
• new advisor booking flow: reduced steps, availability visible upfront
• internship board with deadline-forward card design
• simplified task tracker with three-state categorization
• advisor-facing UI variant for future engineering use

designs were handed off to Francis Ganya and implemented in the live TechRise app. active usage grew from ~25 students to 156 following the redesign, a 6x increase in the months after handoff.

trace is a conversational reminders iOS app. users talk to it naturally, and it handles the structure. i'm the cmo, working alongside arhaan keshwani, joey zhang, and nina kilidzhiyska.

we had a working product but no visual language. no logo, no typeface, no defined way to show the app to people. that wasn't a design gap, it was a launch blocker. without a locked brand system, we couldn't run paid ads, build the app store listing, or post consistently. every downstream asset was blocked until these decisions were made.

i owned the brand system end-to-end: scoping the decision set, driving alignment, and shipping a visual language the whole team could build on, in one week, with no design budget.

constraint	detail
timeline	1 week
budget	$0
team structure	async, gc-based feedback
design resources	sole designer

without a shared visual system, every asset we produce reads as disconnected, and we can't run ads, publish consistently, or submit to the app store.

three decisions were blocking everything downstream: logo, typeface, and product display format. until those were locked, nothing was repeatable or scalable.


that scope boundary kept the team focused and the timeline intact. it also gave us a clear definition of done: three decisions locked, all downstream assets unblocked.

the filter for every option wasn't "does this look good." it was "does this give trace a mark it can grow into without explaining what the product does."

the only alignment we had going in was that we wanted the brand to feel simplistic. the first logo attempt was a glowing abstract waveform mark: white on black, soft-edged, radiating outward. it looked striking in isolation but immediately read as too complex and too heavy. it didn't feel like trace.


that reaction was useful data. it told us what we didn't want and gave us a clearer direction to move toward. from there, the team moved toward a geometric mark, but i pushed back: without a brand identity established yet, something that abstract gave no signal about what trace actually did. i suggested the voice memo waveform direction and put together multiple variations to pressure-test it.

we ran those variations by a small group of users. the feedback was positive on clarity — people understood the voice connection — but the more the rest of the brand system developed, the less the logo needed to do that work. the font and product displays were already communicating the product. that shifted the decision criteria: if the rest of the system carries the message, the logo just needs to be a mark worth owning.

option	rationale	user feedback	verdict
glowing waveform mark	too ornate. contradicted the simplistic direction we had aligned on	not tested; cut before feedback round	cut
voice memo waveform (multiple iterations)	cleaner, referenced the app's core voice interaction directly. tested multiple variations	positive on clarity. users understood the voice connection. but felt too literal once the brand system developed	cut
abstract hexagon mark	geometric, clean, distinctive. not tied to any single feature, giving trace room to build its own identity around the mark over time	tested well with team once brand system was established. logo didn't need to explain the product	chosen

final thoughts: the voice memo iterations were a necessary middle step. they clarified what the logo needed to do, and then helped us realize it didn't need to do as much as we thought. that freed us to go fully abstract. the hexagon mark is simple enough to sit small without losing its shape, and flexible enough to grow with the brand.

the filter: find the middle ground between minimalist and personality-forward. something that sells the product to a stranger without overexplaining it.

the team's instinct was to go fully minimalist. i pushed back on that from a user acquisition standpoint: minimalism alone doesn't sell a product to someone who's never heard of it. trace needed enough personality to create a first impression. the question was how much.

we anchored off the font already on the trace website (a clean sans used for body), then focused the search on a display face that could carry the wordmark and headers.

option	notes	verdict
website serif (first suggestion)	too corporate. wouldn't sell the product to a consumer. flagged and cut early	cut
satoshi medium	clean geometric sans. not enough character for what trace needed at the wordmark level	cut
satoshi black italic	too heavy. didn't match the simplistic direction	cut
coolvetica rg	rounded and informal but read too elementary for the brand we were building	cut
apollo otf	editorial serif with real character. hit the middle ground between minimalist and playful. team aligned immediately	chosen

with apollo locked, we tested uppercase vs lowercase for the wordmark. uppercase read too formal and corporate. lowercase felt intentional and matched the conversational nature of the product. we locked in all lowercase.

the filter: does this format work as a repeatable template across social posts, paid ads, and the app store listing? if we couldn't reuse the same layout across all three surfaces, it wasn't the right format.

phase 1: pre-rebrand
the first attempts used a "hey trace" headline format with a single angled phone mockup on a light starburst background. the copy and layout were attention-grabbing but the visual didn't feel like the product. without the brand system finalized, nothing was anchoring it to trace specifically. i flagged this early: these assets couldn't go live until the brand was locked, or we'd be remaking them anyway.


phase 2: post-rebrand iterations
once the font and logo were locked, i rebuilt the product display around the finalized brand. the format shifted to a dark background with three angled phone mockups showing the app in context. this immediately felt more like trace. the team responded positively but it still took a few passes to get the hierarchy right.


phase 2b: incorporating feedback
after the initial iterations, two clear pieces of feedback came back: visual hierarchy needed work and the logo was missing. the wordmark was either too large and competing with the phones, or absent altogether, leaving the display unanchored from the brand. i took that feedback, brought the sizing down, repositioned the elements, and reintroduced the logo in a way that complemented the product shots rather than competing with them.


top choices
after evaluating the iterations against the filter (repeatable across social, ads, and app store), two formats came out on top. both balance the product, the wordmark, and the logo without any one element overpowering the others.

by end of week we had a working brand system: hexagon icon mark, apollo otf wordmark in lowercase, and a repeatable product display format.

more importantly, we unblocked everything that had been blocked:

• paid ad assets: first creative ready to run within 48 hours of brand lock
• app store listing: visual assets complete and submitted
• social posting: consistent template in use across all posts from launch week onward
• team alignment: brand decisions documented, no re-litigating on every new asset

the geometric precision of the hexagon paired with the editorial character of apollo reads as minimal but intentional. together they establish what trace looks and feels like before a single feature gets explained, which is exactly what a pre-launch brand needs to do.

partners incl. anthropic, equifax, adobe.

progsu went from a 10-person board with no working operating system to a 1,800+ member organization across four georgia campuses, anchored by hacklanta, gsu's first hackathon since 2017. the two decisions that mattered most: betting on one flagship event over continuing to grow through smaller ones, and the structural rebuild that let the org actually carry the volume that bet brought in. everything else below is what made those two calls possible, or what they cost.

progsu wasn't a new club. it had five years of real history behind it: founded in 2020, registered student org status by 2021, safc funding and full university partnership by 2023, a discord community that had grown past 1,100 members at its peak, six presidents across five years. on paper, it had legitimacy.

by the time joey relaunched it in summer 2025, the board was down to about 10 active people.

the assets were still there. roughly 30 google docs laid out structure, role titles, and where the club wanted to go eventually. the direction existed, technically. what didn't exist was a way to turn that direction into weekly output. joey put it plainly: the club had people who could execute and people who were creatively skilled, but no one setting the vision or allocating the work. it wasn't a talent problem or an awareness problem. it was a leadership operating system problem.

that distinction mattered for everything that came after. if the gap had been "we need more members" or "we need better flyers," the fix would have been tactical. it wasn't. the fix had to start with direction-setting and task ownership before a single event got planned.

the first move wasn't a flyer or a post. we needed a mission and vision statement before anything else got built. if you'd asked anyone on the board to pitch progsu to a stranger in one sentence, they couldn't do it, and without that, every other call — what to post, what events to run, who to bring in as sponsors — had no filter to run through.

the trade-off was real: every day spent on a mission statement was a day the board wasn't posting content or running events, exactly the momentum a freshly relaunched club needed. i made the call anyway, because momentum without direction would have just been busywork that didn't compound. joey drafted the actual statements; i pushed for them to exist first. the version that stuck: reignite the builder spirit at a commuter school with no flagship cs program, by winning on community and accessibility instead of prestige, since most existing tech-club playbooks were built for schools that had neither problem.

direction doesn't execute itself, though. the next problem was getting a small board to actually finish tasks on a deadline, and that took three tries:

attempt	what happened	outcome
notion	board had no prior familiarity with it	barely opened, work didn't move
trello + dedicated discord channel	pinged repeatedly, plus 1:1 follow-ups	still ignored; the 1:1s started to feel like surveillance to members
live google doc during weekly meeting + discord ping for follow-up	tasks assigned in real time, owner pinged directly post-meeting, expected to flag blockers themselves	output increased; some members still needed active guidance, but tasks started closing

the bottleneck was never the tool, it was adoption behavior. the system that worked was the one that matched how the team already communicated, not the one that looked most professional on paper.

the first real test of the relaunch was the fall kickoff, paired with a rock paper scissors tournament built for an expected 200 attendees.

going in, the proposed format was overcomplicated: three wristbands per person, a "gulag" bracket for eliminated players, multiple rounds, and four dedicated spectator roles. i flagged before the event that this would be too much for a room of tired, shy cs students to follow from a single explanation, but the team kept the original plan.

it broke down live, exactly as expected. the easy move would've been to let it limp through and fix it for next time. instead, mid-event, i made the call to scrap the format on the spot: 1v1 matches, winner takes the loser's wristband, most wristbands at the end wins. had the president announce the change immediately, no waiting for consensus first. from there it ran itself: people started finding their own opponents, the "spectators" pivoted to helping people pair up, and the room had one of its best nights yet.

two things changed permanently after that event: we built a tighter run-of-show before future events instead of relying on live fixes, and we made it a standing rule to always capture one strong, full-room photo, because a packed room with no proof of it doesn't do much for a club trying to convince people the relaunch was real.

after the kickoff, the team had grown but responsibility hadn't kept pace: marketing was 5 people, tech was 4, outreach was 3, with no clear lines between them. i led the rebuild on the marketing and outreach side; the overall structure was a joint call with joey and the board.

initial structure, post-kickoff

level	role	scope
top	president	sets vision, fills gaps everywhere
domain vp	vp marketing	owns content, growth, brand end to end
domain vp	vp tech & workshops	owns workshops & hack nights end to end
domain vp	vp startups	owns build nights & venture track end to end
domain vp	vp outreach	owns partnerships & sponsors end to end
shared ops	secretary / pm	docs, sops, handoffs
shared ops	finance	budget, reimbursements
shared ops	event coordinator	logistics, day-of execution

that held up at a couple dozen people. it didn't survive hacklanta. once the org hit 1,500+ members across four campuses, four flat domain vps couldn't carry the volume anymore, so we rebuilt a second time into a full c-suite.

scaled structure, post-hacklanta

domain	lead	vps	directors
tech & development	cto	vp of t&d, vp of programming	software dev, hacklanta, education
operations	coo	vp finance, vp of ops	finance, logistics, events
growth	cmo	project manager, vp of branding	content, podcast, design, analytics, community
relations & outreach	cro	still being staffed	still being staffed

the cadence scaled with it: one weekly sprint with the co-founders and the four c-suite leads keeps the org aligned at the top, then each function runs its own weekly sprint inside its own team.

by this point the club had momentum: regular workshops, a clear identity, growing membership, nonprofit status in motion. the next call was the highest-stakes one: keep compounding through small recurring events, or make a single, much bigger bet.

this one was a group call. the case we made together as a board: gsu hadn't run a real hackathon since 2017, and even that one underperformed against regional players like hackatl and hackgt. the only options on campus were small and exclusive. there was a clear, unclaimed gap — a flagship event that could pull in students beyond gsu and put the club inside the broader atlanta tech ecosystem instead of just the campus bubble.

build nights and workshops didn't stop for the sprint — if anything they mattered more: that existing programming doubled as hackathon prep, and the sponsor companies already showing up to build nights gave students an early shot at getting on a recruiter's radar before hacklanta weekend even started. five weeks, from scratch, to gsu's first in-person hackathon in nearly a decade.

five weeks also forced a real choice on where to spend the team's time. paid social wasn't a real option, so the actual trade-off was flyers against a built channel: we built a direct channel into cs classrooms instead — a professor database, a single outreach message the whole team sent and followed up on, and volunteers delivering a short prepared pitch in person, classroom by classroom. we don't have clean attribution data tying signups directly to those visits, but it was the only promotion channel running at real volume in those five weeks, and the hackathon still pulled 400+ hackers with zero track record behind it.

promotion for build nights never got the same discipline applied to hacklanta or the kickoff — no dedicated outreach push, no repeatable format, just a recurring event riding on whatever attention the brand had left over from bigger pushes. unlike the rps tournament or the ping pong table, there was no single live moment that forced a fix. it just slowly lost relevance.

looking at it now, the root cause is visible in the org chart itself: in the post-kickoff structure, vp startups owned build nights end to end. in the c-suite rebuild, that domain disappeared, and build nights never got reassigned anywhere. a program that loses its named owner during a restructure doesn't get killed on purpose — it just stops being anyone's job.

the fix starts there: give it an explicit owner in the current structure, point the classroom outreach channel that worked for hacklanta at it directly, and track week-over-week attendance as a leading indicator so a decline gets caught in two weeks instead of discovered at the end of a semester. it's still an open problem heading into next semester.

focus and retention led. speed was near the bottom.

pace started as ai smart glasses that highlighted words in real time, adapted to reading speed, and surfaced definitions, summaries, and translations in the lens. nine ai agents ran across three tiers: gaze tracking and ocr on the glasses, adaptive pacing and profiles on mobile, recaps and coaching in the cloud. it targeted students, professionals, and readers with dyslexia or adhd.

it demoed beautifully in a pitch. it was also a 5 to 7 year problem, not a summer one. custom optics, low-power edge inference, and a hardware supply chain each need a dedicated team. my hardware prototype budget was zero.

i separated the pain from the delivery mechanism. the reading problem was real and underserved. the glasses were me over-engineering the fix. killing the hardware did not invalidate the pain, so i kept the pain and went back to users.

original concept	detail
product	ai smart glasses (killed)
mechanic	real-time in-lens highlighting
architecture	9 agents, edge / mobile / cloud
timeline	5 to 7 years
hardware budget	$0
kept	the reading pain

research question	why it matters
where does reading actually break down for you?	isolates the failure mode: focus, comprehension, speed, or motivation
what do you do when you get stuck?	surfaces the workaround they already use or pay for
what have you read lately that you feel good about finishing?	defines what success looks like
what have you been meaning to read but keep avoiding?	uncovers the emotional layer: guilt, overwhelm
if you read twice as fast with full comprehension, what changes?	tests whether the pain has downstream stakes

targeted first: high-volume, high-stakes readers. grad, pre-med, and pre-law students, early-career analysts, engineers reading technical docs, and heavy readers who fell off.

40 interviews across 5 segments. 24 live conversations (17 in person, 7 video) and 16 async (10 direct messages, 6 forum threads), run as a minimum viable experiment. the metric was simple: a 1 to 10 pain score and a coded failure mode for every interview. 35 of the 40 were sourced cold through online outreach and referrals. five were warm contacts.

failure mode	interviews
focus / distraction	10
retention / memory	8
motivation / avoidance	8
comprehension	6
speed	6
other	2

focus and retention led. speed, the thing the glasses were built to optimize, was near the bottom. the evidence did not just refine the product, it pointed at a different one.

segment	avg pain (1 to 10)
pre-med / law	8.0
early-career analysts	7.4
undergrads	7.2
other	6.7
leisure readers	4.6

leisure readers scored low and had almost no problem. the pain lives in required, high-stakes reading, not reading in general. that cut the market to the people who actually feel it.

the retention illusion. "i highlight everything, close the textbook, and it's like i never opened it." passive tools feel like progress and produce almost no recall.

the tool is the problem. "i feel like i'm faking it." ai summaries were the single most common workaround, 8 of 40, and they backfired. users called them lossy and named real costs: a failed detail quiz, a production bug at work. the behavior the product has to beat is the one already hurting them.

the pain is specific. "i can fly through a novel in a weekend, but one 40-page case opinion takes me three hours." same reader, opposite outcomes. the problem is not reading ability, it is dense, required reading.

the insight the product is built on. "i've never once missed a book club deadline. if people are waiting on me, i finish." the same person hit near 100% completion on book club reading and near 0% on required reading. the only variable was social accountability and a deadline. that is a mechanic, not a feature.

the segment narrowed, the solution changed, and the reason got specific.

initial: students, professionals, and readers with dyslexia or adhd will buy ai smart glasses that adapt to their reading in real time, because dense reading is slow, hard to focus on, and hard to retain.

now: students and early-career professionals with high-stakes required reading will adopt an active reading companion, because passive tools fail them when retention actually matters.

in detail
segment	students and early-career professionals with high-stakes required reading
core problem	they complete dense reading through passive tools and retain almost nothing; the failure surfaces later, with real consequences
root cause	every existing tool is passive or replaces the reading; nothing verifies comprehension mid-read; ai summaries made it worse
mechanic	chunked guided pacing, a retrieval checkpoint after each section, and optional social or deadline accountability (the book club effect, built for required reading)
outcome	finish what you start, pass the detail-level test, stop feeling like you are faking it

what i am explicitly not building:

• another summarizer. it is the tool already failing them.
• a speed-reading gimmick. speed was the lowest-ranked failure mode.
• anything for leisure readers. they have no pain and will not pay.

the decision: continue testing. 16 of 40 scored 8+ on pain, so the problem is validated. willingness to pay and the winning mechanic are not, so committing to a full build now would be committing on faith.

open questions:

• willingness to pay. no pricing signal has been tested yet.
• which mechanic leads. retrieval checkpoints or social accountability. only a prototype can rank them.
• the forum channel. undersampled at 6 of a 20-response target.

next experiment: a two-week prototype test pitting retrieval checkpoints against accountability, run alongside a pricing smoke test.