toss-tech-design

Applying Toss Tech Design

Overview

Treat Toss design not as "making things pretty" but as an operational discipline that includes problem definition, research operations, internal tools, UX Writing, accessibility, brand, and trust.

This skill is sources/toss-tech-design-summary.md an execution guide for quickly applying the core principles of the summary preservation copy. If you need detailed grounds, cite this summary preservation copy directly, and if confidence is low, prioritize the grounds in the summary preservation copy over generalization.

When to Use

• When designing or reviewing flows with high cognitive load, such as finance, payments, authentication, and onboarding
• When you want to turn research from one-off validation into an operating system
• When you want to structurally reduce repetitive manual work, legacy workflows, and internal tool inefficiency
• When you want to make UX Writing, error messages, and guidelines into a system rather than a matter of individual capability
• When you need to redesign actual failure points for accessibility, foreign users, seniors, and screen reader users
• When you need to treat brand, graphics, and interaction as problems of cognition, trust, and immersion rather than decoration

Do not use this skill when:

• When you want to imitate only Toss's visual style
• When the work is only polishing the visual appeal of a screen without defining the problem
• When you want to make guesses like "this is what Toss would do" without grounds in the original text

Core Principles

1. Do not handle a large process as is; break it down into action units.
2. Ask "why is this needed?" for each action, and separate what to remove from what to automate.
3. Set priorities based on the resources and context of all stakeholders, not your team's convenience.
4. Prefer small tests and incremental application over a complete solution.
5. Research is not interview outsourcing but infrastructure for problem definition and context translation.
6. Product Design focuses on redesigning the problem structure rather than adding features.
7. Design systems, internal tools, and writing guidelines are measured and improved like customer products.
8. Accessibility is not a checklist but a core usability problem that determines whether something is actually usable.
9. Visual elements and interaction are not decoration but devices that increase cognitive speed, trust, immersion, and understanding.
10. Prioritize trust over conversion pressure, and avoid copy that pressures or deceives users.
11. To learn a domain quickly, do not estimate from your desk; go into the field and the context of users' daily lives.

Working Method

1. Redefine the problem
   Find the structural problem behind the surface problem the user experiences. Do not accept feature requests as is; first redefine "what is blocked."

2. Break the flow into action units
   Break it down not into large steps but into actual action units. Example: selecting a date, adding attendees, attaching a link, changing visibility.

3. Ask the reason for each action
   Classify each action as one of 유지, 삭제, 자동화, 보조 . At this time, look at it from the perspective of all stakeholders, not your own position.

4. Design the smallest experiment
   Instead of a massive renewal, test starting with the small changes that have the lowest risk and the greatest effect.

5. Look at failure points from the perspective of real users
   Look at it in the context of people who actually get stuck, such as those with accessibility needs, foreigners, seniors, beginners, and internal tool users.

6. Turn it into measurable operational units
   Create an operable state with metrics such as search time, completion rate, error rate, satisfaction, loss of trust, and search success.

7. Promote a single improvement into a system
   Do not stop at documentation for a good solution; turn it into components, templates, libraries, guides, and operational structures.

Domain Lenses

• Research Ops: Reduce the bottleneck for individual researchers and enable anyone on the team to design appropriate questions and read the results.
• Product Design: Create fewer worries, less input, and an easier next action rather than more options.
• Internal Tools / Design Systems: Improve internal tools like customer products based on KPIs, satisfaction, search time, and scalability.
• UX Writing: Good copy is not a matter of taste but a system. Design templates, principles, reduced writing hurdles, and team consensus structures, and avoid wording that pressures or deceives users.
• Accessibility / Inclusion: Rather than adding a separate mode, redesign the existing information architecture, reading order, state communication, and input method themselves.
• Brand / Graphic / Interaction: Judge in the direction of improving cognitive speed, trust, neutrality, understanding of state, and immersion rather than prettiness.
• People / Culture: Design roles and culture not as declarations but as standards, feedback, and onboarding structures.

Execution Modes

• Quick mode: Core Principles와 Quick Referenceonly to present a quick direction.
• Deep mode: Domain Lensesand source evidence together to create a concrete action plan.
• Audit mode: sources/toss-tech-design-summary.mdas well to specify the evidence, limitations, and scope of application.

Output Contract

When applying this skill, if possible, answer in the following order.

1. How to redefine the problem
2. What action units to break it into
3. What to reduce, remove, or automate
4. What the smallest experiment is
5. What metric to use to judge success
6. What to leave behind as a repeatable system asset
7. If certainty matters, what source evidence was used

Quick Reference

Signal	Ask First	Default Bias
Users feel it is complex	Rather than what is difficult, where do they stop?	Reduce options and input
There is a lot of repetitive manual work	If the flow is broken into action units, what remains?	Small automation rather than large automation
Research is the bottleneck	Who can design the questions and read the results?	Make research shared infrastructure
Dissatisfaction with internal tools is high	Has it really become faster, and easier to find?	Measure satisfaction and search time
Copy quality is inconsistent	Whoever writes it, can a certain standard be achieved?	Deploy through templates and systems
There is an accessibility issue	Where do actual users fail to finish on their own?	Task success rate over checklists
Brand/graphic judgment is difficult	Is it recognized faster rather than prettier?	Prioritize trust and recognition speed

Implementation Example

Scenario: The research schedule sharing process is slow and prone to human error

1. Break down the entire flow of sharing a schedule into date selection, adding attendees, attaching links, setting visibility, and writing a message.
2. Ask "why is this needed?" for each action, and distinguish unnecessary steps from steps that can be automated.
3. Re-prioritize based on the resources of all participants, not your own convenience.
4. Apply only a single improvement first, such as automatic invitation of internal attendees, as the smallest experiment.
5. Measure changes in sharing time, number of edits, human errors, and satisfaction.
6. Once the effect is confirmed, promote it into a research operations template or internal tool feature.

Common Mistakes

• Cover up problems with added features without revisiting the structure.
• Start efficiency efforts as a massive project.
• Treat research only as a late-stage validation step.
• Treat internal tools and design systems as auxiliary means.
• Leave UX Writing principles only as a document and do not deploy them as a system.
• Erode trust with conversion-pressure phrasing or exaggerated persuasion.
• Treat accessibility only as legal compliance or a checklist.
• Consume brand and interaction as decorative staging.
• Answer with genericities even when source evidence is needed.

Reference

• For quick application, use this file first.
• Detailed evidence and context for each article are in the sources/toss-tech-design-summary.md summary preservation copy.
• If you need the original article URL, page flow, tag distribution, and extraction limitations, be sure to check the summary preservation copy.