惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
Recent Announcements
Recent Announcements
GbyAI
GbyAI
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Microsoft Azure Blog
Microsoft Azure Blog
N
Netflix TechBlog - Medium
人人都是产品经理
人人都是产品经理
MongoDB | Blog
MongoDB | Blog
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
WordPress大学
WordPress大学
U
Unit 42
腾讯CDC
D
Docker
The GitHub Blog
The GitHub Blog
阮一峰的网络日志
阮一峰的网络日志
Vercel News
Vercel News
I
InfoQ
Jina AI
Jina AI
爱范儿
爱范儿
宝玉的分享
宝玉的分享
博客园 - Franky
G
Google Developers Blog
P
Proofpoint News Feed

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
这些细节设计SaaS系统务必要统一
吴之猫 · 2024-05-28 · via 人人都是产品经理

在做产品设计时,我们都知道要保持一致性才能让我们显得更专业。那这个一致性,包含了哪些东西?都有哪些细节?作者给我们分享了Saas产品都需要统一哪些信息,可以让我们的设计看起来更专业。

满足用户业务流程的需要是B端SaaS系统设计的首要目标,也很容易在一些细节设计上没有C端产品那么严谨。

而且一些庞大的SaaS系统需要多位产品经理协作完成,很容易在一些基础术语命名和细节交互上不一致。

虽然这些细节不会影响系统功能的使用,甚至一些用户对此都不敏感。但是作为逻辑严谨的产品经理,以下这些细节设计一定要在系统层面保持统一,最好作为系统级的产品规范来要求。

一、通用操作按钮命名统一

(1)“增删改”操作按钮

“增删改”我比较习惯的命名方法是新增、编辑和删除。

新增:还有叫添加、创建的比较多。

编辑:通常还可以叫做“修改”

删除按钮一般没有别的名称。

(2) 内容保存和取消按钮

对于内容保存的操作按钮,我比较习惯使用“保存”和“取消”的叫法。有的系统不叫做“取消”,叫“返回”。

(3)二次确认框操作按钮

操作的二次确认框的按钮,常用的有“确认/取消”、“是/否”、“继续/返回”等,个人比较推荐“确认/取消”的组合。

(4)停启用状态及操作按钮

停启用的状态及操作按钮,普遍统一使用的是“启用/停用”。有时候我们会看到有有些系统的状态叫“启用中”、“生效中”、“在用”等。“停用”的状态也叫作“已停用”、“停用中”、“已禁用”等。

(5)查询按钮

我个人偏爱“查询”,还有叫作“搜索”、“检索”、“查找”等。

(6)登录/退出

还有比较常见的是“登入/登出”。

二、数据字段命名统一

(1)日期 vs 时间

XX日期和XX时间的栏位命名,建议采用以下原则:

内容只显示日期的栏位叫“XX日期”:e.g. “就诊日期:2021-3-26”;

日期加时间或者只显示时间的叫“XX时间”:e.g. “就诊时间:2021-3-25 15。

(2)类别、分类和类型

在标准词语的释义上,这三个词各有侧重点,这里我只介绍一下我个人的理解和使用习惯。

类别和分类在词义上就明确的将事物进行归类的意思,相对来说类型只是强调事物的共同点和特性。类别强调将事物按照某种标准进行归类,分类则只要按照某种逻辑进行归类就可以。

我个人使用的话,如果有确定的标准,则用类别;如果不是依照某种标准进行的归类,则用分类;在已有类别和分类之外,需要按照其他特性进行区分,则使用类型。所以我个人基本上是按照类别>分类>类型的顺序在使用。

(3)同意/批准/通过、拒绝/驳回/不通过

这些按钮都是在审批流程相关的功能经常用到的。根据需要审批的业务场景,特定的描述可能更加合适。

但我个人倾向还是在术语上进行统一,比如我基本上会使用比较通用且语义上比较柔和的“通过/不通过”。

这样的好处是在做报表和数据分析时,不需要先对这些描述进行对照,直接根据这两个状态值就对整个系统的流程结果进行筛选。

三、专业术语统一

所做的SaaS系统是哪个专业领域,对应的专业术语一定要准确和统一。拿我熟悉的医疗系统举个简单的例子,最常用的“医生”字段,我们不能出现像“大夫”、“专家”、“治疗师”等通俗表达,而且在职称和官方表述中都使用“医师”。所以在系统层面最好统一使用“医师”。

四、页面命名规范统一

页面的命名,建议遵循以下两个原则:

(1)业务功能页面直接以业务本身命名:“西药字典”、“出差申请”,以名词或者动宾结构为宜。

(2)维护界面:单纯的数据维护功能界面叫“xxx维护”,带有其他功能的综合性功能界面可以叫“xxx管理”。

五、基础交互统一

(1)查询:下拉框筛选选项,条件为空时查询全部 or 选择为“全部”选项时查询全部数据。

(2)查询:查询条件是都有单独标题 or 统一使用暗提示。

(3)操作:哪些状态变更操作需要有二次确认框,系统需要有统一的规范,一般包括删除、启用、停用等。

提示语可以采用通用的文案,这样也就不会因为页面其他元素的调整而需要调整提示框文案。例如:请确认是否要删除所选内容?

专栏作家

吴之猫,微信公众号:有不知,人人都是产品经理专栏作家。健康管理小硕,医疗健康产品汪+文艺猫。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。