UI/UX 指南
本文将 Apps in Toss 小程序进行设计和开发时需要遵守的 UI/UX 标准汇总在一起的指南。
从品牌 Logo·名称·颜色的设置方法，到防止暗黑模式、UX 文案原则、图形资源使用方法、分辨率设计标准等，都会按顺序进行说明。请在服务上线前仔细确认并应用每一项。
如果未遵守标准或确认存在暗黑模式，审核将不会通过；即使在上线后才发现，也可能会限制服务曝光或中止服务。
小程序品牌指南
这些标准是为了让 Apps in Toss 服务能够传达出与 Toss 明确区分的品牌体验而准备的。它是防止用户将 Toss 与 Apps in Toss 混淆的重要标准，请务必阅读并遵守指南。
1. 品牌 Logo / 名称 / 颜色
通过在 Toss 和 Apps in Toss 界面的各处展示品牌 Logo、品牌名称、品牌颜色，让用户能够清楚地识别品牌。
品牌 Logo
合作方的 Logo 会显示在总览页、权益页、推送、通知、导航、桥接页。请务必使用下方附带的图片或插画文件制作 Logo。
制作和应用 Logo 时，请遵守以下标准。
尺寸必须是 600×600px 的直角正方形。不能使用圆角形式。
Logo 后方必须有背景，并使用在浅色模式和深色模式下都清晰可见的背景色。
如果像 Anipang 那样 Logo 自身已经包含背景，则请将图片完整铺满 600×600px 区域。
请将 Logo 文件上传到 Apps in Toss 控制台，并在
granite.config.ts文件顶部的appsInToss函数中brand.icon属性里输入相同的 Logo 链接。
品牌名称
品牌名称会显示在总览页、权益页、推送、通知、导航、桥接页。除非有特殊原因，否则请使用韩文书写。比如 Toss可以，但 Toss不建议这样写。
请在 Apps in Toss 控制台中输入品牌名称。
granite.config.ts文件顶部的appsInToss函数中brand.displayName属性里输入相同的品牌名称。
品牌颜色
品牌颜色会用于 Toss 内入口、桥接页、按钮（使用 Toss 设计系统时）等。品牌颜色的设置标准如下。
如果已经有品牌颜色，就直接使用。
如果没有品牌颜色，就选择 Logo 中使用最多的颜色。
如果难以决定， 取色网站也可以用来从 Logo 图片中提取代表色。
如果品牌颜色不符合色彩对比标准，会在尽量保留现有颜色的基础上自动校正。
granite.config.ts文件顶部的appsInToss函数中brand.primaryColor属性中#请输入包含“#”的六位十六进制代码值。例如#3182F6这样输入。
2. 导航栏
导航栏是固定在屏幕顶部的区域，提供 Apps in Toss 专用组件。请根据入驻服务的类型，参考下方指南设置导航栏。
游戏指南
非游戏指南
3. 标签栏
标签栏不是必需组件。不过如果需要标签栏，必须使用 Toss 提供的浮动式标签栏并自行实现。
即使使用自有 UI，标签栏也请按照提供的形式实现。因为如果与 Toss 主界面的默认底部标签形式重叠，用户可能会混淆自己当前所处的位置。
设置标签栏时，请遵守以下标准。
标签数量最少可为 2 个，最多可为 5 个。
必须保持 Toss 提供的浮动形式。
防止暗黑模式政策
Toss 用户期待无论在哪里都能获得一致且可信赖的使用体验。如果每个服务的标准都不同，用户就会感到混乱，这可能导致对整个服务的信任下降。 UX 指南并不是为了限制创造力而制定的规则，而是为了向用户提供可预测且便利体验的最低标准。
为此，Toss 制定了必须遵守的最低使用体验标准，下面的案例都属于偏离该标准的严重可用性错误，因此无法作为 Apps in Toss 服务上线。
1. 一进入服务就弹出底部弹层的情况
服务一打开，用户看到的不是预期画面，而是 遮挡整个屏幕的广告型底部弹层出现的情况。 请求通知同意的底部弹层也包含在内。
用户在进入服务的瞬间，就期待能够立即执行自己意图中的目标。 这时如果出现意料之外的干扰，就会打断沉浸感，并提高用户直接离开的可能性。
2. 点击返回按钮时，弹出阻止返回上一页的底部弹层的情况
用户正要返回上一页、探索其他服务的瞬间，出乎预料地 弹出引导同意通知的底部弹层的情况。
为了阻止流失而刻意设计的额外干扰，会让用户觉得自己的自主性被侵犯。这种体验会降低用户对服务的信任。
3. 没有可退出选项的情况
指除了选择合作方引导的 CTA 之外，用户没有其他选择的结构。像这样无法拒绝的设计，可能会让用户感到被强迫。结果很可能引发对服务的反感与不信任。
4. 在意想不到的时刻展示广告的情况
用户为了领取道具而点击菜单，却出乎预料地 出现全屏广告的情况。
在使用流程中突然出现的广告会妨碍沉浸感，也可能给服务和品牌留下不愉快的印象。
5. 仅看 CTA 按钮无法预测下一步行为的情况
把屏幕上已经说明的价值原样重复到 CTA 中，导致无法看出点击按钮后会进入哪个画面或产生什么行为。
CTA 是清楚告知用户下一步要做什么的装置。如果按钮标签含糊不清，或只是重复说明，用户就无法预测点击结果，从而感到不安。这种不安会让人犹豫点击，最终可能导致转化率下降。
此外，如果在 CTA 上方同时显示夸张或重复的辅助说明，也会模糊按钮作用，并给用户带来混乱。
UX 文案
本指南旨在提供可应用 Toss App 语气风格的文案指引。 请遵守以下指南。
1. 해요体
产品内的所有文案都使用“해요体”。 为了营造一致的用户体验，无论场景和上下文如何，请将 해요体 应用于所有文案。
2. 主动表达
请尽量在产品内使用 主动句。被动句最好只在特定场景下使用。
好了 → 完成了
去掉“~었”
改写动词
3. 积极表达
请尽量减少产品内的负面沟通，使用正向句式。例如：不行、没有（X）→ 只要……就可以（O）
没有 → 有
错误消息
无法获得权益时
权益对象说明
服务可以使用，但无法获得某些权益时 → 正向句式 用户很容易因为扫描而误以为整个产品都不能使用。
4. 轻松的敬语
产品中“~시겠어요?', '시나요?', '~께”之类的过度敬语不要使用。尽量使用更轻松、亲切的语气。
动词去掉“~시”
'在场（敬语）’ → ‘有'
'询问’ → ‘确认, 问'
'给（敬语）’ → ‘给'
去掉敬语后显得别扭的情况
在获取用户信息的问题中机械地去掉“~시”时，句子可能会显得别扭。
试着把想了解的信息作为“主语”重新写句子。
5. '{名词} + {名词}不要使用“
汉字词展开写法
汉字词名词可以拆开写成动词形式。
如果汉字词难以展开书写时
'{名词}因为{名词}而”这种形式也会更口语化。
例外规则
图形
为你介绍 Toss 提供的图形资源及正确使用方法。
Toss 提供的图形资源
1. 图标 & 表情符号
Toss 提供约 7,000 个以上的图标和表情符号套装。在 App Builder 和 Figma 中进行设计时，可以查看图标和表情符号列表。App Builder 可以在工作区中 注册应用后 从“设计”菜单开始。若需要自行制作图标，请参考 Apps in Toss 图标制作指南并按照标准制作。
[使用时注意事项]
请将图标在屏幕中以 24~40px 的大小使用。
不建议将两个以上图标或表情符号并列组合使用。请一次只使用一个。
Toss 提供的图形资源仅可用于服务界面内的 UI 设计，不能用于应用 Logo、缩略图等应用信息中。
2. 智能手机 mockup 文件
使用智能手机 mockup 制作资源时，请直接使用上面提供的文件。图标按尺寸提供，请不要自行裁剪、校正颜色或扭曲形状。
3. Toast（AI 图像生成工具）
可以基于第 1 项提供的图标和表情符号生成 3D 图像。生成的图形在实际画面使用前，需要先获得 Toss 图形设计团队的使用批准。批准通常会在 1 天内完成。
4. 其他
3D 图形或动画只能使用 Toss 提供的模块中包含的资源。 提供范围今后会逐步扩大。
图形的正确使用方法
1. 请使用符合上下文的图形。
图形不是装饰，而是帮助用户更容易理解画面含义的角色。
2. 请按信息密度使用合适的大小。
简单的图形请小一点，细节较多的图形请充分放大使用。
3. 不要在一个画面中使用过多图形。
类似大小的图形越多，视线就越容易分散。 请只使用一个最核心的图形，其余用辅助图形或图标替代。
4. 请避免遮挡关键信息。
请调整大小和位置，避免重要内容被推到下面而产生不必要的滚动。
5. 请避免负面或诉求式的情感表达。
让用户感到不快，或像在乞求、诉求的表达都属于暗黑模式。 请不要使用这类情感表达。
6. 不要使用装饰性效果或特效。
没有意义的描绘、粒子效果、过度渐变等元素会让画面变得复杂，并妨碍信息传达。
7. 请使用能准确传达情境的图形。
在非错误场景中使用感叹号图标，或者 明明不需要等待却使用加载动画时，用户可能会误解情况。
合作方自行制作图形时的注意事项
1. 请保持 Toss 风格的一致性。
Toss 崇尚简洁、明快、干净的数字图形风格。 抒情画风、漫画式表达、手绘感在画面中可能会显得格格不入。
Toss 的图形风格示例
2. 请使用高画质图形。
请制作清晰、干净的高画质图形。如果分辨率太低，或者粒子等细碎效果太多，可能会显得质量不高。
3. 在深色模式和浅色模式下都要清晰可见。
Toss App 中使用的图形必须同时考虑深色模式和浅色模式。 过亮或过暗的颜色在某些模式下可能不容易看清，因此请使用中等明度的色彩。
4. 请让它与整个画面协调一致。
为避免图形比文本或 CTA 按钮等其他元素更抢眼，请平衡整个画面的颜色和布局。
5. 请呈现积极且整洁的印象。
图形在营造服务的稳定感和信赖感方面非常重要。 请避免过多单色、朦胧且暗沉的印象，尽量设计得明亮、整洁。
分辨率
本指南将说明在开发 Apps in Toss 小程序时，应以什么分辨率为基准来设计和优化界面。我们会说明推荐标准，以及在各种设备环境下也能稳定运行的设计方向。
Apps in Toss 小程序会在多种分辨率和屏幕比例的设备上运行。为了减少这种环境差异带来的混乱，本指南提出以“基准分辨率为中心”的设计方式，而不是按设备逐一适配。
Apps in Toss 小程序全屏设计标准
Apps in Toss 的游戏小程序必须实现全屏。在全屏环境下，请务必考虑以下几点。
内容必须完全铺满屏幕。
不应留下 WebView 留白或半透明区域。
不能因为设备旋转而导致比例错乱或出现 letterbox（黑边）。
刘海、摄像头孔、Dynamic Island 要按 Safe Area 处理。
缩放后资源质量不应明显下降。
因此，与其按设备分别调整分辨率，不如确定一个基准分辨率，并通过缩放来应对。
看待分辨率的两种标准
在 Apps in Toss 小程序中，建议把分辨率分为以下两类来理解。
① 逻辑分辨率（Logical Resolution）
是 UI 布局、坐标计算和游戏逻辑的基准分辨率。
它与实际设备像素分辨率是不同的概念。
建议只选择一个逻辑分辨率。
所有设备都应保持相同的游玩手感和画面构成。
② 资源分辨率（Asset Resolution）
指图片、背景、角色、UI 资源的像素密度。
无需为每台设备单独准备资源。
采用少量分辨率组进行管理会更高效。
Apps in Toss 推荐分辨率标准
① 逻辑分辨率推荐范围
请从以下范围中选择一个作为基准分辨率。
竖屏小程序： 约 360 × 640 ~ 420 × 740
横屏小程序： 约 640 × 360 ~ 740 × 420
建议在这个范围内确定一个基准分辨率，并通过缩放应对设备间差异。
② 资源分辨率推荐标准
建议按组准备资源。
1x 资源：对应基础分辨率
2x 资源：对应高分辨率设备
只有在图形质量特别重要时，才选择性追加 3x 资源。
基于数据的参考说明
本指南基于 在 Apps in Toss 实际服务环境中收集到的设备分辨率数据整理而成。
整个小程序流量中约 70~80% 为横向约 800~900，纵向约 360~420 范围的 viewport 分辨率占比较高。
其余流量则以分散在各种分辨率中的长尾形态为主。
因此，与其逐个适配所有分辨率，不如以代表性分辨率范围为基准进行设计，这样最有效率。
测试设备指南
无需在所有设备上测试。满足以下条件的 3~5 台代表性设备就足够了。
2~3 台屏幕比例不同的设备
1 台需要较大程度应用 Safe Area 的设备
1 台屏幕尺寸相对较小的设备
不建议的方式
请避免以下方式。
按设备型号使用不同逻辑分辨率的方式
以实际像素分辨率计算 UI 或坐标的方式
运营过多的资源分辨率组的方式
在不同分辨率下维持不同 UI 布局的方式
这种方法可能会导致 UI 破损、出现黑边，以及维护成本增加。