Sample App Research

What Devs & QA

Think about Our

Sample App?

Design System Team

Design System

We want to properly address the overall usage and impact of current sample app on expected users

(Core QA, Vertical QA, Vertical Devs)

​

Hopefully we can create more proper sample app design that can impact Devs and QA quality of work which leads to reduce # of defects and confusion on core components

​

Why Are We Doing This?

Background

Sample app is a platform for Devs, Core QA, DS designers to check developed core components. It helps us test the capability of TDS components and spot any gaps early.

1. Gather Devs & QA perception and usages on the current Sample App
2. Identify usability issues of current sample app

Research Objective

About the Research

👨‍💻

Participants

Vertical Devs (3)

👨‍🔧

Vertical QA (2)

🙋‍♀️

Core QA (1)

• How Devs & QA interact with TDS component in their usual workflow?
• Is the current sample app design already fulfilling user's needs?

​

Research Questions

• There's a new TDS component created by core team, you wants to check the component on the newest sample app which is (core component name). What will you do?
• you see (some core component variants) of Figma/staging app. Through sample app, how do you make sure the variant is available?

​

Usability Testing Task

What Do You Guys Think about Our

Current Sample App?

Here’s What QA & Devs Says about Our Current Sample App!

“

Sample App is useful for grooming like checking core component availability and capability

- Michael (Android Devs)

“

It’s quite hard if there’s no sample app. Because I must manually render the component I want to preview which take quite time. With sample app, I can see core components information effortlessly.

-Ernest (IOS Devs)

“

Even though not not all component can be modified, some component pages that can be modify helps a lot for doing QA job.

-Prabhleen (QA Core)

“

I really like you guys adding the search bar! Now I can easily search for components that I want to preview!

- Joseph (IOS Devs)

How Exactly Sample App Impact Their Process?

👨‍💻

Vertical Devs - Helps Them saving times & efforts

They mostly use it to checking core component availability & capability quicker when grooming & sprint planning so they don’t have to:

• Render the code manually to see the preview (takes about 30-60 seconds)
• Ask someone on DM or slack channel

“It’s core component right?

I wonder is these variant of component is already available or not?

​

it says here it’s name is “coachmark”�Let’s try to search it on sample app before I ask anybody about it”

“Aha, I found it! So these variant is available!

​

Now I don’t have to ask anybody about it

�let’s continue searching it on code library!”

Vertical’s Figma File

Sample App

How Exactly Sample App Impact Their Process?

🙋‍♀️

Core QA- Make Them spotting defects easier

Besides helping them to QA the developed core component, it’s also helped us designer spot the defect on the design-side.

QA spotted differences between tech spec and sample app

Tech spec is fixed

It’s Also Have Huge Potential to Non-Users

👨‍🔧

​

Vertical QA - Can help them be more efficient on doing QA

• Vertical QA not using and not aware about sample app
• They not aware which is core component and local component
• After trying the prototype, they find it really helpful which will make the QA process more quicker

“I wonder what this component should behave?

​

Let me try ask related PM and engineers about it”

Vertical QA have concern about core component on staging app

“Alright I already slack them, now let’s wait them to respond”

Sometimes it takes time to getting the answer to search for

Does that mean current sample app is already fulfill Devs & QA’s needs?

Based on those findings,

Let’s try to measure the current sample app’s usability

To answer that question

System Usability Scale (SUS)

A “quick and dirty” reliable tool for measuring the usability through 10 item questionnaire with five response options for respondents; from Strongly agree to Strongly disagree.

​

Benefit of SUS method :

• Is a very easy scale to administer to participants
• Can be used on small sample sizes with reliable results
• Is valid – it can effectively differentiate between usable and unusable systems

It’s Actually Quite Good!

After conducting and calculating it, the result is…

Let’s try dive more deeper on these to see what we can do better!

Devs & QA heavily rely on TDS component’s name they see or remember which make them struggle to searching desired component easily

Finding

1. Devs & QA not exactly remember all the component’s name, it really depends on their memory or what they see on Figma.
2. Most of Devs & QA using search bar to find a components they’re looking for
3. Sometimes Devs & QA have a different knowledge of component’s name which current sample app search capability unable to cover it

“

Observation

(Typing “switcher” but there’s no result, typing “toggle” also no result) �huh, maybe the listed name here is different from what I know”

- Joseph

“

“Sometimes there’s no hint of component’s name in Figma which makes me need more time and effort to guess name on the sample app”

- Ernest

1. Findability Issue

Improper designed component pages makes it hard for Devs & QA to understand TDS component’s information and capabilities

Finding

• Overall, devs & QA can easily understand the properly design component page
• Improper designed component page makes Devs & QA overwhelmed because not having the same structure and pattern like the properly design component page
• Properly design component page that can be customizable is very crucial to core QA which will have them to spot defects easily

“

When I try to search for a “phone number” component, I got confused with all these scatter components all over the page. There’s not even a clear information for what this component component capable of - Joseph

“

“There are still a lot of pages which component can be modified to test all the permutations which lead to higher risk to a potential unspotted bug” - Prabhleen

2. Information Display Issue

Improper designed component pages makes it hard for Devs & QA to understand TDS component’s information and capabilities

2. Information Display Issue

Properly Designed Component Page

Improper Designed Component Page

Customized component

Customize control

Components permutations scattered all over

No information about states and variants name

Bad visual distinction and placement design elements makes Devs & QA takes extra time to understand the information on component’s page

Finding

• A lot of Devs & QA didn't realize they have to press “apply changes” button to show the customized component
• Devs & QA didn’t aware which one is the “canvas” and which one is “customize control”

“

“I’m confused why the dialog button that I customized earlier didn’t show up, then I just realized there’s an “show dialog” button on the bottom that I have to press”

- Julita

“

“I just realized that the button on the top is the component that I customized, I guess that’s why I got confused when looking this page for the first time”

- Ernest

2. Information Display Issue

Major Issue

Minor Issue

Cosmetic Issue

Extreme Issue

Prevent the completion of task

Create significant delay & frustration

Create delay to complete task

Point to a potential enhancement only

Legend

Summary

Findability and information display issue on current sample app bothers Devs & QA to easily discover TDS component informations

How Might We

Enable Devs & QA to discover

TDS component information

effortlessly through sample app?

Based on those findings,

Potential Solution

2. Information Display Issue

1. Findability Issue

2. Visually Predictable (lowering learning curve)

1. Relevant Keyword (better search result)

Outcome :

Devs & QA can find component they looking for based on they’re knowledge capability

Outcome :

Devs & QA can quickly understand TDS component’s information and get familiar pattern throughout other pages

Create design pattern as a foundation

2. Visually Predictable (lowering learning curve)

How we make it visually predictable?

Title

Pain Points :

Improper designed component pages makes it hard for Devs & QA to understand component’s information and capabilities

Code name and alias will make it findable

Clear distincted component canvas

Predictable customize control

Sticky render button when scrolling

Pain Points :

Bad visual distinction and placement of design elements makes Devs & QA takes extra time to understand the information on component’s page

2. Visually Predictable (lowering learning curve)

*The shown UI only act as representation of current potential solutions ideas. May needs more refinement from discussion and iteration.

Proper Sample App Design Hand-Off Documentation

2. Visually Predictable (lowering learning curve)

How we will execute it?

Organized Flow, Consistent Result Every Time.

2. Visually Predictable (lowering learning curve)

TDS Tech Spec

Sample App Design Pattern

Sample App Design Handoff Documentation

How we will execute it?

Putting Component Alias Name

How we make search result more relevant?

1. Relevant Keyword (better search result)

Main Title

Component’s Image Thumbnail

Code name and alias

Findings :

Devs & QA not exactly remember all the component’s name, it really depends on their memory or what they see on Figma.

*The shown UI only act as representation of current potential solutions ideas. May needs more refinement from discussion and iteration.

Whether By Skimming or Searching, You’ll Find

them easily.

1. Relevant Keyword (better search result)

Pain Points :

Devs & QA heavily rely on component’s name they see or remember which make them struggle to searching specific component easily

Before

After

*The shown UI only act as representation of current potential solutions ideas. May needs more refinement from discussion and iteration.

Devs still didn’t have a complete visual “how the TDS component code is structured” even though they already see sample app

“

“Even though I already saw the sample app, I still have no clear idea how core team structure the code”

- Ernest

“

“ I hope core have a code documentation that I can copy which will also easier to implement it on android and ios consistently”

- Michael

Further Improvement Opportunities

For Devs

QA still often miss on checking padding & spacing when inspecting developed component

“

“When doing QA I usually miss on font size, spacing, and padding”

- Julita

“Unfortunately on android, I can’t checking padding and spacing on sample app which in IOS I can do it using flexes”

- Prabhleen

For QA

“

We already on the right track!

Mas Aufaa

I need sample app design for TDSVoucherCard this afternoon

Is the design already done?

Properly designed TDSVoucherCard Sample App

is Now Available on Android (and soon on IOS)

Where are we right now?

1. Finalizing more proper final solutions based on these research
2. Design team will try provide sample app design along with tech spec if there’s an improvement opportunity especially on grooming

What’s Next?

Action Items

Before

After

Improve Sample App -> Ease Devs & QA workflow

-> Reduce # of defects and potential confusion on core components

​

​

Least search result

Inconsistent throughout pages

Scattered components variants

Better search result!

Predictable pattern throughout pages!

Clearer information display!

Thank you!

Design System Team

Design System