功能

如何完成后台PRD的撰写?

本文作者将分享自己在后台需求文档的撰写上的心得和建议,enjoy~近期在工作上独立完成了一份后台的需求规格说明书,因此有了一些心得体会。在这之前,我浏览过许多关于后台设计的文章,大部分文章都是在阐述如何设计后台,给了我们很多设计理念上的建议与帮助。只是,无论什么样的设计都最终都需要以文档的形式产出,因此,本文我将在后台需求文档的撰写上分享自己的心得和建议。现在,我们先来做做

信息结构图、功能结构图、结构图,你还傻傻分不清吗?(上)

你还在问产品结构图到底是信息结构图还是功能结构图吗?这里有微信的实际例图帮助你更好地理解这组命运三姐妹图类。在写PRD、竞品分析文档中,我们常常会看到产品结构图、产品功能结构图或者产品信息结构图的身影,但需要讲清楚他们的定义和作用也真没看上去那么简单,这里作者尝试分享一下自己的观点。特别声明:由于篇幅和其他因素限制,本系列中所有的实例图在完整性上有省略和简化,仅作为举例讲解

如何画出专业的原型图?(上)

怎么样的原型图才算是专业的原型图呢?文章总结了一些经验,希望对你有所帮助。本片文章(原型上篇)重点内容:清晰的视觉层次视觉流结构功能预见性信息的焦点即为视觉的焦点足够简单考虑到边界条件首先,我们要明确原型图是画给谁看的,通常是以下几类人:开发、部门领导、UI设计师和测试,一个完善的产品流程离不开着几个角色。开发通常最关心的是有多少功能,功能的复杂度怎么样,边界条件是什么,异

捕捉客户需求:先改进功能需求的记录方式

编者按:用户在表达对某个新功能的需求时,他们的建议很容易被忽视或者被搁置在一边。Phil Freo 在本文中介绍了能更好地捕捉客户需求的方法。典型的方式真的管用吗?最常用的记录功能需求方式非常简单:“john@example.com需要功能A… [@产品和研发团队相关人员名单]”。假设我们确实要开发A功能,上述做法提供了需要给到通知的人员列表,但这种操作既不能给研发有用的帮

面试产品经理岗位的能力三阶段

面试产品经理的时候需要向面试官展现自己的产品能力,建议提前对应聘岗位的产品进行分析总结。初级产品经理的能力往往是设计功能,高级产品经理的能力往往是设计功能和产品架构,资深产品经理或者产品总监更多的是对业务的理解以及能够带领团队完成公司既定的业务目标。一、对产品的功能理解大部分产品经理的主要工作就是设计功能,那么把应聘岗位对应产品的功能改进写出来,到时候讲给面试官听,很方便评

做产品,如何拿捏需求

之前听过刘文智《产品经理深入浅出》的讲座,其中有一句话给本屌留下的印象最深:做产品经理,最重要的就是“拿捏”。作为一个初级产品经理,专业填坑经理,资深挨砖师,当时听到“拿捏”这个骚气十足的词,我居然可耻的硬了(表示有共鸣)。当我们面对用户的需求,运营的吐槽,市场的恐吓,老板的圣旨,如何“拿捏”,这是个问题。拿好了,对谁都能交代,捏不准,结果必然是被别人群起而“拿捏”,直至蛋

那些很熟悉但又不知怎么用的设计法则(1):80/20法则

每次在做项目总结的时候,总想列举一些法则和方法论来增加总结的专业性以及可信服度,但是总有些熟知的方法却怎么也叫不上名字,所以决定开设一个这样的专题,敦促自己在做设计的时候不要留于表象,有理可循。80/20法则(80/20 Rule / Pareto principle)在整个产品中,大部分效果由少数几项关键因素决定。80/20法则又名二八定律、帕累托法则(定律),也叫巴莱特

功能设计:将需求转化成实际的功能列表

围绕功能框架去设计,不要去迎合领导,不要去讨好用户,不要去取悦自己。产品经理在做功能设计的时候,要能保持平和中立的心态,才能确保核心主线功能不出现任何偏差。概念设计阶段是需求从抽象到具体、从模糊到清晰的过程,确立了产品的功能模型和信息架构。而功能设计则需要将信息架构进一步落地,是从框架结构到详细设计的过程。以分析后的需求为依据,在概念设计的基础上,设计产品的功能,经过功能的

一个应用有多少功能才足够?

如果你对手机中App的使用率较高,尤其是一些工具类应用,那么可能会遇到一些这样的应用:具有众多的功能,提供了分享到无数的社交平台,可以备份到你能想象的所有云存储空间,使用这个App几乎就可以完整的管理你的人生让你从此摆脱恶习工作效率提高5倍等等,但是,你就是不想用,可能因为举得它太过强大你配不上它,也可能因为它太过复杂让你望而却步,总之,你就是不会去用它。在之前的文章“嘘!