网站首页 / 设计之家 / 抠一抠产品设计的细节(一)
返回

抠一抠产品设计的细节(一)

浏览次数:44 分类:设计之家

就算大家仅仅是走路,以A点至B点有时也非常复杂 – 要想了解路径是不是正确的,是否是对的方向,是不是走上捷径的道路。 但当A点是客户的问题而B点是实际特征时,这就像在一个旧地图和错误指南针在大海中导航。 为什么说这个过程严格呢 – 就算是时间非常紧迫 – 也需要更多地提供有关解决方案的信心和数据。

研究问题问题也需要研究,第一,问题是怎么成立的?是客户的要求,CEO的思考,是实现问题的路线图?那么理解问题的位置就变得非常重要。

如何分辨诱发用户遇到的实际问题常常很困难,这也容易被忽略。但是最初引发它的问题,意味着确保设计的起点是实际问题,而不是可能的解决方案之一。从首席执行官,产品牵头人,产品设计师等人收集客户关怀的见解 – 进一步挖掘,一直到你找到引发这个问题请求的原始的具体事情。

研究问题收集起数据深入探讨研究问题,是解决问题的一部分。第二步意味着要善于挖掘出人们和搜索谷歌的东西。一旦出现事件(也许是年少的创伤或者投诉),也需要更大地获取信息。 其他人怎样处理这个问题?这是一个基本问题还是原始问题?有无办法将问题分解成为更具象的问题?最重要的是,收集数据。

即便我们正在探讨一个全新的功能或产品有待开发,也有这些类似的指标(某种程度上)是可以使用。假若这是对已有功能的改进,则应该更容易从分析中获取使用数据或应该实施的任何类型的指标。

再次设计问题现在有了所有这些信息,应该很容易就可以更好地了解问题的背景和存在的原因。重新构建问题意味着获得不同的视角并从另一个角度来看待它,从而打破它以前在收集时可能添加的任何偏见或解释。因此,虽然最初的需求也许是“我们想要一个功能,同意在余额不足的情况下向用户转账”(已包含解决方案的需求),但问题可能是“转移给用户的钱花费时间,并且需要经常检查余额”。 这个问题的新框架为解决方案开辟了新的途径(实现调度程序,或者在余额不足时自动发出警报)。

设计的解决问题的方案,解决方案的问题现在定下来,数据上可以是用于广泛的产品背景。如今是框架解决方案的时候了,举个例子“决定哪一条途径诱发解决方案更适合这个问题”。为此,将解决方案的特征放在问题的形式中可能很有用 – “用户能自动设置提醒吗?”“用户能不能够导入事件?” – 并建立一个列表可能的解决方案方法。主要目的是缩小选项的范围,并形成一个用原型进行测试的假设。

您好!

点击取消回复

    个人中心我的 分类

    在线客服x

    客服
    顶部 回到顶部