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

推荐订阅源

L
LangChain Blog
V
V2EX
爱范儿
爱范儿
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Martin Fowler
Martin Fowler
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Apple Machine Learning Research
Apple Machine Learning Research
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
宝玉的分享
宝玉的分享
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
罗磊的独立博客
小众软件
小众软件
Vercel News
Vercel News
博客园 - 司徒正美
阮一峰的网络日志
阮一峰的网络日志
V
Visual Studio Blog
J
Java Code Geeks
P
Proofpoint News Feed
MongoDB | Blog
MongoDB | Blog
B
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迎来强劲对手 – 人人都是产品经理,
如何利用设计团队分享提高表达能力
一只鸡腿 · 2023-01-05 · via 人人都是产品经理

表达能力是通用能力,其中团队分享是设计师在日常工作中提升表达能力的重要途径。然而实际工作中,可能会因为各种原因阻碍设计师的表达能力的提升。如何利用设计团队分享,提高表达能力呢?一起来看一下吧。

表达能力是通用能力,其中团队分享是设计师在日常工作中提升表达能力的重要途径,但是在实际工作中设计师同学会遇到缺乏经验/权重太低/没有专门时间做分享等因素,会阻碍设计师的表达能力的提升。接下来将会一点一点展开讲讲怎么解决这个问题。

一、难点

1. 缺乏经验

大部分的设计师常规的工作都是做执行工作,除了中高主管外,其他的岗位很少有进行分享或是总结的机会,导致了一旦是okr任务里面强制安排分享,就没法快速介入和寻找话题。

2. 权重太低

大部分的设计师的工作任务都是执行任务,即使是设计主管在人少的团队中都要自己进行下场做设计,而不是只用做管理。这种情况导致了很多设计师对这种团队分享任务只是象征性质的分享,很难给出一个真正给团队带来有意义的分享。

3. 没有专门有时间做分享资料

一般在工作中不会给设计师留存一个专门做分享PPT的时间,为了完成okr任务就得需要挤压自己的休息时间以及学习时间。如果工作时间是965或者这是双休其实还好,但是如果是996或者是007的话,单休或者是节假日时间基本就没了。最后就导致了出来的分享效果其实并不好。

其实分享效果要看这个主管平日里做不做,如果日常主管不带头做分享,就等着属下做然后等着自己摘桃子的,只能说属下大概率不傻。

二、常见分类

常见设计分享包括知识技能来的分享,项目复盘。

按照分享角色分为:向上汇报和对下分享。

1. 向上汇报

一般向上汇报的场景是主管的述职报告和晋升报告还有针对上级的团队业绩汇报,这个时候是你的上层决定你是否晋升或者是述职成功。

设计的根本是满足用户的诉求,那上级角色关注的诉求是什么?就是要知道一段时间内成绩/业绩,针对向上汇报推荐smart原则(一种目标管理的方法)进行汇报。

Smart原则是现在在管理上面经常用到的一种目标管理,或者说效率管理模型。SMART分别代表了5个单词的首字母,也是目标管理的五大原则,也被称为目标管理的五个维度。——引入百度

smart原则拆解:

S:Specific(具体的)

所谓的明确性是要用道具的语言清楚地说明行为的标准。所以这里的目标一定要是明确的,而不是含糊不清或者是模糊的目标。

假如有这么一个关键结果——“提高用户效率”;每个人对“提高效率”的认知不一样,对于最后的界定也不一样,这样的结果就无法衡量,从而最终无法评估。

但是如果把关键结果设置成“提高用户设置效率”,那么大家对于结果的认知会更加的清晰,从而在后面沟通和实施的场景下效率会更高。

M:Measurable(可衡量的)

目标要具有清晰的衡量性,这里要求目标是是被度量的。制定目标的过程中你要清晰地知道花费的时间以及你能力的边界值到底是多少,这样才能控制完成的进度。要求的目标具有是可以被量化的。

还是以上面的“提高用户设置效率”为例,假设设定为“缩短用户设置从20秒到10秒”,到了最后通过埋点就知道了距离这个时间还有多长时间差。

A:Achievable(可实现的)

目标的核心意义要能够接受且实现,如果是强制安排的目标大概率会引起反作用。这样指定的目标最后会有无限多的推脱的方案。换而言之在制定目标是场景下,你要客观的预估自己能力到底能做到哪一步。换一个说法就是,“目标要现实”。

还是以上面的“提高用户设置效率”举例子,假设设定为“提高用户设置效率200%”,这个目标是是离谱了一点,但是效率一般最多能提高100(200根本完不成)。

R:Relevant(相关的)

指定的目标一定要和上级目标和同级目标相关联,跟上级目标的关联是:上级目标的分支与分解,主要是上级目标的完成的途径之一。跟同级目标的关联是:同级之间相互呼应,甚至于能辅助同级任务完成。

这次换一个目标,我的角色是设计师,那我设置的目标是”提高平台用户的活跃度10%”。这个目标明显是产品经理相关的目标,而不是跟设计相关的目标。相同的角色,如果是设置的目标是“缩短用户发布信息时间由30秒到20秒”这个目标跟设计师相关。

T:Time-based(有时限的)

任何目标如果不去限制时间都是无意义的,因为同样的目标放在这个月和下一个月,环境不同都有可能造成不同的结果。所以目标一定要具有时效性,来保证任务的完成,否则造成的结果就是操作人磨洋工/负责人干着急没有办法进行考核。导致最后整体效率的下降。

2. 对下分享

对下分享的场景通常是知识分享和团队整体项目复盘,分辨推荐不同的策略可以使用:

  1. 知识分享:WWBL原则
  2. 项目复盘:star原则

1)WWBL原则

基本的拆分原则:是什么-为什么-怎么做-注意点。

W:what(是什么)

知识分享可以理解为一本书的写作方式,序言之后要讲清楚一些关键性的概念以及主体事物的描述,降低后面内容的理成本。

W:why(为什么)

一般展现的这么设计的原因,通常是使用流程拆分法或者是元素法进行。

B:behavior(行为)

主要是围绕用了什么方案解决了为什么,设计方面的解决方案通常是:颜色,交互,流程优化,用户分析等方面

L:lime light(注意)

很多知识都有自己的适用范围,一旦出了这个范围就会出现出现一些谬误或者是不合适的场景。以及有一些比较细节的注意点。

2)star原则

star法则中常见的有四个:环境,目标,结果,行为。

①环境

环境的元素里面包含了事件所经历的时间、地点、背景,在这里尤其是得先描述清楚背景才能够让对方知道这么操作原因,才能够获取到对方认同感。一旦认同感到位了,后面的事情都好做。

②目标

这里的目标跟自己和团队所做的任务相关,在实际工作之中每个人有每个人不同的事情,所以一般在这里描述的是:

  1. 你做的是什么任务?
  2. 任务要达到的目标是什么?
  3. 有没有其他的要求?

这样才能描述的清楚你负责的是什么,来让对话者/读者清晰地知道的清楚你的职责,后面聊天的时候才有聊天的范围。

③行为

这里所说的行为一般指的是在你为了实现你自己的目标时候你使用了哪些行为或者是工具,中间遇到了哪些问题又是如何解决的。

④结果

这里通常情况下是将结果进行量化,比如PV、UV提升多少、或者是用户转化率提高了多少这样的总结才能够更清晰的让别人知道你完成任务的量级。除此之外,通常还有获得了什么成就以及有什么认知相对于比较虚幻的结果。

三、分享流程

1. 前期思考

前期有3个思考点:

  1. 制作PPT之前需要先确认听分享的人听之后的目的是什么?
  2. 对他们有什么帮助?
  3. 对于团队有什么提升

思路借鉴:很多时候是没有思路的,就可以去多去看看一些大厂公众号的文章(我个人推荐58的文章写的非常好)还有语雀里面的文章也是非常多的。

这里再补充一个时间问题:一定要提前几天定会议室,分享会前10分钟最好去查验一下会议室设备完整度。

2. 中期宣讲

第一次心态紧张其实是最大的(社牛不算),有一个比较好的方法能缓解就是把其他参与人员当做白菜,讲的时候不看他们就好了。

3. 后期评价

这个是一般分享设计师分享后很难想到的点,如果里面有和自己关系比较好的同事可以在分享会完成后可以询问意见。

四、总结

分享会是设计师难得的提升机会,能够应用的从场景很多,无论是后面做主管还是面试培训也好。希望大家能在分享会上表达能力得到更大的提升!

#专栏作家#

一只鸡腿,微信公众号:B端设计一只鸡腿,人人都是产品经理专栏作家。一个吃货的B端设计师。

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

题图来自 Unsplash,基于 CC0 协议

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