A complaint should become a traceable public record—not another message lost across channels.
The feature was designed for the iNews website so users could publish complaints about products, services, applications, websites, or other company-owned offerings, then interact through likes, dislikes, comments, sharing, reporting, and bookmarks.
Core proposition
Public visibility creates accountability, while structured interaction keeps the complaint useful after publication.
Challenge
Complaint channels were fragmented, responses were slow, and users had little visibility after submitting an issue.
Goal
Create a clear publication flow that supports discovery, evidence, public discussion, and follow-up.
My responsibility
Question Mark, Home, Complaint Detail, Write Complaint, and Notifications.
Team collaboration
A second designer handled Bookmark, Edit Profile, and the Profile Dashboard.
Tools
Figma for interface design and FigJam for flows, prioritisation, and information architecture.
Project boundary
The internship report covered design, prototyping, and usability evaluation—not production deployment.
Designed complaint journey
Publish
Turn the issue into a complete, structured story.
Make visible
Place the complaint inside a searchable news environment.
Build discussion
Connect support, comments, sharing, and reporting.
Follow progress
Keep updates and account activity easy to revisit.
Research replaced assumptions with evidence about where complaints break down.
The research combined a 136-response Google Forms survey, four selected interviews, and brainstorming. The survey mapped behaviour at scale, while the interviews explored interests, influences, goals, expectations, motivation, and pain points in more depth.
136
survey responses
Quantitative baseline collected through Google Forms.
89%
interested in the feature
121 respondents wanted a public complaint feature in online news.
91.2%
wanted an open response
124 respondents were more interested when the related party could reply publicly.
78.7%
valued similar cases
Respondents felt helped when they could find complaints similar to their own.
Where people submit complaints
Social platforms led because they were public and easy to access.
Where people search for similar cases
Discovery also happened outside official service channels.
Participant profile
Broad survey, focused interviews.
The survey included readers across age groups, professions, and locations. The largest groups were people aged 18–24, Tangerang residents, and students. Four respondents were then selected for deeper interviews, producing different perspectives from students, a private employee, and a civil servant.
36%
aged 18–24
49 respondents
49.3%
lived in Tangerang
67 respondents
33.1%
students
45 respondents
Five recurring problems became a focused product direction.
Survey and interview findings were organised into pain points, needs, expectations, and solution ideas. The goal was not to implement every suggestion, but to connect each design decision to a documented user problem.
Select insight
Active insight
Users struggle to get a timely, useful response from the related party.
User need
Visible progress, clear responsibility, and a response they can trust.
Design response
Notifications, status tracking, public replies, and response-time cues.
Prioritisation
One feature system, three levels of commitment.
The original matrix compared priority with feasibility. The web version below keeps the decision readable without reproducing a dense board of sticky notes.
Build now
High value and feasible within the project scope.
Shape carefully
Important ideas that needed additional logic or design definition.
Future system layer
Useful directions deferred because they required operational or technical support.
The product was organised before screens were polished.
Eleven task flows mapped specific user actions, while the information architecture grouped the experience into discovery, complaint detail, publishing, and account management.
Four connected journeys
Selected task flow
Discover complaints
Outcome
Users can compare similar cases and avoid repeating information.
Information architecture
Four branches keep the experience understandable.
Instead of displaying the full architecture screenshot, this interactive map exposes one branch at a time. The complete original remains available as supporting evidence.
Five key screens explain the product without turning the page into an image gallery.
The supplied asset pack contains the wireframe evidence for Home, Complaint Detail, More Options, Comments, and Write Complaint. This section keeps one screen in focus and explains the design intent beside it.
Selected screen
Home
Balances complaint discovery with familiar news-portal content.
Most tasks felt very easy; the writing flow exposed the clearest product risk.
The report tested six prototype tasks with participants aged 17–25 who had complaint experience, matched the defined personas, used Android or iPhone devices, and represented different Indonesian regions. SEQ used a 1–6 scale, while severity used 1 as catastrophic and 4 as low priority.
5.5
average SEQ
Across the six detailed task results
5 / 6
tasks scored SEQ 6
Very easy for the participant
2
priority issues
Mobile sharing and complaint form resilience
Selected task
Home
The welcome page and discovery content were completed without a meaningful obstacle.
Mobile sharing
Finding
The auto-generated Instagram Story template worked better on desktop than mobile.
Recommended iteration
Create a mobile-specific composition and test the export path on actual devices.
Draft protection
Finding
Leaving the write page could erase completed fields.
Recommended iteration
Autosave a local or account-based draft and warn users before destructive navigation.
Form clarity
Finding
The complaint form felt confusing to the participant.
Recommended iteration
Reduce cognitive load through field grouping, progressive steps, examples, and visible completion status.
06 · Reflection
The strongest design decision was turning a complaint into a connected lifecycle.
The project connected research, prioritisation, information architecture, writing, public interaction, personal management, and usability evaluation. It also showed that adding more features is not enough: the submission flow must protect user effort, and media-sharing behaviour must be tested on the device where it will actually happen.
Evidence before interface
Survey and interviews established the real behaviour and expectations behind complaint publishing.
Scope before decoration
Prioritisation separated feasible, important features from ideas that needed operational support.
Testing before confidence
The form and mobile-sharing issues were visible only after participants completed realistic tasks.