一些想法

个人总结的方法论

  • 先讲背景,再讲方案
    刚开始做产品时,和别人将需求,经常直奔方案。结果对方经常听不明白,就需要我将背景再补充一下。
    后来自己在对接别人的需求时,就仔细体会了。如果直接告诉我方案,我会以为是命令或要求我这么做,即便我可以按要求去执行,但仍会感觉被动,感觉只要照做就行,别的不需要过问,心理上会觉得我是在听从别人的指挥。
    应该没有人会觉得很舒服,可能还会产生抵触情绪,无缘无故被人安排了工作,还不知道为什么要这么做。
    所以在跟别人讲需求时,就尽力将背景讲清楚,将方案的合理性讲清楚。
    如果对方不接受该方案,就退一步,还原真实的场景,换位为用户,去仔细体会方案是否可行。
    基本上将方案放入具体场景中讲述时,大家就都能体会了。

  • 需求变更要有详细记录
    评审后待确认的方案,确认后一定要周知相关同事。
    开发中变更的需求,也一定要有记录,也要及时通知相关开发、测试、产品、设计、运营,让相关同事及时跟进处理,避免不同步造成人力资源浪费。
    实际工作中,会在交互中详细列出出现的问题,以及给出的方案。针对待定的问题,明确标示是否已经确定。

  • 尊重同事的付出
    在和百度同事合作过程中,学到了一点常识:上线邮件中,优先感谢参与的同事。
    曾有同事跟我抱怨,产品上线没有通知开发,上线后的数据也没有通知开发,感觉自己只是公司的外包。
    经常觉得研发才是产品完成过程中最重要的参与者。从产品设计出来到上线,研发付出的时间精力最多,产品稍微改动需求、设计调整细节,可能都会造成研发同事加班处理。
    所以上线邮件、上线后的数据反馈理应及时通知研发同事,并要表达感谢。
    工作中,也需要多倾听研发同事的建议,调起他们的积极性,多给产品提方案。然后你会发现,研发经常可以提出更合理的方案。

  • 同理心
    频繁无缝切换视角,做产品时经常思考“如果是用户,会怎么操作”。如果自己都觉得多余的步骤,那用户肯定觉得多余;如果自己不太好理解的文案,那用户肯定也不理解。
    不要把用户想得比我们更熟悉产品,其实绝大部分用户都很小白,甚至连按钮上的文案都不理解。所以尽可能讲得直白一点。
    在用户操作之后给提示的时候,有个原则,发生了什么(是什么)——为什么——怎么做。
    最先告诉用户的应该是刚才的操作发生了什么,接下来告诉用户为什么出现这种情况,接下来告诉用户该怎么做。
    这一流程更符合认知,也更容易被理解。

  • 越少越好
    移动端设计,经常要在优先空间内展示丰富的信息。
    但展示的字段不一定越多越好,无用的信息对用户都是干扰,反而降低了到达率。
    在设计时,要反复思考哪些字段才是对用户有价值的,坚决拿去没有价值的信息。
    相对有价值、可有可无的字段,就要考虑是否可以放在不明显的位置,或者通过设计,优化展现,或者精简掉。
    将有价值的字段按照重要程度进行排列,从左往右从上往下。还可以加大字号、加重颜色、放大尺寸。
    还有就是倾听用户反馈,如果有数据可以佐证,跟进数据调整方案。

  • 一致性
    使用其他app时,经常发现同一模块的内容,在不同的位置,却有不一样的展示方式:位置、动效、尺寸。
    不知道普通用户会不会关注这些点,对我来说,会觉得混乱。

发表评论

电子邮件地址不会被公开。 必填项已用*标注