知识分享

  • 首页
  • 市场分析
  • 需求分析
  • UI设计
  • 产品运营
  • 产品设计
  • 项目管理
  • 新玩意儿
不积跬步无以至千里
不要停留,欣赏沿途的风景
  1. 首页
  2. 产品设计
  3. 正文

产品经理的日子 – 我是如何做功能设计的

2021年10月27日 223点热度 0人点赞 0条评论

编辑导读:互联网发展至今,大部分的功能都有了,产品很难在这方面寻求创新,只能开拓新的业务形式。本文作者根据自身工作经验,分享了自己是如何做功能设计的,希望对你有帮助。

在当前的行业里,功能设计其实是最不需要动脑的地方,天下作业一大堆,就看你会不会抄了。互联网发展到现在,大部分的功能都已经有了,纯自己创新的只有业务形式,至于功能基本大同小异。

功能设计模块大概可以遵循几个点:

1、能删就删别客气

在公司第一个项目应该是【用户中心】项目了,当时定位是C端用户与公司的交流地,能够看到公司发布的新品,也可以看到门店的地址及导航,还能有各种信息查询,整理后产品架构大概是这样的:

乍一看好像没什么问题,从企业的角度来讲没问题,相当于是一个企业门户了。但仔细想一下,有几个问题需要回答。

a、用户为什么会打开这个小程序,驱动是什么?

用户只有在装修阶段会使用这个小程序,那么应该属于短期高频,长期低频的概念,上来的原因要么是找以前的订单联系官方进行售后报修,要么就是短期内查询订单生产安装进度,工具性质比较强。

b、用户为什么要在这上面看新品和门店地址,符合用户习惯么?

不符合用户习惯,首先如果我是新客户那么我肯定不知道有这个小程序,如果我是老客户我已经知道我在哪里定的产品,如果忘记了那我肯定在地图上找,或者联系销售发地址给我,没必要在这里找,不符合用户习惯,其次为什么要在这里给门店评价,为什么不在公开渠道比如淘宝、大众点评这些地方?

c、用户为什么会在这里看文章?

虽然企业的出发点是通过文章触达用户做社群,或者是有内容可以宣发,但是忽略了一个问题,用户为什么会在这里看?这里会有社区讨论氛围么?有人在这里运营社群么?

d、定位是企业门户小程序,是不是太大了?

虽然每个企业都想要一个门户,但一开始做门户,有那么多精力么?

一顿思考之后,把项目框架砍成了这样:

聚焦工具属性,砍掉社交属性,以官方的名义向用户提供信息查询。

2、突出重点

用户中心这五个模块,如何设计,是9宫格,还是微信列表,还是什么方式?哪个是核心功能,该如何展示,经过分析后决定着重体现在订单上,家居定制行业合同就是订单,总不能把一个合同直接展示出来吧,后来思考后决定把服务体现出来,从用户进店的第一次沟通【量尺】节点开始展示到最后的【安装效果图】进行展示,既体现了服务,也体现了品牌的高度。

3、简化操作

在人机交互的原则里面有一节是说交互要清晰,避免用户多操作的,那么基于这个原则,我们在首页直接展示内容,原因如下:

a、正常人的订单不会有很多,平均2-3单,没必要搞订单列表

b、直接展示用户的订单,可以简化操作,更方便用户查看,也更简单

到这里我们发现大概的思路有了,那么订单怎么展示,直接抄一个电商的订单详情还是什么?怎么才能用最少的功能体现最大的价值?

4、附加价值

在做产品的时候我们可以反思一个问题,用户为什么会在你这里,除了这些东西还有哪些小惊喜可以给到用户,也就是附加价值。在做个人中心的时候我们发现客户与集团这边的沟通互动很少,信赖度也很少,大部分客户是与经销商进行挂钩,没有直接与集团对话,缺少一层信任感,但这种信任感不能通过经销商提供,毕竟每一个城市每一个经销商给到客户的服务是无法统一的,这个问题不解决及时你提供再多的功能模块,客户还是客户,品牌还是品牌,品牌对客户的聚合能力还是无法提高,针对这个问题,我们觉得应该从服务流程进行细化。

基于以上思考,我们从用户进店第一次服务开始到最后安装验收完成的重要环节搬到线上,并且在核心的节点向用户发送通知与客户互动,提高品牌的服务价值。

另外在每一个中间环节我们都有相对的产物给到用户,比如预约通知,量尺图,效果图等等产物会及时推送给到用户。

通过标准流程+服务机制+中间产物提高用户的购买体验,这样既满足了订单的展示需求,也提高了品牌的服务机制,让用户更了解,更放心。

5、当下合理

其实在梳理的过程中,还发现售后投诉、报修、问券调查等功能可以添加,但不少因为当时的业务环境,技术排期等各种因素只选择了四个模块进行开发,在设计每一个功能的时候,先看当前的业务形式是否稳定,再看当前的逻辑是否能够执行落地,只有这两个条件满足了,才有可能让功能有人用,也只有功能有人使用了,才能有数据为后续的业务发展提供有效的分析基础。

产品功能设计的时候需要关注未来,但也要着眼于现在,毕竟未来的业务会变成什么样,谁知道呢?

写在最后:随着业务不断发展,后续版本迭代也在继续,新项目后续介绍。

附1:V1.0.0版设计稿

附2:V1.1.0版设计稿

附3:V2.0.0版本

 

本文由 @互联网老兵 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

标签: 暂无
最后更新:2021年10月27日

小虾米

同理心,洞察力!

点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复
最新 热点 随机
最新 热点 随机
拍10部火1部,道观也来凑热闹,短剧成吸金神器? 为什么二次确认后,用户依然会误删? 新零售SaaS架构:面向中小连锁的SaaS系统整体规划 AI时代下浅谈XR中的渲染技术 基金理财之客户需求分析 业财一体化数字化(一) 酒店代理的灰产江湖:0库存、赚4成差价、月入16万 探索工具型产品体验度量模型-行为度量理论篇 飞猪、携程们的下半场:吃工具属性老本,补内容短板 AI产品经理 | 入行AI的必备知识 3D 文件格式的江湖纷争 在线音乐等待“第三极” 小程序里卖剧,8天赚1亿? 卖爆抖音后,中式汉堡将成为一场“虚火”? 电商包邮背后隐藏的小心思 县城咖啡之战的最后赢家是谁? 字节跳动再战长视频,这次有何不一样? 网文IP的风,吹到“下饭剧”? 提升B端产品易用性:搭建帮助体系 小红书关停“自营电商平台”,作何打算?
从虚拟偶像到虚拟主播,一场TO C到 TO B生意的大迁徙今天我们来聊一聊小红书电商盘点一下那些虚实结合的文本输入方式自动驾驶,又到黎明前?万亿规模能源产业互联网【能链】为何一枝独秀?经营指标层面深度解读骑手需要的不是同情,而是尊重数据更新|不只是一个更新按钮而已名实唯一性:数字与AI经济里的那些潜规则实战分享!系统可见原则在交互方案中的运用从商业模式入手,搭建一款产品的底层拆解框架小红书走到命运拐点微信的聊天记录占比,被网友玩成了新一代 MBTI ?SaaS产品数据分析之指标与标签一篇文章搞懂一个系统之 SRM 系统一个真秀才倒下去,十个假靳东站起来谈谈在B端落地第三方大模型的步骤从0开始设计产品搜索功能(一)瑞幸的“9块9”突围战,只需几滴茅台?如何从0-1建设企业微信SCRM顶流网红“秀才”翻车,“中老年收割机”易主?
蜜雪冰城走红后,一点点们难打翻身仗? 字节跳动为何执着于“种草”? 苹果首款AR眼镜卖2万5!续航2小时,近视也能用,库克:欢迎来到空间计算时代 拼多多与阿里的技术差距大吗? 2019年,小程序如何做好冷启动? 微信键盘抢先体验,不用担心隐私泄露了? 如何有效提升团队 UX 成熟度?实践干货都在这里 为什么你会收到相亲广告的推送? 万字总结:B端产品设计基础思维与方法 电商末日,倒计时300天 一文讲透美团兴盛史(三):社区团购 知识图谱在内容类产品中的应用 【设计法则】如何精进你的设计知识体系之—Z型视觉模型! Web3.0:一场概念的游戏 网易云音乐,瞄准有声书 从前端Bootstrap框架的角度看待按钮 移除真人,虚拟偶像会更强大吗? 设计上云,能多大程度上提高团队效率? 卖菜烧光120亿,每日优鲜大败局 产品周报222期 | 微博将上线协管员功能,抖音内测图文内容一级流量入口

COPYRIGHT © 2023 知识分享. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang