Case study
Enjin.world
Rebuilding a career platform for bilingual students and professionals in Tokyo. Sole designer on the 2023 revamp.
Summary
- Background
- A bilingual career platform in Tokyo, running three services (Career, Forum, Community) under one product.
- Problem
- Users signed up but never came back, and no analytics said why.
- Approach
- User research (interviews), then rebuilt the IA as the solution.
- Outcome
- User task-tested, feedback confirmed success.
Context
Enjin was a startup based in Tokyo, building a career platform for bilingual students and professionals in Japan. It ran as an offshoot of JAPI, a network of 219 partner organizations across 120 countries that the CEO came out of. Distribution was partnership-driven through that network, with offices in Shanghai, Hanoi, Jakarta, Yangon, and Mumbai. The product, enjin.world, ran three features: a job board (Career), a Q+A space (Forum), and a networking feed (Community).
I joined in 2020 while still transitioning from graphic design into UI/UX. The first version of the interface was an early collaboration between me and another designer on that same journey. By 2023, with more practice and fresh research, I owned the full revamp. This case study is about that second version.
In the absence of a PM, I drove prioritization and scoping in partnership with the CTO, who doubled as product owner. Two design interns supported earlier phases of the work. The dev team reported to the CTO.
Problem
The site had users. It did not have active users. People signed up and did not come back to apply, post, or participate. Engagement was thin, and we had no instrumented analytics to identify where people dropped off or why.
The brief was to find out why, with qualitative evidence as the only tool available.
Research
I ran twenty 1:1 semi-structured interviews with active and lapsed Enjin users, recruited across the three services, plus focus groups with five users and two non-users for comparative perspective. Sessions were roughly 45 minutes, recorded with consent, and synthesized via affinity mapping into themes.
Three themes consistently emerged:
Architectural confusion. Users felt overwhelmed and didn't know where to start. The flat tab strip put Forum, Career, Community, and Messages at equal weight, with no anchor or primary purpose. Most couldn't tell what Enjin was primarily for, so most didn't form a habit around it.
The clearest expression of this was the unified Messages inbox. Career replies from recruiters, Forum responses from strangers, and Community DMs from friends all stacked into one stream. A job rejection could land directly beneath a casual ping about coffee. Users had no way to switch register between three relationship types, and high-stakes recruiter messages drowned in social noise.
Familiarity gravity. When asked which sites they actually used for job hunting, LinkedIn and GaijinPot dominated. For social, Facebook and Instagram. Their habits set the interface expectations we were not meeting.
Visual fatigue. The original orange-green palette was the most-cited surface complaint, signaling "early stage" in a market where Indeed Japan and LinkedIn set the polish baseline.
Research made it clear what was broken, not how to fix it. The architecture moves came from reasoning and from how LinkedIn, Facebook, and Reddit handle similar problems. With no analytics and no budget for separate IA studies, testing each decision upfront wasn't an option. I tested the integrated redesign with users at the end.
Decisions
Split the architecture, not the navigation
The pivotal call. Career, Forum, and Community served three different intents: goal-directed job hunting, Q+A browsing, and social networking. Stacking them in one navigation forced users to switch mental models on every screen, which mapped directly to the Architectural confusion theme from research. I separated the three into distinct experiences and handed cross-service switching to the burger menu. Each service got its own contextual messaging surface, dissolving the unified inbox that had been mixing recruiter replies with friend DMs. Daily use became single-context. Moving between services became a deliberate action, not an accidental tab click.
Borrow patterns users already knew
Comfort comes from familiarity. I borrowed interface patterns from the two sites users habitually relied on: LinkedIn for the job browsing and profile flows, Facebook for the community feed. Less orientation time meant more time spent on the content itself.
Cut the visual noise
The original orange-green palette was the single most cited complaint in interviews. I replaced it with teal and off-black, added whitespace, and gave each service its own mark: a staircase for Career, an infinity loop with speech bubbles for Forum, a speech-bubble cube for Community. The sub-brand marks did the wayfinding work, cutting orientation time on every screen.
Architecture
The split surfaced in the navigation. One flat tab strip serving all three services became three separate experiences, switched via a top-left menu and each focused on what users actually came there to do.
The burger menu in each service's top-left switches between Career, Forum, and Community. Each switch lands users in a single context, never in a flat tab strip.
One unified inbox became three contextual Messages surfaces. Career carried recruiter threads. Forum carried follow-ups from people who answered users' public questions. Community carried friend DMs. Each Messages tab kept the relationship type it actually served, instead of mixing all three into one stream.
Deliverables
Three distinct service experiences for Career, Forum, and Community, connected by a burger-menu switcher for cross-service moves. Mobile-first responsive layouts across all three. Three sub-brand marks and a unified type and color system. A component library covering every repeated pattern, from button states to data tables. On the side: a product explainer animation (After Effects, own voiceover) and bilingual B2B brochures and event standees for the recruiting circuit.
Outcome
Without product analytics, I validated the redesign with task-based usability testing. Five users who had used the original platform, drawn from prior study participants and current Enjin users, completed task instructions across the new flows, followed by a short interview. All five completed the tasks. All preferred the new design over the original.
Reflection
My biggest lesson from Enjin: I should have pushed for analytics on day one. The interviews set the right direction and task-based testing proved the rebuild worked, but I could never show a hard before-and-after dataset, and I committed to the new IA without a tree test to back it. Now in my projects, tracking goes in during week one, and I don't ship an IA change without validating it first.
