Design is not about the pixels — or why the lean approach rocks

For a while now, I focused on building partnerships with my freelance clients.

A couple of pages taken out of lean UX book helped a lot.

263790__wallpaper-lines-creative-stripes-abstract-abstract-walls-lines-green-blue-backgrounds_p

While talking with potential clients, especially coming from Dribbble (I guess that’s due to visual nature of the site), I am sometimes having a hard time explaining how I work. I noticed a lot of people are still used to what I call “old agency model”, where designer puts a price tag on the work based on rough time estimate, then disappears with the project into oblivion and shows up a bit later with a finished project that might or might not fit the client’s vision. This is bad. For a while now I have been working with lessons taken out from Jeff Gothelf’s amazing book Lean UX and I have been really happy about it for several reasons:

You have to get over your ego

As a designer, you might be forced to show things that are not perfect. This is good for you. It’s a lot easier getting feedback from your client — or potential users — early than spending a lot of hours trying to pixel-perfect a solution that wouldn’t work in the first place. Remember that design is all about solving problems and if you’re solving the wrong problems, your pixel-perfect buttons don’t matter.

It breeds trust

If you’re working with people in your team — product owners, project managers, developers and so on — side by side, people start to understand that only last couple of percent of the design process is about the pixels. Majority of design happens in the designer’s head or sketches and a lot of things are not deliverables that you can show off to your client or colleagues. Working in the open is useful to you and the team or the client, because everyone knows what’s going on and understands the process.

It’s more focused

There’s an important saying in the lean startup community — shipped is better than perfect. If you can get your design out to potential users even with its flaws and problems, there’s higher chance that you will get useful feedback and act on it without going down the wrong route. There’s also usually less deliverables and a whole lot more of tweaking and fixing things. One major upside is also the fact that usually you don’t spend a lot of time building the wrong thing.

There are obviously downsides to this approach and you as a designer have to make sure you overcome this. The major obstacles I found so far are:

It gets micromanage-y

When working in the open you have to be prepared that a lot of people who are not designers will step in and try to get a say. This is good, but can be destructive to the project if you simply cave in and do whatever people tell you. Micromanagement never helped anyone and certainly won’t help your project if you allow it to happen. If you have to “fight” for your design, do it. Make sure you have data, examples and anything that can help you stand your ground but make sure to stay open for useful feedback. This is hard, so brace yourself and do your research.

It gets messy

A lot of people are not used to this process so when you show them somewhat imperfect mockup or prototype, they will go straight into criticising things that don’t look right. Stop them right there and make sure you’re talking about the same thing — if you were just trying to get one interaction right, make sure you’re on the same page with your team or your client. Make sure that you’re talking about what matters instead of dwelling on the details — there will be time for that.

It’s hard to estimate

While staying true to the iterative nature of design process, lean UX is incredibly hard to estimate, which can be tricky. The lean approach works incredibly well with product teams but the client needs to be updated with ongoing costs and time. The process is all about being open and trusting each other so make sure you communicate clearly how much things are taking and signal potential problems as soon as they appear — this helps avoiding going way over budget or spending lots of time working around some particular problem when there’s lots more other things to do.

I found it best to work with the lean startup “Minimum Viable Product” (or “Minimum Viable Experience”) and then take it from there if you’re working on a constrained budget.

All in all, I love working lean and I found it very liberating. I strongly recommend you to try it as well — while it’s hard at the beginning, it’s really worth it.


原创文章,作者:Smiler李想,如若转载,请注明出处:https://www.iamue.com/5942/

(0)
Smiler李想Smiler李想
上一篇 2015-06-01
下一篇 2015-06-02

相关推荐

  • 虚拟现实产品是更棒的交互体验吗?

    2016年12月,携程UED大会把虚拟现实技术作为论坛的核心主题,邀请了方方面面的专家,从技术,硬件,体验等各个方面来剖析VR这种创新的趋势。

    2017-05-09
  • iOS App中数据加载的6种方式

    我们看到的APP,往往有着华丽的启动界面,然后就是漫长的数据加载等待,甚至在无网络的时候,整个处于不可用状态。那么我们怎么处理好界面交互中的加载设计,保证体验无缝衔接,保证用户没有漫长的等待感,而可以轻松自在的享受等待,对加载后的内容有明确的预期呢?今天这篇文章,会介绍6种常见的加载模式设计,和3种减少等待感的具体手法,希望对追求极致体验的产品人有帮助。

    2017-06-02
  • 和几位牛逼的设计师聊了聊“理想雇主”这件事,还有些别的故事...

    互联网领域的设计师们更像是一群“走钢丝的人”:游走在逻辑和审美之间,游走在说服和被说服之间,游走在PM、开发和大BOSS之间,试图最终达到各方的平衡和实现最有效的解决方案。

    2016-06-20
  • 对话式交互设计流程

    上一篇文章介绍了自然对话的基础概念,学习了谷歌对于人类自然对话的研究和理解。本文将通过一个简单的案例来介绍谷歌推荐的对话式交互设计流程,以及本人对该流程与常规的体验设计流程异同之处的对比分析。设计流程1.选择适合的使用场景对话式交互界面的使用场景通常是简单直观的。当考虑任务场景的时候会想到游戏,因为游戏是低风险的。但是游戏界面的设计必须要能够满足用户的期望,以免使用户感到无聊。猜数字的小游戏可以作为对话式界面设计的一个很好的例子,不要求...

    2018-03-31
  • 产品需求分析——《破茧成蝶》读书笔记

    这是一本很实在的书,没有很虚的理论,而是结合了国内互联网实际的案例,清晰明了地道出现实情况跟理想状态的不同,并且给出了很好的解决建议。适合刚入行的交互设计师以及产品经理阅读。 进入研究生阶段,大大小小…

    2015-03-05
  • 交互设计中的心理学

    整理认知心理学中对交互设计(用户研究)有所启发的一些知识点(参考《认知与设计——理解UI设计准则》)包括:中央凹与边界视野——如何呈现信息以获取注意力格式塔原理——如何处理不同界面元素的关系时间感知——如何让…

  • 屏幕尺寸越来越多,“首屏为王”还有效么?

    作者:Amy Schade@nngroup,翻译:小球娘   几句话概述:把什么内容放在页面顶部(第一屏的位置)以及把什么内容藏在第一屏位置之后将始终影响用户体验——无论屏幕大小。有平均84%的用户会区别对待页面第一屏内容和…

    交互专题 2017-08-07
  • 你天天挂嘴边的「用户体验」,到底是什么?

    用户体验到底是什么?这个每天都挂在嘴边的词,你真的懂吗?

    2017-05-02
  • H5三个设计方向的自我定位

    如今,移动端H5如雨后春笋般迅速发展花样繁多,无论是宣传产品、内容介绍、新闻推广都会想方设法搞套H5出来。那么如何在众多H5中脱颖而出?如何使手上的资源发挥最大化?如何扬长避短,做出吸睛的H5?都是摆在我们面前的问题。

    2017-05-27
  • 交互设计思考模式:“删除、组织、隐藏、附加”

    Giles Colborne简约四策略是“删除、组织、隐藏、转移”,由于“转移”在实际设计过程中比较少运用到,所以我根据elya的知乎回答把四策略定义为“删除、组织、隐藏、附加”,elya没有解释她的理解,所以我根据自己理解重…

    交互设计 2015-08-31