Daily Productive Sharing 600 - Design as Craftsmanship
One helpful tip per day:)
Paul Stamatiou, an awesome designer who joined Rewind.ai after a decade at Twitter, describes his understanding of quality and design:
- the traditional 'ship, then iterate' is actually a trap that eventually turns into shiterate.
- the need to make trade-offs is all the more important because the demand for quality is too high without regard to reality, which everyone hates.
- people choose a product or service not only because of what they can achieve, but also because of the feeling they bring.
- ensuring quality is a big challenge, but it can also be very rewarding - it's all about whether we want it.
If you enjoy today's sharing, why not subscribe
Need a superb CV, please try our CV Consultation
Paul Stamatiou 是一位很棒的设计师，在 Twitter 工作十年之后，加入了 Rewind.ai。他介绍了自己对于质量和设计的理解：
- 传统的 Ship, then iterate 其实是一个陷阱，最终会变成 shiterate；
- 过高地要求质量而不考虑实际情况，这是大家都痛恨的，所以更需要做出权衡；
- 人们选择某一样产品或者服务时，并不仅仅是因为它们能实现什么功能，还有很大的因素是因为它们带来什么样的感受；
- 保证质量是一个很大的挑战，但也会带来非常大的收益，关键在于我们是否愿意。
如果你喜欢我们的内容，不如支持我们 :)
Excerpt
It's a bit different from my previous roles: I’m a product designer but I also spend time building my designs in Xcode. I love having a hands-on route to directly affecting product quality.
With small teams, the output, whether it’s an app, web site or any other product, represents the people behind it and the tremendous amount of effort they expended to make it.
As a designer I'm motivated not only by identifying and successfully solving problems for people through software, but also by the care, attention to detail and craft I'm able to put into it along with the team.
When I joined the Twitter design team I was designing in Photoshop. For things that demanded higher fidelity, I would dive into After Effects to make small UI videos—a far cry from the interactive mobile prototyping we take for granted today.
That's where the challenge of building quality products starts to creep in. The constant tension of shipping faster versus shipping better.
Falling into a cycle of "Ship, then iterate" is a trap. It ends up being more shiterate.
There are a lot of reasons why shipping well-crafted, quality products is hard, especially on a large team.
Quality is all-encompassing.
People hire services not just based on what they can do but how it makes them feel.
Quality products can take your users from "I'm merely using this thing to accomplish a task" to "this is something I love using and I'm telling everyone I know about it."
Quality products make me excited to use them.
If we all generally agree that quality is a good thing, then why aren’t there more high-quality apps and services out there? Because quality is hard.
Lots of things can affect the quality of your product, especially on large teams, including culture, incentives, skills and tools.
Most companies struggle to prioritize small quality and “fit & finish” design issues.
Quality is the way you work.
Polish is an easy word to equate to design tickets but it's an especially poor choice as most people tend to think it's defined as optional, obsessive and unnecessary details.
Build a working style that always pairs thinking about the long-term design direction of your surface area along with the short-term.
As much as designers want to go off in a corner and come back with magical designs and a roadmap, this really needs to be a team effort, even if your stakeholders are more in the "inform" role of the DACI framework.
For me, Figma is where initial hunches live; a starting point. Not final designs.
Please, never treat design as something you just handoff to engineers. That's a great way to devalue the contributions of the engineers on your team and lead to a worse product. Treat it more like a conversation between design and engineering.
It's also important as a designer to know when to push on something and maintain your quality bar and when to compromise. That's your superpower.
Everyone will hate working with you if you hold a high quality bar but don't know how to work within the context of your business goals and customer needs.
A shared understanding of what types of work meets and what type of work doesn't meet your quality bar, along with executive support, can help with prioritization.
Poorly run design systems can preclude valid design explorations in pursuit of consistency and efficiency; just using what's already there.
Applying your design systems thinking (or any other patterns you've worked with before for that matter) all too eagerly may prevent you from noticing the obvious.
A related tool I like to employ sometimes, especially to break out of my own personal design aesthetic and tendencies, is to ask myself, how would [another company] design this?
I might think to myself "Airbnb loves to have these huge headers, bold colors, dynamic cards and sheets, so they may approach it like this." Then I'd mock that up.. and do the same with other companies. I may hate it, but it will get me thinking.
Incentivize and commit to sunsetting features that are no longer your core focus, have low usage, or are otherwise detrimental to your product.
But without this rigor, your product could all too easily become cluttered, slow and become harder to maintain over the years.
Always leave adequate time after gathering new insights to not only design refinements, but build them and live with them for a bit first. It's too easy to compromise on quality in the face of existing timelines.
Quality will always be hard, but don't you want to make something great?
Comments ()