状态图与概念模型
什么是概念模型?
用户心智模型、实现模型、视觉模型这些不同的“域”的桥梁。用概念模型希望尝试既能跟业务部门沟通也能跟开发部门沟通。以直观的方式向领域专家(eg.业务部门)和开发人员解释系统应当如何组织,如何工作,以及如何与用户互动。
概念模型描述的是问题域内不同的概念以及概念之间的关系。
电子书产品
首先对于读书,用户的心智模型就是建立在纸书的基础上的,书架,翻书,等等。所以可以发现市面上几乎所有的电子书产品不管是阅读器还是 app,都在尝试还原一个适应这种用户心智模型的电子书视觉界面和交互界面。
概念模型需要能够站到用户的鞋里,一定要考虑用户的心智模型,然后呢,它还应该是一个能够同时跟业务部门和开发沟通的工具。
omnigraffle 在 google 里有很多的 templates,记得去下载。
概念模型的设计过程
用领域语言和用户语言进行大量描述,也就是描述用户体验和用户交互过程吧,在这种描述当中找名词(可能的「实体」)和动词(可能的「关系」)
在不同的命名空间中统一术语,删减不必要的「实体」
定义每两者之间的关系,「一对一」、「一对多」、「多对一」、「多对多」。
实际设计概念模型
微信号与视频号的关系
首先描述:每个微信号可以创建一个或多个视频号,通过视频号可以发布视频内容,或者通过视频号进行直播。可以分别通过视频号与微信号身份对视频内容点赞,评论。
概念模型的价值
有一个「完整」的系统视角,理清楚系统内的概念和关系。
思考及澄清一些边界性问题。
有一个明确的概念关系统一沟通,统一开发、业务、用户视角。
原型图
画原型图的核心目的是理清产品架构,而不是追求动效和交互什么的细节。原型图的重要性不像想象当中那么重要。特别是用工具和画的精不精美其实是次要的,那不是产品经理的工作,痴迷于画原型是不太健康的文化,真正重要的是产品设计和架构设计的思路,画原型过程中能够帮助理清这些。
画原型图的步骤
手绘图
手绘这一步建议有,但是除非跟设计,业务以及开发合作比较默契,否则不太建议直接用手绘图跟人沟通。
线框图
高保真原型
做原型图的目的
坍缩:头脑中规划的时候会有很多不切实际的想法或者念头,画原型图能够像写日记一样把这些想法加工落地,在这其中不切实际的部分可以被切割掉。
具体:之前二爷讲过一个故事,就说一个产品经理在汇报的时候底下人都漫不经心的做自己的事,然后这个产品经理就拿了一个本子,说,我们要做的东西就跟这个本子的 size 差不多,然后所有人就都有了一个画面感,可以展开讨论了。另一个例子是,你让一个人想十样白色的东西,然后你再让他想十样厨房里白色的东西,范围大大缩小,但是结果是这个人想到十样白色的东西的速度却大大加快了,这是因为限定带来了具体的画面感,原型图就是一个限定的画面,讲故事的能力就是营造画面感的能力,所以从某种程度上讲,画原型图就是把这个产品将成一个有画面感的具体的故事。没有原型图的一个很可能的后果就是,完全按照要求做的
原型图是各方沟通的抓手
原型图能促进思考成熟
中间挡住的那个是 ideate,意思是形成概念。
信息架构像一张地图,首先展示产品的整个框架,接下来还能让用户知道自己在哪里,能去哪里,怎么去。
第一条比较好理解,整个产品的信息架构跟具体页面上的页面架构的关系
第二条比方说在电商平台中,商品列表页的优先级一定是高于详情页,但是也不意味着用户想要进入商品详情页必须通过商品列表页,也有可能是通过一个什么链接直接就进去了呢,现在产品的很多环节并不需要搜索直接就是一个推荐。这就是说,信息的级别不一定等于用户的访问路径。
第三条防止用户进到撞墙页面的时候也不能过度处理,比方说微信和支付宝支付完成的页面,支付宝的就有些过度处理了(个人感觉)我一直没想明白的一件事是,我也没参与那个什么春节摇一摇的推广活动,但是现在移动支付的习惯就是用微信,这个习惯我最开始是怎么养成的呢?
现在我觉得可能就是相比于支付宝,微信支付完成的界面比较克制,没有什么乱七八糟的推送,只有一个完成按钮,让我比较舒服。这也侧面反映了微信和支付宝的产品逻辑
评论