交互设计如何做竞品分析

案例简介:

在「钉钉/任务」模块,嵌入 tb 的任务,可直接访问任务详情页。

竞品分析的意义

为什么要做竞品分析?这个问题也许很容易找到答案,比如:想看下对方都做成什么样;比如想找一些设计灵感,等等。目的不同,竞品分析的方法和方式也会会有差异。但需要明确的是,竞品分析是「手段」,而不是「目的」。

具体方法

01.设计目标

  1. 尽可能复用平台已有的资源
  2. 保证平台体验的一致性

02.竞品分析

当你在做竞品分析的时候,你习惯分析哪些内容?信息架构、功能、核心用例流程、色彩、icon等等,可以对比分析的内容非常多。那每次分析的内容都是一致的吗?全部都需要吗?如果要取舍,依据又是什么?

在我看来,「设计目标」就是依据。接下来的任何步骤都不能脱离这个依据。「设计目标」是「竞品分析」的前提。所以「竞品分析」也可以沿着「设计目标」的思路,继续开展。

ps:目标可以衍生为产品目标、视觉目标、运营目标等等,这里讲的是指交互设计目标。

0201. 尽可能复用平台已有的资源 ↓↓↓

资源 = 模块,首先需要梳理该平台的模块,然后分析「钉钉任务」(本身也是个模块)与其他模块之间的关系,也就是梳理 模块架构。本次项目主要涉及「任务详情页」,所以以「任务详情页」作为起点,梳理其模块架构。

注意:这个时候,我会把 tb 独立 App 的「任务详情页」与「钉钉任务详情页」做对比。如果本身不存在独立 App,那这个环节可以省略。

0202. 保证平台体验一致性 ↓↓↓

当不同的页面保证了「信息架构」、「功能设计」以及「核心用例流程」三个方面都保证了相对的一致性的时候,我们就可以相对安全的说,体验一致性了。所以可以从以上三个方面着手,深入分析和对比。

信息架构 & 功能列表

核心用例流程

核心用例可以是:录屏、截图、workflow。重点在流程,也就是用户的操作路径。

主界面

这一块主要供整体感觉上的参考。

03. 设计策略

还没那么快。在设计策略之前,我们还需要迭代一次「设计目标」。


竞品分析之后,我们会拿到一些 insights ,这些 insights 
应该立即在项目组内部进行讨论,并得出一致结论,同时修正设计目标。

ok,修正设计目标之后,我们可以再跑一次循环,最终走到「设计策略」那一步。设计策略的获取,可以在「竞品分析」的框架下,直接做「选择」:

0301. 模块架构是什么样的?

0302. 信息架构如何选择?功能如何取舍?

0303. 核心用例流程如何设计?

最后

以上就是我以一次真实的项目(为了说明方法,具体有所调整,主要参考思路本身)为案例,总结的交互设计,如何做交互层面的竞品分析的一个思维框架,主要目的是为了输出设计策略。

当然,在实际操作过程中,我们还需要结合实际情况对设计策略进行调整。但该框架下输出的设计策略,算是一个非常扎实的设计起点。

我所认可的交互 · 1

很多时候,我会用「上道了」、「有感觉了」这样的词,去评价身边的新人交互设计师。当然,这些字眼也只能起到意会的作用。

思考良久,我尝试用 案例 去阐释我对交互的评价标准(criteria,not principle),于是有了这个系列。该系列主要是一些简单的、具备代表性的小案例,大部分来自我工作中的实际项目,旨在抛砖引玉。

案例 1:通知范围选择

First,案例分析 ↓

Then,Implication ↓ 😊

  • 以场景为线索,梳理用例
  • 提前帮用户选择(他想要的选项)

 

 

The design of Youtube subtitle

今天突然留意到 Youtube auto-generated subtitle 的设计,顿时觉得这个设计实在太好了。之前一直这样的吗?🤦‍♀️🤦‍♂️有点记不得了… 那为什么要跟视频视频自带的 subtitle 设计上有差异呢?职业病不自觉地被激发…

Auto-generated Subtitle

系统自动翻译的字幕,采用了上下翻动的设计。这样的方式非常从左到右、从上到下的阅读习惯。同时也限定了字幕的位置,让视线更容易聚焦。从逻辑上说,保持最后一句来承上启下,又让阅读更加的连贯。实为非常好的设计。

Subtitle

视频自带的字幕,则沿用了目前最常见的方式。

Why

我私以为,系统自动翻译的字幕的设计出于以下考虑:

需要自动翻译的场景下,用户要么听不懂音频语言,要么听不清音频。那么这种情况下文字阅读应该是他最重要的任务,所以提供连贯的、自然的阅读体验,非常重要。

适配自带的字幕呢?

视频内容的类型非常多,如果画面为主,音频为辅的内容,如此强调阅读性就意义不大了。比如我们看电影,字幕只是辅助,保障用户能用余光捕捉关键信息即可,不遮挡视频内容为佳

 

 

移动端的增长

在去年 8 月到 12 月期间,我曾短暂的负责过 Teambition 移动端的产品和设计。很遗憾才刚迈出一小步,没能全部落地。但整个过程对于我而言却是非常重要的。

当公司策略上转向大型传统企业(餐饮、工程等),并决定从专业场景着手的时候,我预感到移动端如果仍然保持「紧跟 web」的策略,终究会无地自容。那移动端应该如何定位?移动端在整个服务生态中,扮演什么角色?我们是否会预期mobile first 的提前到来?

移动端与 web 的关系

为了数据兼容,移动端不假思索地跟随 web 的发展,因此做得很重。这可能是一个最符合逻辑的结论,毕竟我们不希望用户的协作受平台限制,也不符合无缝协作的价值主张;但这也是一个并非非做不可的结论,只需要我们明确了移动端与网页端产品的关系,而我当时主张是:从 web 的子集关系,转变为交集关系。

移动端的目标用户在哪里?跟 web 用户的关系?

第一步怎么迈?

专注 PV / UV 均最高的功能,收益明显。

完整推导文档 ↓

前往查看产品推导文档

 

继续阅读“移动端的增长”