KnowNative

KnowNative

KnowNative

KnowNative is a language-learning platform that helps students of traditional Chinese improve reading comprehension through immersive, personalized study experiences. They had recently launched their demo for their web app, but it was designed exclusively for desktop use. To increase accessibility and broaden their reach, I was brought on to design responsive mobile and tablet versions.

Project Overview

Project Overview

Project Overview

Challenge

Improve KnowNative's demo experience by designing responsive prototypes that make the product accessible across devices and easier for users to engage with.

Outcome
  • Delivered tablet and mobile prototypes that allow users to explore the demo seamlessly from any device.

  • Created a scalable design system to support consistency and collaboration among team members throughout the project.

Role

UX, UI Designer

Time

16 weeks

Tools
  • Figma

  • Pencil and paper

First Impressions

First Impressions

First Impressions

I began by reviewing the existing desktop design and noting my initial impressions as a new user. With no prior experience learning Chinese, I assessed the interface from the perspective of someone encountering it for the first time.

I began by reviewing the existing desktop design and noting my initial impressions as a new user. With no prior experience learning Chinese, I assessed the interface from the perspective of someone encountering it for the first time.

What Worked Well

What Worked Well

Where I Felt Confused

Where I Felt Confused

Opportunities I Noticed

Opportunities I Noticed

These reflections made it clear that the current design assumes users have some existing knowledge of Chinese. While I had several ideas for new features, I prioritized translating the current experience responsively and documented my observations for future, research-backed improvements.

Responsive Planning and Breakpoints

Responsive Planning and Breakpoints

Responsive Planning and Breakpoints

Before building out the designs, I defined responsive breakpoints to guide layout decisions. Since the demo had just launched, we didn’t have data on the range of devices users were accessing it from. Referring to the Nielsen Norman Group's recommendations, I used the following breakpoints as a starting point:

Before building out the designs, I defined responsive breakpoints to guide layout decisions. Since the demo had just launched, we didn’t have data on the range of devices users were accessing it from. Referring to the Nielsen Norman Group's recommendations, I used the following breakpoints as a starting point:

Working with the prototype across different screen ranges, I realized there was no meaningful benefit to creating an XS window class. The layout and features stayed consistent between XS and S breakpoints. Based on this, I refined the breakpoint system to focus on three meaningful ranges: S, M, and L.

Working with the prototype across different screen ranges, I realized there was no meaningful benefit to creating an XS window class. The layout and features stayed consistent between XS and S breakpoints. Based on this, I refined the breakpoint system to focus on three meaningful ranges: S, M, and L.

Medium Window Class

Medium Window Class

Medium Window Class

Toggling Side Navigation Bar

Since we already had the large window class built and prototyped, I began wireframing for the medium and small breakpoints.

For the medium layout, I explored how to adjust the sidebar and reading space to maintain legibility and balance. Because reading is central to the experience, I sketched different ways the sidebar could condense or shift to give the text more space.

Left: Tablet concept created by previous UX designer; Right: Sketches of ways to condense the sidebar

Top: Tablet concept created by previous UX designer; Bottom: Sketches of ways to condense the sidebar

Left: Prototype of side navigation bar (orange) with double arrow icon button directly under navigation items ; Right: Prototype of side navigation bar (orange) with double arrow icon button on the bottom of the bar

Top: Prototype of side navigation bar (orange) with double arrow icon button directly under navigation items; Bottom: Prototype of side navigation bar (orange) with double arrow icon button on the bottom of the bar

While reviewing the prototypes, the stakeholder and I realized it was difficult to visualize how the side navigation would behave when collapsed, including where the toggle arrow should appear. To address this, we placed the toggle arrow directly beside the side navigation so users could easily find and reopen it, and we switched from a double-arrow icon to a single arrow to better match KnowNative's minimal visual style.

Left: Final prototype of side navigation bar open; Right: Final prototype of side navigation bar closed

Top: Final prototype of side navigation bar open; Bottom: Final prototype of side navigation bar closed

Layout Challenge

Designing the medium window class turned out to be more complex than I expected. I'd experimented with responsive design before, but this was the first time I was fully responsible for making an entire website adapt smoothly across breakpoints.

While creating the high-fidelity mockups, I ran into an issue with the medium breakpoint range (641px-1024px):

  • At the larger end of the range, both the main text and sidebar could be displayed side by side

  • At the smaller end, the main text collapsed, and the sidebar expanded to fill the entire screen.

    This inconsistency raised development concerns, especially around when and how the layout should shift.

Designing the medium window class turned out to be more complex than I expected. I'd experimented with responsive design before, but this was the first time I was fully responsible for making an entire website adapt smoothly across breakpoints.

While creating the high-fidelity mockups, I ran into an issue with the medium breakpoint range (641px-1024px):

  • At the larger end of the range, both the main text and sidebar could be displayed side by side

  • At the smaller end, the main text collapsed, and the sidebar expanded to fill the entire screen.

    This inconsistency raised development concerns, especially around when and how the layout should shift.

I discussed with the stakeholder, and later, in a team meeting (which I couldn’t attend), it was confirmed the developers were also unsure how to handle the transition. It was clear to me that the breakpoint ranges I had set weren't going to work. To resolve this, I further explored different breakpoint options and mocked up threshold variations.

We then chose Option A where the end of the large window class size would be at 907px and the beginning of the medium window class would start at 906px. Across the entire medium breakpoint, the main text would collapse and the side navigation would take full width. This simplified development and created a more consistent experience. Since this decision was made based on visual and technical preference, we agreed to conduct future user research to better understand how users interact with the app on different screen sizes.

The new and finalized breakpoint ranges

The new and finalized breakpoint ranges

Small Window Class

Small Window Class

Small Window Class

Similarly to the medium window class. I explored a few different structure options to preserve the integrity of the existing desktop design. I referenced earlier concepts created by the UX designer that worked on the demo which gave me a strong foundation and inspiration to iterate from. 

Left: Mobile concept created by previous UX designer; Right: Sketches of small class window

Top: Mobile concept created by previous UX designer; Bottom: Sketches of small class window

Adding/Deleting a Term

The desktop demo users hover and pop-up interactions to let users view definitions and add terms to their flashcards ("Terms"). This pattern didn't translate well to mobile due to the limited screen space and the absence of hover states.

The desktop demo users hover and pop-up interactions to let users view definitions and add terms to their flashcards ("Terms"). This pattern didn't translate well to mobile due to the limited screen space and the absence of hover states.

Desktop Demo of "Study" Tab

Desktop Demo of "Study" Tab

On mobile, key constraints included users being unable to hover to identify interactive words, pop-ups requiring unnecessary taps, and the definition component needing to fit within much tighter screen space.

On mobile, key constraints included users being unable to hover to identify interactive words, pop-ups requiring unnecessary taps, and the definition component needing to fit within much tighter screen space.

Mobile Demo of "Study" Tab

Mobile Demo of "Study" Tab

To mitigate those constraints, I underlined terms to indicate interactivity, ensured the "+" button was accessible for tapping, and replaced the desktop pop-up with an inline definition component that expands within the text. The inline component currently does not display pinyin, so I hope to test whether mobile users need pinyin in context and explore adding an audio-pronunciation feature as a future enhancement.

To mitigate those constraints, I underlined terms to indicate interactivity, ensured the "+" button was accessible for tapping, and replaced the desktop pop-up with an inline definition component that expands within the text. The inline component currently does not display pinyin, so I hope to test whether mobile users need pinyin in context and explore adding an audio-pronunciation feature as a future enhancement.

Design System

Design System

Design System

To ensure that my work was clear and easy to build on for both developers and future UX designers, I documented patterns, spacing, components, and interaction to help maintain consistency across screen sizes and streamline handoff. The image below is one of the many examples of how I recorded those iterations.

Window Size Class Documentation for KnowNative's Design System

Window Size Class Documentation for KnowNative's Design System

Final Designs

Final Designs

Final Designs

From a wireframe to prototype, I finalized my responsive designs for both the medium and small window class in preparation for handoff and user research.

Reflection & Next Steps

Reflection & Next Steps

Reflection & Next Steps

Being new to working in a multidisciplinary team, design systems, and responsive prototypes, I learned a great deal throughout this project. I spent significant time researching design systems in Figma and best practices for responsiveness, and I'm proud of how those efforts informed the final outcome. I look forward to applying these skills in future projects.

  1. Testing

Many of the design decisions were assumption-based, so usability testing would be the first priority to validate the interaction patterns and refine the responsive layouts.

  1. Hand-off

After testing and iterating, I would prepare a developer hand-off with clear documentation, component specs, and responsive behavior guidelines.

  1. Product Launch

Once developed, the product would be available across multiple devices, improving accessibility and expanding KnowNative's reach.

  1. Future Features

After observing how users interact with the app, I would prioritize and design additional features that support their learning need and improve the overall experience.

Check out other case studies:

Check out other case studies:

Check out other case studies: