Category: Uncategorized

  • Designing Lexica: Can Design Help People Do The Right Thing?

    Designing Lexica: Can Design Help People Do The Right Thing?

    Duration

    December 2023–July 2025 (1.5 years)

    Role

    Product Designer

    What is done

    Creating design system, creating accessibility guideline, prototyping, and testing

    Introduction

    As mentioned in my previous blog post, I decided to design a mobile-first contribution tool focused on lexicographical data (words, phrases, etc.) on Wikidata, now called Lexica. Through Lexica, I want to proof that:

    1. Good design alone can help users make high-quality contributions to Wikidata with less human error.
    2. A well-designed tool will be appreciated by contributors regardless of their experience levels.
    3. A Wikidata tool that feels similar to the Wikidata interface helps establish trust.

    This is all done by leveraging guardrails, purposeful limitations, and subtle aspects of gamification. Here’s how I did it.


    Understanding the challenge

    When approaching Lexica’s design, I wanted a solution that felt intuitive, made complex information understandable, and, most importantly, guided users to make better contributions.

    The tool’s priorities presented what initially seemed like fundamental contradictions:

    • Increasing both the quantity and quality of contributions
    • Increasing ease of use and reducing errors
    • Presenting curated and randomly-chosen Lexemes
    • Creating a native-feeling and fresh, innovative user interface
    • Being as simple as possible without hiding how Wikidata structures information

    Instead of viewing these contradictions as obstacles, I saw them as opportunities to create a new kind of user experience—one that helps users do the right thing without compromise.

    From the very beginning, Lexica has always been designed for less experienced contributors as the main audience. This means explicitly not allowing mass editing and automated editing. Other great Wikidata tools, such as QuickStatements, can handle such scenarios.


    Leveraging guardrails

    Editing in Wikidata can be daunting for many because there are so many things that can define a Lexeme. What needs to be added? Which section should the contribution be placed in? What values can be included? And most importantly: what’s the correct syntax for each value? These are questions that many users struggle with, often resulting in unintentional errors and a lack of standardization that experienced community members then have to address.

    Adding a statement to Wikidata. Notice the need to remember the exact string of the Statement and value.

    To mitigate this, I designed Lexica with guardrails to handle these complexities. Lexica curates Lexemes, defines what needs to be added, and presents an interface where syntax errors are impossible. Instead of allowing users to freely input text, Lexica presents choices, except in specific cases (e.g., writing script variants of languages). This way, users never have to worry about making syntax mistakes or missing important details.

    Lexica shows users options to select an Item that eliminates error-prone free-form text.

    Adding the fun of playing card metaphor

    Gamification typically relies on elements like leveling up, social interactions, and competition. However, I decided to use a more literal approach, inspired by the desktop metaphor.

    In Lexica, I used playing card metaphor to structure tasks. Cards effectively group discrete pieces of content in a manageable way. Just like a shuffled deck of cards, every Lexeme shown to users is randomized. Users interact with a stack of cards, which is set aside once completed or discarded if unsolvable. These cards are referred to as “task cards”.

    GIF of Lexica task cards that shows stacked and draggable nature of the element
    Task cards uses playing card metaphor such as stacking and dragging.

    Additionally, I incorporated another literal metaphor: hyphenation (“syllabification”). Just as hyphenation splits words into syllables, Lexica allows users to divide a Lexeme directly. Imagine cutting a baguette into pieces—users get to slice the Lexeme into its respective syllables. Whenever users scroll to the gap in between letters, Lexica can give subtle haptic feedback on supported platforms. This metaphor helps familiarize a relatively uncommon concept, adds tactility to the task, and makes quick scrolling easier.

    Illustration of Lexica hyphenation activity: shown lexeme is "adikarya" with a left-right arrow background
    Adding hyphenation in Lexica is as simple as scrolling and dividing.

    While most tools for editing Wikidata tends to be more utilitarian in design, Lexica’s playful approach makes contributions feel more like a game, making complex information easier to digest without overgamifying the experience.


    Structure the contribution as a mystery game

    The process of making a contribution in Lexica is structured like a mystery. In a mystery, a problem is presented, clues must be uncovered, and tools are used at your disposal to help piece things together. Lexica mirrors this:

    • The problematic Lexeme is clearly presented in front of the user.
    • Clues are revealed by flipping over cards, allowing the user to uncover the information needed.
    • Lexica then presents recommendations based on what they’ve discovered while also allows the freedom to manually find answers.
    A collage of steps to solve Lexica Lexeme to Wikidata Item linking activity: showing Lexeme info, showing Item info, previewing the change, and finishing the task card.

    Once everything is in place, Lexica gives a preview screen, presenting the “big picture” before submitting the contribution. This approach empowers users, making them feel like they’ve solved a mystery.


    Focused and finite contribution

    Most Wiki tools are designed for power users who want to accomplish many tasks at once, which can be overwhelming for those with less technical expertise. Lexica, on the other hand, shows only one problem at a time, focusing the user’s attention on a single task.

    To achieve this, I separated detailed information about Lexemes (language-specific) from Items (general concepts). Additionally, I separated the contributing screen from the preview screen. This helps avoid cognitive overload and allows users to focus on the task at hand.

    Additionally, by numbering each contribution and subtly thinning the deck of cards as the session progressed, Lexica helps prevent burnout because users aren’t confronted with endless cards.

    Lastly, every contribution session is limited to only five Lexemes at a time based on user feedback on how long they usually do sustained contribution on the go. There’s no limit on how many session users can do, however, so more engaged users can still do larger volume of edits.


    Familiar, yet fresh interface

    Lexica’s user interface is built on top of Codex, a unified design system used by Wikimedia. Codex provides a set of components and guidelines that allow third-party developers to create Wiki-style interfaces, using design language that users already know and trust. By using Codex, we can implement:

    • Dark mode for a more comfortable viewing experience
    • Responsive interface to support various screen sizes
    • Multi-language crowdsourced translations support through TranslateWiki

    We also created our own custom components by closely following the design system’s standards. This makes Lexica feels right at home in the Wiki ecosystem.


    Accessible by design

    Accessibility was a top priority in Lexica’s design. Since Lexica is very text-heavy by nature, Lexica provides high-legibility Atkinson Hyperlegible Next font to enhance text readability across a variety of devices and environments. For users who are motion-sensitive, we also included a reduced motion feature.

    Further, Lexica also incorporated ARIA (Accessible Rich Internet Applications) labels, appropriate alt text, and adhered closely to Codex’s accessibility guidelines. This ensures that all users, regardless of their abilities, can interact with Lexica in a meaningful way.

    List of accessibility features in Lexica, categorized into text options, reduced motion, and assistive technologies support.

    While we can’t conduct extensive accessibility testing due to time constraints, we ensured that the most essential elements were in place to improve the user experience for a diverse audience.


    Testing and improvements

    Before launching Lexica, we conducted usability testing to identify potential UX issues. Through both user feedback and internal review, we refined several areas of the interface. Here’s a summary of them:

    1. Clearer button labels

    Initially, some button labels were ambiguous and led to confusion about their function. After testing, we reworded several labels to make them clearer and more actionable, ensuring that users could easily understand what each button did without needing to guess.

    2. Removal of cooldown timer

    The initial design included a cooldown timer to prevent users from submitting too many contributions in a short time. However, this approach was too restrictive, causing frustration. After testing, we removed the cooldown timer entirely. We decided to add a little friction by requiring navigation to the homepage to start another session instead.

    3. Color contrast issues

    Testing revealed several color contrast problems. We revised the color palette, ensuring that all text, buttons, and important elements meet the WCAG 2 (Web Content Accessibility Guidelines) for contrast.

    4. Distinction between Lexeme and Item

    There was some confusion among users regarding the distinction between Lexemes and Items. We made this clearer by using two different color schemes and iconography between the two.

    5. More search results

    Users expressed frustration with the search functionality, especially the hard limit on search results shown in the first prototype. After testing, we implemented a way to load more search results.

    6. Position of buttons

    The placement of several key action buttons, such as “Skip” and “End session” buttons was not positioned well and hard to reach. We moved these buttons to the bottom and added text labels.

    7. Unfamiliar iconography

    Some of the icons such as home and skip were hard to identify. We replaced those with more recognizable icons from the Codex icon set.


    Results

    The results from Lexica’s usage data confirm that good design can indeed have a profound impact on user behavior and contribution quality.

    As of the end of July 2025, Lexica has facilitated 2100+ edits with an error rate of less than 5%. Usage patterns also show that Lexica is actively utilized by contributors of all experience levels, with a notable majority being newcomers. This strongly indicates that by providing choices rather than open-ended inputs, most users could produce high-quality contributions with minimal mistakes.

    Interestingly, hyphenation activity makes up 57% of all contributions, significantly more than other activities even though it is the newest activity launched. This indicates that Lexica’s experimental approach is most effective when the interface is highly interactive and specific, avoiding the feel of mundane data entry.


    Conclusion

    Every design choice in Lexica, from the metaphors and structured interactions to the guardrails and native-like interface, was an experiment to find ways to improve Wikidata editing experience. The data and feedback confirm Lexica has become a tool that people trust, value, and use effectively.

    This outcome highlights the true power of good design: contributors at all skill levels can edit with confidence. The low error rate, combined with the high number of contributions, proves that a focused, user-centered interface can significantly enhance both the quality and quantity of user-submitted content.

    As we finalize Lexica and wrap things up, I want to thank everyone who supported Lexica during its development phase. Your feedback was invaluable in refining the tool and shaping its design. From initial usability testing to additional suggestions after launch, your insights have been critical in making and improving Lexica into a tool that works for everyone.

    If you haven’t already….

    Lexica requires OAuth authorization from your Wikimedia account to identify your contributions to Wikidata.

  • Redesigning NewPipe: A Design Exploration

    Redesigning NewPipe: A Design Exploration

    This design exploration started as something to answer a question about improving upon open source app design. NewPipe looked like it had great potential, so why not try making a design exploration out of it?

    For the uninitiated: NewPipe is an open-source YouTube and other streaming platform client for Android. There are a lot of great open-source apps, but most of them needs more polish. Here’s my attempt to improve one of many such apps.

    I hope you enjoy reading this exploration. Thank you!

  • A One-Year Retrospective of Wikidata Software Collaboration

    A One-Year Retrospective of Wikidata Software Collaboration

    Prologue

    Imagine a world where everyone, regardless of their background or language, can seamlessly access structured, interconnected knowledge. This vision drives the creation of Wikidata, a free and open knowledge base accessible and editable by both humans and machines.

    One of the emerging projects within Wikidata is Lexicographical data project. Imagine a hyper-connected “dictionary” that serves both computers—like large language models (LLMs) such as GPT—and humans. This project has the potential to transform the way we understand and visualize languages.

    When I first started using Wikidata and discovered the Lexemes project, I was thrilled by its potential. However, I quickly became frustrated by its complex interface. Finding information was challenging, and utilizing advanced features like querying was confusing. The Wikidata development team probably has known it for quite some time, but addressing it on the scale of Wikidata requires immense resources and effort.

    I will discuss about the UX research and prototyping process for a new Wikidata tool that aims to make the Wikidata Lexemes project more accessible and user-friendly. I will also share the lessons learned throughout this journey.


    Wikidata Software Collaboration

    Wikidata Software Collaboration is funded by the Arcadia Philanthropic Trust and initiated by Wikimedia Deutschland to bring forward the movement strategy initiatives in collaboration with Wikimedia Indonesia and Igbo Wikimedians User Group.

    The project started in July 2022, and I joined in August of the same year. After 12 months of collaboration, we’ve achieved significant milestones—we found out what our community members are like, the way they interact and see Wikidata, then figuring out a solution that can be developed in a realistic timeframe. Our iterative approach, using agile methodology, enables us to create something novel yet useful, and hoping to engage the community in development, testing, and feedback.


    Research

    Our initial goal was to find ways to help people contribute, reuse, and improve the quality of data within Wikidata Lexemes. We started by conducting user research to identify the needs and challenges faced by Wikidata editors in Indonesia.

    This research involved semi-structured interviews with 15 Wikidata editors in Indonesia. They range from beginners to experienced contributors who had joined the local Wikidata community or attended Wikidata events. The interviews were conducted remotely using Zoom. We designed the interviews to explore editors’ mental models, user journeys, challenges, and perceptions of the project and ask them to do short activities related to lexeme search and contribution.

    We synthesized the research findings into an affinity diagram, grouping similar ideas and concepts, which will inform the design of our new tool. Based on this research, the tool should be straightforward, mobile-first, and offer support for users.

    Key findings

    “If developed well, the (Wikidata) Lexemes project will produce extraordinary results! The data can be used as interesting research materials.”

    A participant’s opinion about the future of Wikidata Lexemes

    “Everything is done voluntarily by volunteers. Contribute, no matter how small it is. If there’s a mistake, someone will fix it, no matter how small the mistake is. Don’t be judgmental and don’t be emotional.“

    A participant’s opinion about core values of a wiki community

    Wikidata & Wikidata Lexemes

    Steep learning curve

    Understanding how to use Wikidata, particularly for lexeme search and contribution, is challenging.

    Mobile editing problems

    They often use their mobile devices to contribute to Wikidata. Unfortunately, Wikidata Lexemes cannot be edited on mobile devices except in desktop mode.

    Translation and jargon

    Translating content into local languages is crucial, and technical jargon must be explained clearly.

    Data quality concerns

    Issues such as duplicates and incomplete statements are common, often caused by editors who are unsure of what to contribute.

    Unique language properties

    There are concerns about accommodating non-Latin characters, various registers, and dialects specific to local languages.

    Compare and contrast

    The community has noted similarities between Wikidata Lexemes and other lexicography tools like WordNet, as well as comparisons with other Wikimedia projects such as Wiktionary, Wikisource, and Wikipedia.

    Community

    Indonesians are active Wikidata editors

    Compared with other Wikidata communities, Indonesian editors are notable active.

    Proud of original contribution

    They prefer creating items or lexemes from scratch because they’re proud of their original contributions.

    Diverse interests

    The community includes both linguistics-oriented and tech-oriented individuals.

    Comuunication channels

    They communicate via WhatsApp and Telegram, with announcements also reaching members through Instagram and Twitter/X. They prefer short, visually engaging content.

    Wants to be heard

    The community wants to be heard but they don’t know how to give feedback and push for change.

    Knowledge transfer issues

    There is limited knowledge transfer between experienced members and newcomers, affecting new editor retention and their knowledge gap.

    What to edit?

    There is no consensus on what to contribute on Wikidata Lexemes, especially for local languages.

    Additional discussions with Wikimedia Deutschland

    We discussed the findings with Wikimedia Deutschland’s UX team, focusing on several key points.

    • The abundance of tutorials and training needed for newcomers shows that the current Wikidata interface is not user-friendly. This indicates a need to reduce the barrier of entry.
    • Mobile device support is important. We need to collect data on Wikidata users who edit from them. This can help us understand mobile usage patterns and highlight the need to improve their experience.
    • Even users with a linguistic background have found the current technical jargon too technical. This raises the issue of balancing accuracy, precision, with user understanding.
    • The current wiki culture may influence the existing overincentivization of individual contributions. As UX designers, we cannot address this cultural factor easily, but it is a good idea to keep this in mind.

    Demographics

    Here are some insights that we can get from the data:

    • Indonesian Wikidata editors tend to skew younger.
    • All of them used laptops and the majority of them also edit on mobile devices.
    • Most of them are involved in other Wikimedia projects, particularly Wikipedia, Wikisource, and Wikimedia Commons.
    • Most of them live in more developed parts of Indonesia such as Java, Bali, Sumatra, and Kalimantan.
    Cover page of the report Indonesian Wikidata Research Participant Demographics

    Persona

    The Indonesian Wikidata community can be divided into five categories regardless of editor tenure.

    Five Indonesian Wikidata user profile
    • Andi, The Data Utilizer: Tech-oriented, academic users of Wikidata for research and product R&D.
    • Sandi, The Teaching Linguist: Teachers and educators, linguistics-oriented people who want to learn deeper about languages.
    • Hendra, The Affable Maintainer: Community members who become the community’s cornerstone because of technical and people skills.
    • Shinta, The People Inviter: Community members who get new members onboard and skilled in social media and communication.
    • Joni, The Competitive Editor: Resourceful members who self-improve and continuously contribute out of passion.

    Ideation

    After the research, we need to come up with ideas for a new Wikidata tool. We started by looking on well-loved tools within the community, such as ISA Tool and Lingua Libre. ISA Tool is a mobile-first website that helps users connect images uploaded to Wikimedia Commons with relevant Wikidata statements. Lingua Libre enables users to submit pronunciations of words to Wikimedia Commons in multiple languages.

    We then used FigJam to conduct an ideation workshop. First, we assembled a visual moodboard to inspire creativity and set the tone for our brainstorming, then generated a list of words and phrases related to the moodboard and created a word cloud to visualize key concepts. Next, we did brainwriting, a technique where participants recorded their ideas on sticky notes and then shared, discussed, and categorized into themes. Lastly, we did a simple feasibility analysis based on factors such as innovativeness, scope, required resources, and time constraints.

    This ideation resulted in three ideas: a mobile-first contribution tool to simplify Wikidata Lexemes contributions, a gadget to recommend lexemes for addition or editing, and a learning app using flashcards for language and lexicography.

    After discussing these ideas with Wikimedia Deutschland, we concluded that the mobile-first contribution tool was the most feasible idea. The gadget to recommend lexemes idea was too complex to make, and the learning app’s scope was too broad.


    Prototyping

    Next, we created an initial prototype for the new tool using Figma. This prototype featured:

    • A streamlined, mobile-first interface inspired by stacks of playing cards, designed for quick and easy contributions on the go.
    • Limited scope of contributions, such as adding antonyms, that can be expanded over time.
    • Community-curated topics (planned).
    • Randomized daily contributions (planned).
    • Support for multiple languages (planned).
    Prototype features of the tool that was about to be developed

    Post-prototype discussion

    After sharing the initial prototype with Wikimedia Deutschland, we discussed several considerations:

    • Gamification can be a double-edged sword. Badly designed gamification can give people the wrong incentives to edit. We must carefully design gamification elements to encourage meaningful collaboration rather than just the volume of contributions.
    • The tool needs to support users who don’t use touchscreens or have motor disabilities. We must incorporate alternative methods of interaction beyond gestures.
    • Ensure the tool is responsive so it works well on both mobile and desktop devices.
    • Start with developing core features, gather user feedback, and iteratively add new features over time.

    Next steps

    To continue working on the project, we need to:

    • Develop a detailed MVP of the mobile-first contribution tool to test its basic functionality and gather user feedback.
    • Conduct usability testing with a broader range of participants to assess the design and make improvements, ensuring the tool is user-friendly for everyone.
    • Develop, launch, and iterate on the tool using agile methodology, continuously refine it based on community feedback.
    • Engage the community throughout the development process to maximize impact, ensure accountability, and maintain transparency.

    Conclusion and personal wishes

    Perfect is the enemy of good. Good enough products are enough.

    Working on this project has been a profound learning experience. I’ve learned how to collaborate with people from diverse cultures, principles of agile methodology, and the stories behind Wikidata development. I’ve also learned how to connect with various communities and partners, and how to brainstorm, ideate, and iterate in innovative ways. I am grateful for this opportunity and eager to see what the future holds.

    I am confident that this project can thrive as a community-driven initiative. It can be sustainable and inspire others to create well-researched and thoughtfully designed products, even when the initial idea sounds simple on paper. Working on community efforts can be challenging, but the rewards are significant.

    Language is more than just a system for communication; it’s a tool for achieving shared understanding. Throughout this project, I’ve learned that effective communication involves not only choosing the right words but also understanding the context and showing empathy to whom we’re communicating with.

    I invite anyone interested in contributing to this project to learn more about this collaboration. Your feedback on the prototype would be greatly appreciated, as it will help shape the future of the tool.

    Photo of people associated with Wikimedia Software Collaboration project.

    Thank you for reading until the end and here’s for the next 12 months and more for this project!

  • Presento: Public Speaking Preparation Platform Case Study

    Presento: Public Speaking Preparation Platform Case Study

    Duration

    May–June 2022 (3 weeks)

    Role

    UX Designer

    What is done

    Research, wireframing, prototyping, and testing

    Made for

    Google UX Design Professional Certificate

    “Speak your mind about your next big ideas.”

    Creativity, collaboration, and communication are the cornerstones of 21st century skills that students across the globe need to master. Their ability to public speaking are more important than ever. Nowadays, public speaking, usually in the form of presentations, are commonplace in schools and universities.

    Enter Presento, a newly formed startup dedicated to empower students in developing their communication skills and shaping their futures. Presento exists because of the belief that while public speaking presents unique challenges, these challenges can be addressed with a solution that is both profitable and socially responsible.

    To begin, Presento recognizes the necessity of conducting in-depth research to understand the how students approach and struggle with public speaking.

    Business goals

    Discover business opportunities to help students prepare for public speaking

    Find out the right monetization strategy for the solution


    Research

    Research goals

    The most important part of conducting a research is to set the goals of the research itself.

    Understand what kind of public speaking students do and who their audience are

    Understand the end-to-end journey of how students prepare for their public speeches

    Find out the challenges faced by students when presenting

    Discover what the students’ wants and needs to achieve their goals

    Discover what tools students use to prepare for public speaking

    Hypotheses

    Students usually do public speaking for their teachers/lecturers and fellow students

    They use slideshow makers with templates such as PowerPoint, Google Slides, Prezi, or Canva

    Inability to master their speech (intonation, rhythm, tone) is the main issue when presenting

    User interview

    Are those hypotheses really true, though? To find out, I conducted online interviews with several students aged 15-25 years old that has done public speech in the last 3 years.

    This is the insights I got from the interview:

    Research insights

    Students wished that they can meet with public speaking experts anytime, anywhere with a flexible schedule

    Students wanted to get their expert advice in a private, judgement-free zone

    Students don’t know where to find resources to help them learn techniques to master public speaking

    Next, we can make personas and analyze competitors to represent both the user and business based on research.

    Persona

    Persona of Thomas, a student who does presentations often.
    Thomas, a student who does presentations often
    Persona of Siska, a bootcamp mentor who use public speaking to deliver material to her students.
    Siska, a bootcamp mentor who use public speaking to deliver material to her students

    Competition

    Even though there are no direct competitors for Presento, there are several tools that directly inspired Presento: video call apps, calendar apps, and content curation services. Here are the inspiration I took:

    The inspirations captured from Presento's indirect competitors to create a public speaking preparation platform.
    The inspirations captured from Presento’s indirect competitors

    With the research done, competitors audited, and the inspirations captured, we can move on to the next step.


    Wireframe

    I designed the wireframes digitally using Figma, then tested and iterated them once using usability testing. The design started as a mobile application, then scaled up for tablet and desktop as a website afterwards.

    Early Presento wireframe.
    The early wireframe of the app
    Highlights of the wireframe goals of Presento
    The highlight of the wireframe goals made in Figma
    Sitemap for Presento, a public speaking preparation platform
    Presento’s sitemap

    First usability testing

    This activity is done using moderated remote usability study with 5 testers, 15-25 years old, and are active students. Each session lasts 10-20 minutes and done without any additional tools to get their first impressions.

    First usability test insights

    Insert slides when planning

    2/5 testers

    said that inserting slide/script should be available in planning stage

    Add replay session feature

    3/5 testers

    said that inserting slide/script should be available in planning stage

    Review screen

    3/5 testers

    got confused: is the review for the expert or technical aspect of the session?

    Web articles or document?

    2/5 testers

    said that the contents in the Explore screen look like documents instead of web articles

    Look into the camera!

    Many participants look at the bottom of the screen instead of facing the camera on mobile devices


    Prototype

    I created the prototypes as an Android-based app and a Progressive Web App (PWA) inspired by Material Design 3 as the design guideline.

    Before continuing the design process, I need to address the feedback from the first usability testing.

    Mockups and revisions

    Final Presento mobile app prototype
    Presento mobile app prototype
    Final Presento desktop website prototype
    Presento desktop website prototype

    Accessibility considerations

    This project also considers accessibility, especially for the visually impaired. Here are some of them:

    Presento accessibility considerations to improve public speaking learning experience.

    Style guide

    Boldness and freshness drive the overall design choice for Presento. The dramatic and authoritative DM Serif is used for headings, creating a strong visual impact. For body text, the friendly humanist sans serif Commissioner provides a sharp yet approachable look, balancing readability with modern aesthetics.

    The color palette is designed to make a statement. An aura of teal dominates the screen, highlighting Presento’s commitment to being fresh and distinct. This vibrant color choice not only captures attention but also reinforces the brand’s innovative spirit.

    To complement the color scheme and typography, Material Design icons are employed. These icons contribute to a clean, organized appearance, enhancing user experience by making navigation intuitive and visually appealing. The combination of these design elements ensures that Presento stands out as both a visually compelling and user-friendly platform.

    Presento style guide. Contains components, colors, and typography.

    Final prototype

    The prototype can be seen on Figma. Try to interact with them!

    Note: To see all variations of screen sizes, click the Figma logo on the top left of the screen.

    Second usability testing

    This activity is done using moderated remote usability study with 5 testers, 15-25 years old, and are active students. Each session lasts 20-30 minutes.

    “That is so cool! I never thought I will need this. It certainly would help me to present better. I will definitely use this service and highly recommend it to my friends!”

    A participant’s impression on Presento

    All the testers welcome Presento as a solution to the problem. Some even said that they never thought those problems can be solved!

    The success rate of each task is 100% and the calculated Net Promoter Score (NPS) is 80. In conclusion, Presento has met the needs and wants of students who are preparing for public speaking.


    Conclusion: Helping students improve their public speaking is an interesting challenge

    Creating a solution for social good is always a challenging yet satisfying project. In this case, Presento is well-aligned with Goal 4 of UN’s Sustainable Development Goals: quality education.

    This project pushed me to truly immerse with the people I designed this solution for, putting myself in their shoes and understanding their perspectives, down to the money they’re willing to spend.

    Because it is very time-consuming to design an app and responsive website layouts single-handedly, I had to learn how to use a lot of Figma’s features and extensive plugin support to speed up my work.

    Thank you for reading this case study. I hope you enjoy it!

  • Project Takeout: A Takeout Food App Case Study

    Project Takeout: A Takeout Food App Case Study

    Duration

    January–April 2022 (3 months)

    Role

    UX Designer

    What is done

    Research, wireframing, prototyping, and testing

    Made for

    Google UX Design Professional Certificate

    Background

    Project Takeout, a fictional takeout food restaurant chain in Jakarta, caters to office workers and busy individuals. To minimize rent and operational costs, they operate on a pickup-only model with no in-store dining. Currently, customers view the menu and place their orders directly at the restaurant, waiting in long queues for their meals.

    Initially, this approach worked well. However, with rapid expansion into many offices and malls, it became apparent that this won’t be sustainable for long. Customers pour into the restaurant. Queues started to become overwhelming. The increasing dissatisfaction with long wait times clearly highlighted the need for change.

    The stakeholders recognized the urgent problem and identified eliminating the queues as a critical goal. They hypothesized that removing the need for customers to wait in line and order in-person would significantly enhance the customer experience.

    Key questions

    Why do we need to make this project?

    What will the product be and who is it for?

    What are the primary needs of our customers?

    Who are our competitors and how can we stand out?

    What are the challenges that will be faced by this project?


    Research

    This step consists of user interview and competitor analysis that results in the creation of persona, storyboard, and user journey.

    User interview

    As a starting point, I began by exploring whether removing the need for customers to queue and order meals would indeed improve the customer experience.

    I conducted interviews with office workers who have short lunch breaks and limited time for ordering food. From these interviews, I developed a detailed persona to better understand the needs and behaviors of this user group. The findings confirmed that eliminating queues would likely enhance the customer experience. However, the research also uncovered that queuing time was just one of several factors affecting customers’ decisions to order from Project Takeout.

    Research insights

    Time restrictions

    Office workers, often pressed for time, find it frustrating to wait in line just to place a food order.

    Skip the line

    There’s no way to preorder food to takeout to skip queueing.

    Menu hard to read

    An unexpected insight: the menu behind the counter is difficult to read from a distance while waiting in line.

    Persona

    Persona of Kusuma, an office worker who orders food at Project Takeout

    I imagined that the persona, who values efficiency and convenience, encountering a streamlined system for ordering takeout food. Here’s how the experience would unfold (excuse me for such a high-quality sketch). In summary:

    • The persona could use an app or website to preorder their meals, eliminating the need to wait in line.
    • With a more accessible and readable digital menu integrated into the app or website, the persona would be able to review their options easily.
    • When the persona picks up their food, a simplified pickup confirmation process ensures food pickup speed while minimizing the chance of accidental pickup by other people.
    User journey of our persona, Kusuma

    Competitors

    Project Takeout faces competition from both direct and indirect players in the food takeout industry.

    Direct competitors of Project Takeout: Dailybox, Box & Co, Jiwa+, Fore, Kopi Kenangan.
    Direct competitors of Project Takeout: Dailybox, Box & Co, Jiwa+, Fore, Kopi Kenangan.

    Direct competitors have a similar business model and offer mobile apps that provide menu access, ordering capabilities, and loyalty point tracking. However, Dailybox and Box & Co do not offer pickup services. A significant drawback of these apps, however, is their complexity. Some users find them overwhelming; one participant even preferred to wait in line rather than use the app. Additionally, accessibility issues such as text smaller than 12pt, make these apps difficult to read—particularly for users with vision impairments like our persona.

    An example of competitor's app that have unreadable text size
    Can you see what category I’m looking at?
    Indirect competitors of Project Takeout: GoFood, Grab.
    Indirect competitors of Project Takeout: GoFood, Grab.

    Indirect competitors provides food pickup service, but they are not associated with a specific restaurant. While this can be a very compelling feature to some customers, they lack the level of food customization and personalization that Project Takeout is known for.

    With these insights and competitive audits in mind, the goal is clear: design a solution for Project Takeout that allows customers to view the menu, preorder their meals, and skip the line. By doing this, we can something that answers Project Takeout’s customers needs and wants.


    Early wireframes

    I began by creating early wireframes by hand. I focused on key elements such as menu presentation, meal customization, preorder options, and pickup process, capturing the essence of what the final design should achieve.

    Hand-drawn Project Takeout wireframe

    Once the hand-drawn wireframes were complete and reviewed, I transitioned to Figma to develop a more polished and interactive prototype.

    Recreation of wireframe in Figma

    First usability testing

    This activity is done using moderated remote usability study with 5 testers, 18-35 years old, and live in urban areas. Each session lasts 10-20 minutes and done without any additional tools. Here are the insights:

    Use QR to confirm

    3/5 testers

    expressed a clear preference for using a QR code to confirm their order instead of entering a PIN.

    Simplify personalization

    2/5 testers

    said that the current system for personalizing food preferences and dietary restrictions was too complex.

    Improve checkout

    Testers found the checkout process to be cumbersome and suggested simplifying it. Specifically, the scheduling function, which was rarely utilized, should be deemphasized.

    These insights highlight areas for improvement, mainly to focus on streamlining and reemphasizing of features.

    Improved Project Takeout wireframe

    Here’s the highlight of changes made in this iteration:

    With the iteration complete, we can now advance to creating the high-fidelity prototype, incorporating the following key considerations:

    Using color contrast that is WCAG 2 compliant

    Clean and legible typeface to enhance readability

    Avoid use of image-based text to ensure accessibility and text scalability

    Use at least 12px font size to ensure legibility

    Using consistent terminology throughout the app


    Prototype

    The prototype is an Android-based app and used Material Design 3 that was introduced in Android 12 as the design guideline.

    The following recommendations are incorporated into the high-fidelity prototype:

    Recommendations

    Helps someone to find their usuals and discover new meals.

    Food customization categorization

    Grouping customization based on specific food elements, additions, exclusions, and additional notes.

    Checkout page rework

    Reduced prominence of scheduling function, giving more focus on checkout section.

    Second usability testing

    This activity is also done using moderated remote usability study with 5 testers, 18-35 years old, and lives in urban areas, now using Maze and Google Forms as the data capture tool. Each session lasts 20-40 minutes.

    Overall, the results are promising. The average time on task is less than 10 seconds and the success rate of each task is 100%. The calculated Net Promoter Score (NPS) is 80 and the System Usability Score (SUS) is 82.5. It can be said that the app has gained Project Takeout customers’ trust and have met their needs and wants.

    “This app feels polished, looks professionally-made and comparable to world-class apps such as UberEats and GrubHub. I love it.”

    A participant’s impression on Project Takeout app

    During the second round of usability testing, additional insights emerged that highlight areas for further refinement:

    Add button to see all menus on homepage

    2/5 testers

    reported difficulty accessing the full menu from the homepage.

    Include additional notes

    2/5 testers

    suggested incorporating a feature that allows users to add notes during the food customization process.

    Show order details when confirming takeout

    Testers indicated a need for a clearer view of the meals being ordered before confirming pickup.

    Final prototype

    The prototype is finalized, implementing feedback that are captured.

    Style guide

    Style guide that includes reusable components, colors, and typography chioces for Project Takeout

    Typography

    The app utilizes Outfit, a big, bold, geometric typeface for headings. This choice adds a strong presence and a modern feel, making important information stand out effectively.

    Lato, a humanist sans-serif typeface, is used for body text. Known for its readability and versatility, Lato provides a subtle, clean look that complements the bold headings without being overpowering.

    Color

    The color palette is predominantly muted, featuring near-black and white tones. Occasional hints of color and varying shades of gray are used to highlight important elements or interactive features. The restrained use of color keeps the focus on the high-quality food images.


    Conclusion: Rethink the way we order food

    As the COVID-19 pandemic subsides and people return to their offices, the food pickup business presents a promising opportunity. This case study demonstrates that even well-established processes, like ordering food at a restaurant, can be significantly enhanced with thoughtful design and innovation.

    Initially, I assumed that developing a food takeout app would be straightforward, just try to replicate existing solutions. However, throughout the design process, I discovered that real improvements could be made. The insights gathered from participants revealed unique opportunities for refinement that go beyond what competitors currently offer.

    This case study highlights the value of listening to users and addressing their specific needs to create a more effective and enjoyable food ordering experience. By focusing on accessibility, usability, and design improvements, we can transform the conventional food pickup process into something more efficient and user-friendly.

    Thank you for reading this case study. I hope you found it insightful!

  • Canting: A Batik Drawing Application

    Canting: A Batik Drawing Application

    Canting is a design exploration to create a batik-drawing application for tablets with stylus.

    It is awarded as the winner in 2020 International Design Challenge hosted by Binus University and sponsored by CHIuXiD.

    Duration

    April 2020 (2 weeks)

    Role

    UX lead, working with Laksamana Kusuma

    What is done

    Ideation, wireframing, and prototyping

    Made for

    2020 International Design Challenge

    An award-winning design exploration

    Shout out to my friend that joined me in this competition, Laksamana Kusuma!

    He is really hard-working and resourceful. Without his help, there’s no way our team won the 2020 International Design Challenge.


    Background

    There are

    5849

    batik motifs in Indonesia.1

    Sadly, people do not realize the diversity of Indonesian batik motifs. In fact,

    9 out of 10

    most popular motifs are coming only from Java.2

    A person is creating batik fabric

    Most Indonesian batik makers are currently over

    40 years old.3

    “We saw that the number of young people who want to become batik painters are still very limited.”3

    Haris Munandar, Secretary General of the Ministry of Industry of Indonesia

    “Batik seems to lose its soul and people don’t get the correct values and motifs.”

    Iwan Tirta, Batik designer on rise of printed batik

    UX Methodology

    Illustration about design thinking: Emphatize, Define, Ideate, Prototype, Test

    We use Design Thinking as the methodology for researching, designing, and testing to create Canting.

    Because the competition had a very tight deadline, most of the steps are shortened.

    1. Empathize

    We’re starting to search for ideas on how to make young people want to learn the traditional batik drawing process.

    But, we need to remember that we can’t just create a product then try to match it to our user’s needs. It should be the other way around: user’s needs drives us to create a solution.

    After some brainstorming and user interviews, turns out that most young people are actually interested in batik. They just don’t know where to learn and how to preserve batik as an important Indonesian culture.

    Persona of Canting: Ayu Saraswati. Contains bio, goals, frustrations, and stats about the persona

    2. Define

    After creating our persona, it is important to see the problems from their view. Here are several problems that we found:

    Firstly: What about finding the closest batik painting class? We searched around in Jakarta and only found 1 location: Textile Museum. We also found out the schedule of batik painting class doesn’t fit our persona’s busy and mobile lifestyle.

    Secondly: Where could we find some inspiration? As far as we know, there’s no dedicated platform to share batik creations online.

    Thirdly: What about people’s appreciation to the art of batik drawing process? The rise of printed batik pattern makes batik affordable. But, commercialization of batik can be a threat to the art of creating batik. People who bought those may not know what those patterns represent.

    Lastly: What about government support? While there are some support of wearing batik4,5, but it is mostly formality. The government doesn’t have a solid program to educate people about the diversity and artistic values of batik.

    With all the problems defined, it is time to create our solution.

    3. Ideate

    And an idea came to mind: Why not combine the best of both worlds? Why don’t we make batik drawing process digital yet respects traditional processes?

    We chose Canting as the name of our product. Canting’s name came from the instrument used to transfer wax in batik drawing process.

    Canting logo (alternate color)

    It turns out that tablets with stylus can replicate fabric and canting intuitively. Plus, it is also one of the tools that our target users usually have.

    We also want Canting to be the place to find inspiration to share user creations online. Plus, we wanted to add some education about batik patterns and its meaning.

    Being a digital product, Canting is far more flexible than traditional batik drawing process. It allows us to draw anytime and anywhere we want, share our creations to the world, easy layering and correct drawing mistakes.

    4. Prototype

    When creating the design, we decided on the motif on our application as well. We chose partially-rounded rectangle inspired by the batik pattern Kawung.

    Tablet screen showing the homepage of Canting. Contains create new pattern button, navigation buttons, created batik patterns

    Design system

    We used 1920×1440px (4:3) Android device as the canvas for our prototype and uses Google’s Material Design for the design system.

    Typography

    For the logo font, we use Upakarti by Adien Gunarta.

    For other elements, we use Roboto. It is the standard font in Android to make our app blend in and as non-distracting as possible.

    Color

    Our main color is deep brown, inspired from the color of wax used when drawing batik. The rest of the application is monochrome to help you focus on the canvas.

    Iconography

    We mostly used Google’s Material Icons and some handmade ones. There are slightly rounded icons with some angular ones. We did that because some icons can be hard to see if it’s rounded. (For example, the difference between pencil tool and canting tool)

    Tools

    We used Adobe Photoshop to create all user interfaces, Axure RP to create user interface flow, and Inkscape to create custom icons.

    5. Test

    Due to limited time and COVID-19 pandemic, we only did basic heuristics testing and user testing to 1 person.

    Before testing it to our users, we did some user flow checking for all use cases to make sure they can create new drawing and explore inspirations in the prototype.

    In conclusion, the test result showed that the demand for apps like Canting exist.

    “I think this application is great. It’s also easy to use, you can even see a diverse unpopular Batik motifs. I think it is very important to have a platform for people to learn how to paint Batik, even if it’s not real like using canting and real fabric. You can see your drawings and discover others too.”

    “I suggest you to add tutorial videos on drawing batik and more detailed information about the selected batik patterns.”

    Vivian, 21 years old

    Conclusion

    Canting helps:

    1. Young generation to learn about the diversity of batik patterns and how to draw them
    2. Artists can create and elevate batik as an art form
    3. Support the government on batik education and preservation

    Thank you for reading this case study.

    Postscript: In Retrospective

    This case study is one of the project that lit a spark for me to pursue UX further. With such a limited time to conceive a solution that can be presented for the international competition, I learned how to brainstorm, ideate, and delegate tasks with my team.

    Finding inspiration to preserve batik as a cultural heritage is not easy. It took a few trips to the Batik Museum and art galleries to find inspiration for creating Canting. I learned that sometimes, to think out of the box, you need to find the right environment and some downtime to get my creative juices flowing to tackle the problem.