Employee Communities: Find, Join & Create

My contributions

Employee Communities gives people a place to find, join, and create communities inside their organization — spaces built around a shared interest, team, or cause, where they can post, run events, and manage members. I joined mid-project as a co-designer, while the requirements were still high-level, and took ownership of the employee-facing experience end to end — how people join a community, and how they create one.

My job was translation: turning early, incomplete requirements into complete flows a team could build. I resolved the open questions around states, entry points, and the empty-state create experience, all within Oracle's Redwood design system. The flows I defined shipped as V1, and I've stayed on the product as it's grown.

Information architecture

With the team, I helped map the information architecture — how an employee moves from their entry points (the Communications & Events Hub, Connections, and Search) into a community, and out to everything it supports: posts, events, member management, registration, and HR messages. It's what keeps the space coherent and findable as it grows.

A place for employees to find their people

Big organizations are full of groups that never quite find each other — people who share a role, an interest, or a cause. Employee Communities gives them a home inside the HCM platform: somewhere to discover communities that fit, join in one action, and create a new one when it doesn't exist yet. Since it lives inside tools people already use for work, it had to feel native to that environment — but inviting enough that joining felt like a choice, not a task.

The challenge: a new space, a fuzzy brief

I joined to help a team that needed another designer, in a product area I hadn't worked in before — so I was learning the domain and the in-flight project at once. The early requirements described what the product should roughly do, not how it should work: no settled flow for joining a community, and no defined path for creating one.

That meant getting oriented fast, asking the questions no one had answered yet, and making decisions while still learning the space — turning ambiguity into something buildable instead of waiting to feel like an expert first.

Starting point: the PM's user flow

My PM gave me a user flow mapping the logic — the creation path (gated by creator privilege) and the non-member journey of finding a community, reviewing it, and joining. I took that as my input and translated it into resolved states, entry points, and the actual screens employees would move through. Here's that logic, redrawn.

Who I designed for

Every decision traced back to two employees with different intentions. The join flow serves one, the create flow serves the other — and keeping both in view is what kept the experience grounded.

Two journeys: join and create

The experience came down to two journeys, one for each goal. I designed each as a complete path — including the states the original requirements hadn't accounted for.

The create flow was the harder of the two. It meant designing from an empty state and giving an everyday employee — not an admin — enough structure to stand up something new without overwhelming them. That balance is where most of the ambiguity lived, and where most of my decisions got made.

Designing within Redwood

Here the constraint was the point: every screen had to live inside Oracle's Redwood design system. The work wasn't inventing components — it was composing existing patterns into a new experience the system didn't have yet, while keeping it consistent with everything else employees use.

Outcome & what's next

The flows I defined shipped as the V1 employee experience, and I've stayed on the product as it's grown. I'm now designing a polls feature for Employee Communities — a lightweight way for members to gather input and spark participation, extending the experience I helped define into a new kind of interaction.

The project sharpened one strength in particular: a lot of design value gets made before the first polished screen — in taking a vague requirement, in an unfamiliar domain, and deciding what it actually means. Getting oriented fast, asking the right questions, and making decisions in ambiguity, all inside a strict design system. It's the combination enterprise teams rely on, and the one I lean on most today.