I turn complex workflows into clear, human experiences.
I'm Utik, a product designer working on CRM, internal tools, and operational products. I like the messy middle of a system: the handoffs, statuses, and rules that decide whether a product feels clear.
Selected work
Three projects, three kinds of problems: a multi-owner service, a dense internal tool, and a product built for my own team.
Kawan Nusa Referral Portal
One transparent referral journey across six Nusanet products, from member registration to approved points and reward fulfillment.
Customer Search, with ticket context
Bringing open tickets and recurring issues into the search results of our internal information system, so teams stop opening customers one by one.
Nusa Project Task
A lighter issue tracker for my product team, taken from "sprints keep clashing" to research, PRD, and a working prototype with real data.
Designer by craft. Problem-solver by nature.
Eight years in design, three in product. I take ownership from uncovering user needs to shipping purposeful, polished solutions.
Architecture taught me to see systems. Visual design taught me to care about craft. Product design brought both together. I work best early and close to product and engineering, keeping decisions visible through flows, prototypes, and states.
S1 Architecture
S2 Management (Marketing)
Adobe Certified, 2019
- 2021 — nowProduct DesignerNusanet · PT Media Antar Nusa
- 2019 — 2021Creative DesignerSrijaya Holiday
- 2016 — 2018Creative DesignerMarlis Energi Abadi
- 2015Assistant ArchitectAsina and Associates
Let's make the complex feel simple.
Open to product design and product roles, in Indonesia or remote.
Kawan Nusa Referral Portal
One transparent referral journey, from member registration to customer validation, approved points, and reward redemption, for members and the internal teams behind them.
One connected journey for members and internal teams.
Kawan Nusa supports referrals across the Nusanet product ecosystem. The redesign brought registration, referral tracking, points, rewards, education, and operational review into one experience, with clear ownership at every step.
- Mapped the end-to-end service and status lifecycle
- Reorganized dashboard information and navigation
- Designed member, approver, admin, and marketing flows
- Aligned edge cases and states with product and engineering
One lifecycle, many owners, no shared sense of progress.
Members could submit referrals, but knowing what happened next depended on manual follow-up. Behind the scenes, registration review, customer validation, point input, approval, and reward fulfillment were separate activities with separate owners.
The missing piece was not a feature. It was a consistent status model connecting member actions with internal decisions.
Members needed manual updates. Internal teams couldn't easily see what was waiting, who should act, or which status was final.
Following the work, not only the screens.
Instead of treating each screen as a separate request, I mapped who owned each decision and what information had to move between roles.
Workflow observation
How registrations, referrals, points, and rewards moved between owners.
Stakeholder talks
Sales, marketing, accounting, approvers, and administrators.
Information audit
What members need for confidence vs. what teams need for action.
Prioritization
States and handoffs that caused the most manual clarification first.
Eight stages, every handoff visible.
Each crossing between lanes is a moment where ownership changes and a status has to explain itself.
Four decisions that made progress readable.
Approval states with clear consequences
- Issue
- A rejection and a request for correction felt like the same dead end.
- Decision
- Registration review separates Approve, Request revision, and final Reject. A revision reopens editable fields; a final rejection locks the submission.
- Result
- Applicants know whether to wait, revise, or stop.
Every status gets an owner
- Issue
- A "pending" label didn't say who needed to act.
- Decision
- The dashboard is organized around the questions members ask most: where are my referrals, what have I earned, what changed, what can I get, how does it work.
- Result
- The first screen supports quick orientation, not a wall of metrics.
Points as a lifecycle, not a number
- Issue
- Members couldn't follow points from input to approval and availability.
- Decision
- Pending, approved, and active points are distinct states, with a history that shows why a balance changed.
- Result
- Members gain confidence while accounting keeps approval control.
Redemption as a trackable order
- Issue
- Selecting a reward didn't communicate approval, fulfillment, or completion.
- Decision
- The flow covers catalog, point cost, submission, approval, and fulfillment, for both physical goods and vouchers.
- Result
- Members can track a reward well past the redeem tap.
A shared model both sides can use.
Clearer progress
Statuses say both the current condition and what happens next.
Stronger ownership
Approvers, admins, marketing, and accounting have clearer responsibilities in the flow.
Connected value loop
Referral activity, approved points, and rewards read as one journey.
What I learned
- Map operational ownership before designing member-facing status labels.
- Design revision and rejection as different experiences, not different words.
- Treat rewards as fulfillment workflows, not catalog transactions.
Collaborated with product, engineering, sales, marketing, accounting, approvers, and administrators.
Customer Search, with ticket context
Customer Search, with ticket context
Support teams had to open customers one by one to learn whether anything was wrong. I redesigned the search results so open tickets, ticket history, and recurring issues show up in the list itself.
A search table used all day by internal teams.
Our internal information system is used by the teams who serve customers, not by customers themselves. Its Customer Search returns a table with name, company, installation address, service, phone, and email, plus column toggles and a status filter: Active, Block, Not Active, Free, and No Service.
The company runs two systems: the current IS and a newer IS platform that pages are gradually moving to.
The answer was always one click too deep.
Stakeholder feedback was direct. To know whether a customer had a ticket, or whether their service was up, users had to open each customer's detail page one by one.
Turning a column request into a working model.
One 30-day count, two sources
- Question
- Should the count include only customer tickets, or network (NOC) incidents too?
- Decision
- Combine customer/CS tickets and impacting NOC tickets in one 30-day count, but separate them visually. Add the age of open tickets and an indicator when one is past SLA.
- Result
- One glance shows how much trouble a customer had, and where it came from.
Define "recurring" so the system can count it
- Question
- "Aware of recurring issues" is a feeling. What does the system flag?
- Decision
- A recurring issue is the same ticket title appearing two or more times within 30 days.
- Result
- A clear rule engineering can build and users can trust.
Keep live service status out of scope
- Question
- Users also asked "is the service up?" Should the table show it?
- Decision
- Not yet. Whether live up/down data is available hadn't been confirmed, so I didn't design a column the system might not be able to fill.
- Trade-off
- The service-status question is only partly answered in this release.
Columns are a budget
- Question
- The request was to drop Email. What else changes when two columns are added?
- Decision
- My first proposal kept Email as an optional column and merged contact details into one. In the final review, Email and Vendor CID stayed as default columns, and filter conditions moved into an Advanced filter panel.
- Result
- New ticket columns without losing the lookups people rely on.
Design once, ready for two platforms
- Question
- The page might stay on the current IS or move to the new platform.
- Decision
- I designed two versions of the same page: V1 in a neutral custom style for the current IS, and V2 in Material 3 for the new platform.
- Result
- The design is ready wherever the page ends up.
Advanced filter for the questions teams actually ask.
Status chips stay one tap away. Everything more specific moved into one panel, so teams can find, for example, every active customer with open tickets and repeated trouble this month.
Advanced filter
2 activeNeutral, custom styling that matches the existing system.
Material 3 components, used if the page moves to the new platform.
The list now answers the first question.
- Open tickets are visible and clickable from the results, with age and an SLA indicator.
- A 30-day ticket count combines CS and NOC tickets, shown separately.
- Recurring issues are flagged by a rule the system can compute.
- An Advanced filter covers account status, ticket ranges, and package.
- Two platform-ready versions of the same design.
What I'd carry forward
- Treat a column request as a question about the whole table.
- Confirm data availability before designing around it.
Nusa Project Task
Nusa Project Task
My team kept clashing with sprints and with Jira. I took the problem from "how should we work?" to research, a PRD, a design spec, and a working prototype with real, saved data.
A small product team with a big-team tool.
I work on BIS (Business Information System), a team inside the Product Management division: a PO/PM, a head engineer, five product engineers who now all work full-stack, three product designers, and an assistant to the VP of Tech who filters feedback and builds reports.
We worked in sprints, and the method kept clashing with how work actually arrived. The tool we used made that friction louder.
Before designing a tool, I questioned how we work.
A better tracker for a method that doesn't fit only speeds up the wrong thing. So I first explored four ways of working, each with ideas for tools across teams.
Two-lane board
Separate lanes for planned work and incoming issues.
Shape Up
Fixed-time cycles with shaped, bounded work.
Team Topologies
Team boundaries organized around flow of work.
AI agent layer
Agents that help triage, summarize, and report.
What the team actually needed.
I based the first version on desk research into common Jira pain points and on personas drawn from our own team. This was not interview data, and I wrote it that way in the research synthesis.
Track issues
With story points on every issue.
Own the issue types
Task, story, idea, bug, or whatever the team defines.
Run sprints lightly
Set start and end dates, no ceremony required.
See progress
Reports and a burn chart.
Find related work
Filters to pull up connected issues fast.
Fit every role
Engineers, designers, managers, and product owners.
Small on purpose.
Issue types belong to the team
- Issue
- Fixed taxonomies force work into categories that don't match how a small team talks about it.
- Decision
- Teams define their own issue types, starting from task, story, idea, and bug.
Quiet by default
- Issue
- Busy trackers make the important thing hard to see.
- Decision
- A simple, clean, modern interface that isn't crowded. Green as a light accent, and both dark and light modes from day one.
Real data, not a demo
- Issue
- A clickable mockup proves a layout, not a workflow.
- Decision
- The prototype saves data permanently, so a small team can actually use it.
Ship the smallest useful v1
- Decision
- React + Vite + Tailwind + Recharts with shadcn-style components, targeting Vercel. Version 1 stores data locally with no login.
- Trade-off
- No accounts or sync in v1, in exchange for something the team can try right away.
From problem to code in one pass.
Every artifact a team needs to pick it up and keep going.
What comes next
- Validate the desk-research assumptions with the team using it.
- Add accounts and sync once the workflow proves itself.