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

推荐订阅源

D
Docker
爱范儿
爱范儿
Vercel News
Vercel News
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Martin Fowler
Martin Fowler
博客园 - 司徒正美
大猫的无限游戏
大猫的无限游戏
酷 壳 – CoolShell
酷 壳 – CoolShell
T
Tailwind CSS Blog
Blog — PlanetScale
Blog — PlanetScale
博客园 - 【当耐特】
人人都是产品经理
人人都是产品经理
F
Fortinet All Blogs
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - Franky
T
The Blog of Author Tim Ferriss
Y
Y Combinator Blog
Recent Announcements
Recent Announcements
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google DeepMind News
Google DeepMind News
H
Help Net Security
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
G
Google Developers Blog

人人都是产品经理

为什么你的产品找不到差异化?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迎来强劲对手 – 人人都是产品经理,
ToG产品设计必备!九大原则助你打造卓越产品(收藏版)
武林 · 2024-02-27 · via 人人都是产品经理

G端产品的产品设计也需要考虑多个方面,比如做好安全设计、贴近客户需求等等。这篇文章里,作者就总结了To G产品设计的几大原则,不妨一起来看看,或许会对你有些帮助。

产品经理,这一角色,既是产品的缔造者,也是团队的领航者。他们不仅肩负着产品的成败,更对投入其中的每一位团队成员负有深重的责任。产品设计,作为承上启下的关键环节,其重要性不言而喻。

产品设计,这可是个技术活,得有点“承上启下”的本事。对上,得搞定那些挑剔的用户,让他们心满意足;对下,还得指挥那些“程序员大哥”们,告诉他们怎么干活。

鉴于产品设计的重要性所在,分享一些我在产品设计中会去思考和把握的几点原则。

一、安全规范第一,体验效率第二

在G端产品的江湖里,信息安全与规范犹如高悬的达摩克利斯之剑,时刻提醒我们:安全规范第一,体验效率第二。

为何这么说呢?你想,若是产品出现安全漏洞,那不就是数据丢失这么简单,搞不好你和公司都得吃不了兜着走,从此“退出”江湖。

所以呀,设计G端产品时,我们得像巧手的匠人一样,先打造一副坚固的铠甲——安全体系。穿上这副铠甲,我们才能放心大胆地去追求所谓的“如丝般顺滑”的用户体验。

G端产品可以从以下三个方面去做安全设计:

  1. 登录安全,即限制用户登录。什么人可以登录,什么人不可以登录。比如登陆时采用:账号+密码+随机校验码+短信验证码+Ukey中的多种认证方式进行登录。
  2. 界面安全,不同职责人员所需要查看或编辑的页面不相同。比如通过对职责分配不同菜单功能权限来满足要求。
  3. 数据安全,在网络环境下安全高效的运行,避免数据丢失和被盗取。比如数据传输采用https安全传输方式进行数据传输,且尽可能使用post、get等安全的请求协议,同时对请求内容请求端加密,服务端解密的操作。

二、国产化适配要做成产品的标配

政府部门都是配备有涉密内网和工作网,部署在涉密内网的系统要过分保,部署在工作网的系统要过等保。

除了国产化环境下的数据安全,还需要考虑到异常操作下的数据保全。

举例来说,我之前做的一个业务系统统就遇到一个问题,因为产品对操作过程中的硬件设备的异常情况兼容性没有做到充分考虑,导致客户丢失了办案过程中的音视频数据。

总结来说,这就要求你在做产品设计的时候,需要对产品提前进行国产化环境的适配,分保等保的测评,异常情况的兼容性处理。

当一款产品完成开发上线之前,可以要求测试人员在国产化的环境中做一遍兼容性测试。

三、商业化的安全必须要设计齐全

软件产品不同于硬件产品,可以做到每套设备的单独发货,不存在产品被copy复制的风险。

软件产品的发货主要是提供一个安装包或账号地址,这样就需要在商务上多做一道功能设计,避免产品轻易被别人窃取,或不受控制影响到产品的正常销售。

因此,在产品设计之初就需要基于商业场景的考虑,做好如下几点的产品设计:

  1. 用户授权机制——即通过授权码或激活码的形式,限制未购买产品的用户使用;
  2. 服务到期机制——当产品试用到期或服务到期之后,就得增加服务到期的提醒或不能继续使用的限制;
  3. 账号权限机制——对于涉及到功能菜单、多级账户、一号多开、多账号并发、系统名称显示等配置权限,必须要进行初始化配置,不能允许客户自行配置。

举个反例,当初我们在做某系统的时候,刚开始着急推出来的版本,并没有激活码这个机制。这样就导致代理商拿到公司的软件安装包之后,可以不经过公司授权就卖给多个客户同时使用。

四、具有为用户设计产品的思维意识

产品设计的时候我们始终要保持一个意识,那就是我们是在为我们的用户设计产品,我们所设计的东西需要用户能够容易感知,容易理解,容易操作。

我们是在设计一个产品,而不是在设计一个艺术品,没必要去追求局部细节的尽善尽美。

要站在用户的角度考虑,如果按照眼前的产品设计开发出来的产品,是否能够帮到他们解决问题,是否能让他们的工作变得更简单,是否符合他们的审美和操作习惯。

在此基础之上,如果我们的设计能够从美感、技术高度、独特性上给用户带来冲击,那么这样的设计就更容易赢得用户的赞许。

五、把握住产品需要满足的业务属性

产品设计始终要围着业务转。

To G产品本质上应该紧贴客户业务需要,让原本效率慢的快起来,让原本流程繁琐的简单化,让原本无法完成的变得可实现。

因此,To G产品设计无论用怎样花哨而又高大上的技术、流程、方法去实现,都不能离开业务的初衷,也就是原有模式里核心业务。

新产品可以向业务的上下游拓展边界,也可以合并或优化核心业务,但不能无缘无故的删减或者捏造核心业务。这样会偏离客户的需求,导致产品被客户“唾弃”。

把业务抽象出来的根本属性,就是四个字——“供需关系”。

任何一个组织机构的业务模式抽象出来,无非只有两种:上级发布命令并审核推进情况。下级执行任务并反馈完成情况。

所以我们可以简单的拆分下:最上层领导,关注的是事情被推进的情况及对结果进行评估,于是需要任务审批、数据统计和异常预警等监督功能。而基层人员,自然是关心事情是否能高效完成以及是否能解决业务问题,于是需要流程化的业务开展,自动化的数据录入,智能化的任务处理等执行功能。

为此,我们可以清晰的整理出在产品功能设计上的两个必须有的属性:监督与执行。

六、别忽视掉用户的年龄层次和文化水平

做产品首先还是得搞清楚使用我们产品的用户是谁,用户的画像长什么样。

就G端产品的用户来讲,有浸泡着互联网发酵罐,熏陶于开放创新文化氛围下成长起来的90后检察官,也有被迫跟随着互联网时代潮流,裹挟着适应信息化工作的60后领导。有懂技术、懂产品、懂设计的信息技术部门的工作者,也有不懂APP是啥,不会拼音输入法,不知如何定位签到扫码的辅助工作人员。

文化水平的高低考验着我们的产品在页面文案描述上的呈现功力。太通俗会觉得没水平,太高逼格会觉得不接地气,为此还得尽量贴近他们的现实工作场景。

人员年龄层次的差异决定了界面设计的色彩搭配和字体的大小要灵活应对。当人员年龄偏大时一定要加粗加黑加大显示页面信息;当人员年龄偏年轻化时,要多考虑页面搭配的时尚化,字体、字号、字色、背景等要体现出明显的层次感。

七、不要自行脑补应该遵从用户

有一种死的很惨的产品,不是功能做的不全,反而是需求做的太多。TOG市场最大的特性就是:教育市场这件事,企业根本做不了,也做不到。

有些产品经理做出来的产品,存在明显的“过度规划,超前设计”的问题。

因为没有和客户进行需求的调研,或调研需求过程中对于一些细节掌握的不全,在产品设计中只能自行脑补业务流程,为此带来很多非必要的、不实用的、不合理的过度设计。

原本客户的业务规划只完成了50%,但你的产品却做了90%。很多客户连业务规则都还没有想好,却要他去用你给他设计的“大而全”的产品。

客户一定不会因为你做的产品“包天包地,包山包海”而点赞,只会因为这个产品给他带来额外的工作负担而反感。

那么,应该如何去避免呢?

很多时候用户并不能很清楚地告诉你准确的需求点,而是提供一堆散乱无序,深浅不一,甚至前后矛盾的想法。你要做的就是原封不动地记录下这些内容,从这些内容中,你可以标记出他们所提及的关键词句,通过分类和归纳找到用户最关注的核心内容以及要完成的关键任务。最后,通过这些关键的内容和任务串联出整个业务流程。

对于业务流程不清楚的地方,千万不要自作聪明、自以为是、自行脑补,唯一的办法就是去问用户。

八、可做可不做,最佳选项是不做

在很多东西不确定的情况下,我们应该将精力投入在不断挖掘确定性的东西上。通过抽象、归纳和总结找出主要的流程和核心的目标。

对于确定要做的东西进行优先设计,对于可能存在变化的部分尽可能简化设计,对于不确定的需求就暂且不考虑功能设计。

为什么要这样做呢?

因为,产品功能上线后,不可随意的下线,即使只有20%的用户在使用这个功能,下线也会造成严重的后果。但没有的功能,却可以很容易上线,即使只有20%的用户使用了新上线的功能,也不会影响到其他80%的用户。

有一点你要明白:当我们的用户越多,功能就会做的越多,用户在产品里面用不到的功能也会越多。结果产品会变得越来越臃肿,客户就会觉得越来越不好用。

新产品设计在满足客户核心业务的基础上,多做10%的探索就足够了。其他的功能设计可以写进建设方案里,尝试用建设方案的形式和客户做可行性的探究。

待其印刷到纸面上,你再落实到产品上。

九、强调复用前提是产品足够有用

在产品功能设计和数据表结构设计上,有些产品经理喜欢去做一些通用模型的抽取,美其名曰“考虑将来的复用性”,但也正因为过于强调复用而陷入了产品的过度设计。

当产品没有被大规模的使用,没有在市场上得到客户验证有用,去做功能复用的设计只是徒增成本费用。

新产品第一阶段的设计所要完成的是总体框架的清晰完整,业务流程的全面规范,功能界面的合理布局。

产品复用性设计的越多,产品研发需要投入的人力成本就会越大,产品上线的时间周期也会变得越长。

而大部分情况下,G端产品或项目都是提前锁定了合同金额,想要通过增加产品功能来让客户额外掏钱,几乎是不可能。所以,复用设计带来的产研成本的增加,只会转移到产品或项目的利润缩减之上。

还有一个不能忽视的问题,对于大部分客户来讲,并不具备产品思维,因此很多时候也就不知道自己想要什么功能,希望产品做成什么样子。也许客户在使用了一段时间的产品之后,才知道自己想要的,那么你在产品初期所做的复用性设计都将变得一文不值。

产品的打造是一个持续迭代的过程,“先有再优”的思想应该贯穿产品设计的始末。

最后的话

要成为一个优秀的产品经理,一定要有产品设计不可逾越的原则。

为什么你知道的理论很多,我写出来的东西一看不懂,不看也知道,但还是在做产品的时候不会运用到这些原则。那是因为,你摔过的坑还不够,你掉进了坑里却不知道原因在哪里。所以,还会在相同的问题上再次掉进去。

本文由@武林 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

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