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

推荐订阅源

N
Netflix TechBlog - Medium
I
InfoQ
Engineering at Meta
Engineering at Meta
Jina AI
Jina AI
Recent Announcements
Recent Announcements
T
The Blog of Author Tim Ferriss
P
Proofpoint News Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
D
Docker
Microsoft Security Blog
Microsoft Security Blog
宝玉的分享
宝玉的分享
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
GbyAI
GbyAI
博客园 - Franky
博客园 - 聂微东
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - 叶小钗
酷 壳 – CoolShell
酷 壳 – CoolShell
B
Blog RSS Feed
WordPress大学
WordPress大学
MyScale Blog
MyScale 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-02-01 · via 人人都是产品经理

在工作中,如何发现设计稿的问题,为自己纠错呢?本文作者从五个“多”的方面,对这个问题进行了解答,一起来看一下吧。

卯兔之年的第一篇文章,我们来聊聊学习和工作方法。有位同学问了我一个共性的问题,我把他的问题和我的回答整理出来,希望也会对你有帮助。

01 问:如何给自己纠错?

“我是一名 B 端交互设计师。最近我在面试时发现,面试官会针对具体的设计方案,提出一些很细致的问题,比如:

  • 筛选项的样式为什么是这样的?
  • 这几个按钮的优先级是不是不太对?
  • 这里的表单为什么没有将宽度对齐

这些问题都是我在平时根本没有注意或思考到的,被面试官问到之后,我才发觉设计方案欠妥当,可以被优化。但在日常工作中,很少会有人给我指出来这些问题。我要怎么去突破这种设计思维和认知障碍,找到自己设计方案的问题,并加以优化呢?”

02 答:做到五个“多”

发现自己的问题、审视自身的不足其实是一件很难的事情,因为这是反人性的。

大多数人都不习惯于正视自身的问题。很多人会本能地选择逃避,故作不知;还有一部分人会选择反驳、狡辩或推卸责任;只有少数人会想勇敢面对并积极寻找解决方案。

所以首先,我们要坦然接受 “我的设计稿始终有优化的空间” 这个事实。这是我们能够积极解决问题的心理基础。

然后你可以试试这五个方法:

1. 要多看

先提高眼界和评价标准。

实践案例和好的产品设计看得越多,就越会帮助你形成正确的设计评判标准

多去调研和分析竞品,把竞品的设计解法和自己的设计方案放在一起做比较,找到其中的差异,再做分析和评判。这样你对于自己的设计方案会有更多的思考和审视,设计水平也会逐步提升。

2. 要多做

一个需求多个解决方案。

不放过每一个设计的小需求或者小细节。把它们都当成是设计思考的机会,一个需求可以做出几套设计方案,加以分析和比较,确定最优解。

你在做 2-3 种不同设计方案的过程中,就一定会对设计细节有更多的思考和发现,学习和钻研的程度会比你仅做一套方案更深入。

3. 要多用

产品的问题是用出来的。

B 端产品和 C 端不同,设计师去做产品设计验证的门槛比较高。越是这样,就越不应该嫌试用和验证麻烦。

你可以经常扮演用户,对于自己设计的产品多做试用。你会发现“用”产品和“画”稿子带给你的感受和洞察是不同的。

多“用”产品会帮助你更快地发现和定义问题,尤其可以关注那些第一感受就不是很舒服的小细节或不是很顺畅的使用流程。因为设计师角色扮演能解决的问题,就是较为明显的表象问题。

4. 要多聊

多和其他设计师交流。

借助外力,多和其他设计师做专业交流。如果你在多人组成的大团队,就可以请其他人来帮你挑问题。我们组就经常会有“设计组内部评审会”,有需要的设计师可以预约组内的设计稿评审会,请他人帮忙一起看稿子、想方案。

如果你的设计团队人数少或仅有你一人,你也可以把稿子里的重要业务信息隐藏掉,发到我们的设计交流群里,让群里的设计师一起帮你提意见和找问题。

你为其他人描述你的问题和设计方案时,本身也是一种对于设计思路的梳理。当然,你也需要选择地接收意见,需要结合业务背景有自己的判断标准,对于大家的意见取其精华。

5. 要多访

要了解用户的真实情况。

我在每次做完用户访谈之后都会发现,用户“想要的”和我们这些设计师“给出的”答案,多少还是有些不同。这就好像你是一名医生,当一个鼻青脸肿的人被抬进病房,你能够看到并治疗的仅仅是他的躯体和外表;而他心里的伤痛,就只能通过盘问他、观察他、和他日复一日地相处,甚至是了解他的过往经历才能获知一二。

这也是为什么当你找到了很多看上去可以优化的问题点后,依旧没有给产品带来核心的体验提升的原因。C 端产品还好,你和用户的差别并不大;但如果是 B 端产品,不去接触用户,想要做出质变级的设计优化方案,就看你的悟性和运气了。

当你发现自己的问题并敢于正视它,你就已经踏上成功之路了。保持一个积极的态度,然后多看、多做、多用、多聊、多访,相信要不了多久,你就会看到自己的进步。

专栏作家

元尧,微信公众号:长弓小子,人人都是产品经理专栏作家。一线互联网大厂B端体验设计师,清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作,目前负责国际业务线B端产品体验设计和组件库的搭建工作。

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

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

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