app维持h5登录状态
Whenever you’ve worked in a team of designers, there has certainly been a time when somebody asked a question: “Guys, how do we know we’re doing a good job? Is the stuff we design good or just meh?”.
每当您在一个设计师团队中工作时，肯定会有一段时间有人问一个问题： “伙计们，我们怎么知道我们做得很好？ 我们设计的东西好还是仅仅是？”。
Of course, you’ll get a lot of answers to this when you do a good usability testing of your design (I shouldn’t stress that you should do that, right?) or when you talk to your user/customer/stakeholder (I don’t need to stress this one either 😉 ). But what about the time before usability testing? And the month or two, or six after you released the feature you’ve tested? Are you sure the thing you designed still works well even when literally everything around it changed?
当然，当您对设计进行良好的可用性测试(我不应该强调您应该这样做，对吗？)或当与用户/客户/利益相关者交谈时，您将获得很多答案。我也不必强调这一点😉)。 但是可用性测试之前的时间呢？ 发布测试功能后的一两个月还是六个月？ 您确定所设计的东西即使周围的一切都发生了变化，仍然可以正常工作吗？
We’ve been dealing with similar questions about the quality, resiliency, and consistency of our designs in design team at Kentico, and I dare say we might have cracked it 🙂
在Kentico的设计团队中 ，我们一直在处理有关设计质量，弹性和一致性的类似问题，我敢说我们可能已经破解了。
What we came up with can inspire anyone. From small teams working on simple projects, to big distributed teams working on big, complex products. Size doesn’t matter. After few discussions, trials and errors and a couple of iterations, we came up with a set of tools and guidelines, that make sure the design we put into our product is, and remains, good.
我们提出的想法可以激励任何人。 从从事简单项目的小型团队到从事大型，复杂产品的大型分布式团队。 大小无关紧要。 经过几次讨论，反复试验和错误和几次迭代，我们提出了一套工具和指南，以确保我们放入产品的设计是并保持良好的状态。
不是您的典型工具 (Not your typical Tools)
The tools we came up with are not gadgets, plugins or other design software thingamajigs. They are mental tools and that’s exactly their beauty. Anyone can use, modify or bend them to their needs and liking. They are fast and cost nothing to implement. And they work. (Trust us, we tested it 😉)
我们提供的工具不是小工具，插件或其他设计软件whatamajigs。 它们是心理工具，而这正是它们的美。 任何人都可以根据自己的需要和喜好使用，修改或弯曲它们。 它们速度快，实现成本低廉。 他们工作。 (相信我们，我们对其进行了测试😉)
Note:
注意：
The tools I list below work for us when they’re used consequently (one after another). Imagine a series of sieves with finer and finer mesh, filtering mistakes and missteps. This might be different for your product / team / organization, so don’t hesitate to bend it or cherrypick it to your will.
因此，下面列出的工具在使用时(一个接一个地)对我们有用。 想象一下筛网越来越细的一系列筛子，过滤掉错误和失误。 对于您的产品/团队/组织，这可能会有所不同，因此请随时弯曲或随意选择。
1.反馈回合 (1. Feedback Round)
No shit Sherlock! Yeah, the first tool you can use to make your design better is to ask for feedback. While asking fellow designers for their opinion is a wise first step, don’t forget to involve developers, product people, guys and gals from your Customer Support or whoever else who’s involved in creating the thing you’re building. They can (and often will) provide you with completely different and new points of view you as a designer should (at least) consider.
没有狗屎Sherlock！ 是的，可以用来使您的设计更好的第一个工具是征求反馈。 虽然征求同行设计师的意见是明智的第一步，但不要忘了让来自客户支持部门的开发人员，产品人员，人员和选拔人员或参与创建您正在构建的事物的任何其他人员参与。 他们可以(并且经常会)为您提供(作为至少一个)设计师应考虑的全新观点。
我们如何提供反馈-几点提示： (How we feedback — a couple of tips:)
- Your feedback round doesn’t need to take long but it’s good when it happens as often as possible 您的反馈回合无需花很长时间，但最好是尽可能多地进行
- The feedback you get should identify the biggest issues your design might have (not just from user perspective - don’t forget about technical feasibility and business viability) 您得到的反馈应该确定您的设计可能遇到的最大问题(不仅仅是从用户角度-不要忘记技术可行性和业务可行性)
- Use it whenever you think it’s necessary: while ideating solution, wireframing, prototyping,… 在您认为有必要时使用它：构思解决方案，进行线框图设计，原型设计等…
It’s great if the feedback is immediate and done in-person (remember the 5s test method?)
如果反馈是即时并亲自完成，那就太好了(还记得5s测试方法吗？)
- Lastly: it’s completely OK if you’re leaving feedback session with more questions than answers 😉 最后：如果您离开反馈会话时提出的问题多于答案，那就完全可以了😉
2.设计审查 (2. Design Review)
The second tool in our magic box is a good old design review. However, after some observation, we put a little twist on it. We noticed that designers tend to repeatedly review just one or two aspects of design. For example, they focused on a couple of defects in visual design, interactions or maybe some convoluted copywriting, but that was it. Deeper than quick feedback? For sure! Comprehensive? Not so much.
魔术盒中的第二个工具是一个不错的旧设计评论。 但是，经过一番观察，我们对此稍加改动。 我们注意到，设计师倾向于反复审查设计的一两个方面。 例如，他们专注于视觉设计，交互或一些复杂的文案写作中的几个缺陷，仅此而已。 比快速反馈更深入？ 当然！ 全面？ 没那么多。
We addressed this issue by using structured reviews — each review should cover the most crucial aspects of any design:
我们通过使用结构化评论解决了这个问题 —每次审查应涵盖任何设计的最关键方面：
Problem-solution fit — Is this useful for our users? Does it solve the problem they’re facing adequately? Isn’t the solution creating problems somewhere down the road?
解决问题的方法 -对我们的用户有用吗？ 它能解决他们正面临的问题吗？ 解决方案不是在将来的某个地方造成问题吗？
Interaction design — Is the intended design understandable? What about the interaction sequence? Is the design compliant with usability heuristics and best practices?
交互设计 -预期的设计是否可以理解？ 交互顺序如何？ 设计是否符合可用性启发法和最佳实践？
Visual design — UI, typography, adherence to pattern library or design system, quick accessibility check.
视觉设计 -UI，版式，对模式库或设计系统的遵守，快速可访问性检查。
Copy & microcopy — Is the language we’re using easy to understand? Is the message we’re trying to convey clear?
复制和缩影 -我们使用的语言是否易于理解？ 我们要传达的信息是否清晰？
Metrics and validation — How do we know we’ve solved the problem / job to be done / issue successfully?
Internal heuristics of delightful design — yep, we have heuristics for that. 🙂 (but don’t rely on surface delight alone)
令人愉悦的设计的内部启发式方法 —是的，我们对此有启发式方法。 🙂(但不要仅依靠表面愉悦感)
Other — Any other thoughts or feelings you might have about the reviewed design.
其他 -您对已审阅设计可能有的其他想法或感觉。
现在，我们如何使用它？ (Now, how do we use this?)
Because review usually takes some time and thought to be thorough, we do our reviews online. The best tool for this (and yes, sometimes feedback rounds as well) turned out to be a simple Trello board. Reviewing someone’s design is not obligatory, however, it is in the best interest of a designer in need of a review, to get it from at least 2–3 people (including at least one senior designer). By the way, here’s a design review template for your free use 😉.
由于评论通常需要一些时间并且被认为是彻底的，因此我们在线进行评论。 最好的工具(当然是反馈回合，也是这样)是一个简单的Trello板。 审阅某人的设计不是强制性的，但是，从至少2-3个人(包括至少一名高级设计师)那里进行审阅，符合需要审阅的设计师的最大利益。 顺便说一下， 这是供您免费使用的设计评审模板 😉。
- Designs wait for review usually around a week. This way anyone has time to go through design, documentation and to think the whole review through 设计通常在一周左右等待审查。 这样，任何人都有时间去设计，编写文档，并考虑整个审核过程。
- Each reviewer should address as many aspects of design as possible. If they have nothing to say or object to, simple “no issues found” is sufficient. 每位审稿人都应尽可能解决设计方面的问题。 如果他们无话可说或反对，那么简单的“没有发现问题”就足够了。
- And yes, sometimes we bend the structure — that’s basically the purpose of the last point (“Other”) 是的，有时我们会弯曲结构–这基本上就是最后一点的目的(“其他”)
After some time, we found out that taking a structured approach to reviews didn’t solve just our problem with one-sided reviews — it also sparked a bigger interest in reviews. It’s simply easier to do a review when you’ve got a checklist.
一段时间后，我们发现采用结构化的评论方法并不能仅解决我们的单方面评论问题，还引发了人们对评论的更大兴趣。 拥有清单后，进行审核变得更容易。
3.可用性测试 (3. Usability testing)
The third line of defense against mediocre design we use is probably the most effective one. All of us have some kind of educated guess what’s usable and what’s not. Maybe many of us have some kind of acquired “feel” or automated heuristic check-in our sub-conscience, but we ARE NOT users. There’s a lot written on the interwebs about usability testing, so I’ll just add up a few points on how do we do it:
我们使用的针对中等设计的第三道防线可能是最有效的。 我们每个人都有某种受过教育的猜测，什么是有用的，什么不是。 也许我们中的许多人在潜意识中都有某种获得的“感觉”或自动启发式检查功能，但我们不是用户。 互联网上有很多关于可用性测试的文章，所以我只想总结一下如何做：
- every testing is prepared and conducted as rigorously as possible. If you want to track the quality of your designs over time you need to be consistent with this. 尽可能严格地准备和执行每个测试。 如果您想随着时间的推移跟踪设计质量，则需要与此保持一致。
we take good care of our research design (making clear what exactly do we want to find out), hypothesis formulation and preparation of our test scenarios. If you want to know more, check out this great article about research design by our researcher Adéla Tofflová
我们会精心研究设计(明确我们要找出的确切内容 )，假设公式以及测试场景的准备。 如果您想了解更多信息，请查看我们的研究员AdélaTofflová 撰写的有关研究设计的精彩文章
- there’s recording and transcript of every testing session, and the findings are linked to our feedback database (for example Productboard) 每个测试环节都有记录和成绩单，调查结果链接到我们的反馈数据库(例如Productboard)
We used to measure SUM (Single usability metric) in each testing session, but now we switched to measuring just SEQ (Single ease question) — it predicts task time and task success nicely and it’s less work.
我们曾经在每个测试会话中测量SUM( 单一可用性指标 )，但是现在我们切换到仅测量SEQ( 单一难度问题 )，它可以很好地预测任务时间和任务成功，并且工作量更少。
To make sure that testing session goes as smoothly as possible we use this Usability testing checklist.
为了确保测试会话尽可能顺利，我们使用此可用性测试清单。
4.持续评估 (4. Continuous evaluation)
While all the things I mentioned earlier were mostly qualitative, now we’re moving into the quantitative realm. With continuous evaluation, you’re asking questions like? “How can we track the performance of an implemented feature overtime” or: “How do we know the thing we built works and is successful”. But first of all, you need to be very clear about what “successful” means to you. Can users find the feature in question? Click-through rate? Some specific conversion rate goal? The possibilities and options are endless and as we UX-folks tend to say — it depends.
虽然我前面提到的所有内容基本上都是定性的，但现在我们正在进入定量领域。 通过持续评估，您要问的问题是？ “我们如何随时间跟踪已实施功能的性能”或：“我们如何知道所构建的事物能够成功运行”。 但是首先，您需要非常清楚“成功”对您的意义。 用户可以找到相关功能吗？ 点击率？ 一些特定的转化率目标？ 可能性和选择是无止境的，正如我们UX用户所倾向于说的-这取决于。
随着时间的流逝，我们获得了一些经验教训： (A few lessons we got over time on how to do it:)
- Basically, each implemented feature has its own “custom metrics”. This makes sense since you’d probably want to ask different questions about how people use the comment feature, your landing page or invoice section of your SaaS. 基本上，每个实现的功能都有其自己的“自定义指标”。 这很有意义，因为您可能想问一些有关人们如何使用评论功能，SaaS的目标页面或发票部分的问题。
- We track everything we need via custom events and aggregate & visualize the data in a separate tool (such as Amplitude) 我们通过自定义事件跟踪所需的一切，并在单独的工具(例如幅度)中汇总和可视化数据
- Our usual go-to metrics include tracking adoption, retention, and demography of users 我们通常使用的指标包括跟踪用户的采用，保留和人口统计
- Talking about demography — lately, we’ve been able to create awesome data-driven personas (represented as user segments in our data analytics tool), so we can try to correlate our findings with them 🙂 谈论人口统计-最近，我们已经能够创建出色的数据驱动角色(在数据分析工具中表示为用户细分)，因此我们可以尝试将我们的发现与他们相关联🙂
- In some complex user flows funnel approach of looking at data is many times the most useful one. 在某些复杂的用户流漏斗中，查看数据的方法是最有用的许多倍。
At the moment we’re also experimenting with in-app quantitative feedback using UMUX — LITE format (it’s pretty cool, check it out! 😉) or per feature feedback using SEQ.
目前，我们还在尝试使用UMUX-LITE格式 (很酷，请检查一下！)或使用SEQ对每个功能进行反馈的应用内定量反馈。
- Every week or two we check the data we gathered and if it’s needed we fine tune the feature in question or re-evaluate some of our old design decisions. 每隔一两周我们都会检查一次收集到的数据，如果需要，我们会微调有问题的功能或重新评估一些旧的设计决策。
Overall, quantitative methods are a huge area of its own but if you’re willing to dive in, it will pay off.
总体而言，定量方法本身就是一个很大的领域，但是如果您愿意涉足，它将会有所作为。
5.定期在产品范围内进行健康检查 (5. Regular product-wide health checks)
The last thing in our toolbox is the regular product check. Previously we’ve been zoomed in the microcosmos of individual features but now we’re taking a step back and take a look through the wide lens. When we were discussing all the previous steps in this process we realized we cannot just look at singular isolated bits of experience, but we need to check how do they fit into each other. Imagine you went to a concert and 80% of the orchestra played in perfect pitch but 20% would be out of tune or falling behind the rhythm. The whole experience would suck. The same goes for product (and service) design.
我们工具箱中的最后一件事是常规产品检查。 以前，我们已经放大了各个功能的缩影，但现在我们要退后一步，通过广角镜进行观察。 当我们讨论该过程中的所有先前步骤时，我们意识到我们不仅可以查看孤立的经验，还需要检查它们之间的相互关系。 想象一下，您参加了一场音乐会，而乐团中有80％的演奏音调完美，但是20％的节奏会不合时宜或落后于节奏。 整个经验会糟透了。 产品(和服务)设计也是如此。
那么，我们如何确保产品的所有部分都协调一致？ (So how do we make sure all parts of our product are in tune?)
- We do a regular usability test of the whole product (or big chunks of it). We do these approximately once or twice a year. 我们对整个产品(或很大一部分)进行定期的可用性测试。 我们大约每年进行一次或两次。
- We defined 4–5 crucial user flows and jobs to be done and we test these with our users 我们定义了4-5个关键的用户流程和要完成的工作，并与我们的用户一起测试
We measure and track standard metrics — SUS (System usability scale) and SEQ for these
我们测量并跟踪这些标准指标-SUS( 系统可用性标度 )和SEQ
We also track product-wide metrics such as NPS, however we’re careful not to fall for the quantitative fallacy (numbers tell us, how much of something is happening but do not tell us why is it happening)
我们还会跟踪产品范围内的指标(例如NPS)，但是请注意不要落入定量谬误 (数字告诉我们发生了多少事，但没有告诉我们为什么发生了)
指导方针 (Guidelines)
All the tools I mentioned are proving to be very useful and important, however, over time we also defined a couple of guidelines that make them even better and more effective.
我提到的所有工具都被证明是非常有用和重要的，但是，随着时间的流逝，我们还定义了一些准则，使它们变得更好，更有效。
Be all-in — we test and review and feedback everything that goes into the product
全力以赴 -我们测试，审查并反馈产品中的所有内容
Ask the experienced — every review round should include a review from at least one experienced, senior or lead designer.
询问有经验的人员 -每轮审查都应包括至少一名有经验的，资深或首席设计师的审查。
No bureaucracy — Don’t turn this into a rigid process with a stamp of approval. We do all of this not because we have to, but because we want to. It’s up to each designer if they do this or not.
没有官僚主义 不要将它变成带有认可印记的严格过程。 我们这样做并不是因为我们必须这样做，而是因为我们想要这样做。 是否执行此操作取决于每个设计师。
回顾(以及为什么要期待) (Looking back (and why you should look forward))
Since we started to use this these tools, we undoubtedly tested and reviewed more designs, and I dare say we delivered better and more consistent experience across all shipped features. And by better I mean features that are usable, fulfill users’ needs, fit snugly into our app and sometimes even got praised by our happy customers. Structured reviews proved to be the best! Using Trello and asynchronous approach to them is a huge time and resource saver.
自从我们开始使用这些工具以来，我们无疑测试和审查了更多的设计，我敢说我们在所有已交付的功能中提供了更好，更一致的体验。 更好的是，我指的是可用的功能，满足用户需求的功能，紧密地适合我们的应用程序，有时甚至得到我们满意的客户的称赞。 结构化的评论被证明是最好的！ 对它们使用Trello和异步方法可节省大量时间和资源。
To wrap it up, the tools I described here won’t solve all your design QA (quality assurance) problems but they can help you at least in the beginning. This was the way we do it in our design team — you and your team might find useful something a bit different. Don’t hesitate to bend it to your needs, add stuff, remove stuff, do whatever you’d like. If you try it out, let me know. At the same goes for questions of course 😉
总结一下，我在这里描述的工具并不能解决您所有的设计QA(质量保证)问题，但至少可以在开始时为您提供帮助。 这就是我们在设计团队中所做的方式-您和您的团队可能会发现有用的东西有些不同。 毫不犹豫地将其满足您的需求，添加内容，删除内容，做您想做的任何事情。 如果您尝试一下，请告诉我。 当然也有问题😉
shoutout to my great colleague Jakub Šlancar, if you understand czech, you can read his blogpost about our design review process.
向我的伟大同事 JakubŠlancar大喊大叫 ，如果您了解czech，则可以阅读他 关于我们设计审查流程的 博客 文章。
and thanks to another great colleagues — Veronika Hradilova, Adéla Tofflová and Adam Amran for feedback, and Petr Augustin for a second pair or eyes and his helpful article on structured writing!
还要感谢另一位出色的同事 -Veronika Hradilova ， AdélaTofflová 和 Adam Amran 的反馈，以及 Petr Augustin 的第二副 观点 或他 有关结构化写作的 有用 文章！
资料来源： (Sources:)
10 Things To Know About The Single Ease Question (SEQ) by Jeff Sauro, at MeasurigU
Measuring Usability: From the SUS to the UMUX-Lite by Jeff Sauro, at MeasuringU
Measuring Usability with the System Usability Scale (SUS) by Jeff Sauro, at MeasuringU
Surface delight won’t help you build better products by Petr Augustín in UX Collective
翻译自: https://uxdesign.cc/5-tools-to-maintain-quality-of-design-in-your-team-73ab44b5ae63
app维持h5登录状态
扫一扫
42
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
