我们让它变得可靠。 接下来是什么? 可用性?

发布于 2024-07-16 10:18:52 字数 521 浏览 7 评论 0原文

我在一个小型开发小组工作。 我们正在构建和改进我们的产品。

半年前,我们无法考虑更高的特性,例如可用性,因为我们的产品存在太多问题。 许多错误、高技术债务、低性能和其他问题使我们无法专注于可用性。

随着时间的推移,我们已经大大改进了我们的流程。 我们所做的:

  • 真正的敏捷迭代
  • 持续集成
  • 测试(单元测试、功能冒烟测试、性能)
  • 代码质量“良好”
  • 无痛部署过程

因此,我们现在正在生成稳定、可靠的版本。 以下引用(转述)描述了我们目前的情况:

首先 - 让它发挥作用; 之后,使其可靠; 之后,使其可用

我们是极客,所以我们无法自己“制作”出色的 UI。 那么我们应该做什么呢? 您可以推荐什么方向? 也许我们应该聘请兼职或全职的可用性专家? 我们如何向利益相关者解释可用性的重要性? 我们如何让他们相信这是有用的?

I'm working in a small development group. We are building and improving our product.

Half a year ago we couldn't think about higher characteristics, such as usability, because we had so many problems with our product. Many bugs, high technical debt, low performance and other problems kept us from being able to focus on usability.

With time we've improved our process substantially. What we've done:

  • Real Agile iterations
  • Continuous integration
  • Testing(unit-tests, functional Smoke tests, performance)
  • Code quality is 'good'
  • Painless deployment process

So we are now producing stable, reliable releases. The following quote (paraphrased) describes our current situation:

first - make it work; after that, make it reliable; after that, make it usable

We are geeks, so we can't 'make' a great UI by ourselves.
So what should we do? What direction can you recommend?
Maybe we should hire Usability experts part-time or full-time?
How can we explain the importance of Usability to our stakeholders?
How do we convince them that this is useful?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(11

假装爱人 2024-07-23 10:18:52

您的商界人士认为什么能让您赚最多的钱? 去做。 也许可用性是下一步要做的事情,也许是更多的功能,也许是不同的产品。 这不是“极客”一定能够猜到的事情。

What do your Business people say will make you the most money? Do that. Maybe usability is the next thing to do, maybe more features, maybe a different product. It's not something a "geek" will necessarily be able to guess.

始终不够爱げ你 2024-07-23 10:18:52

我和你在同一条船上 - 我基本上生活在命令行上,并且我完全脱离了现代 UI(网络和桌面应用程序)。

对我来说,解决方案是为我的所有 GUI 使用真正的 UI 开发人员,而我只是住在后端。

这种安排有很多好处:

  • 不必再调试自己的蹩脚 UI :) 这是他们的工作,而且他们比您更擅长,所以不用担心。
  • 您的代码自然会倾向于 MVC 或至少分层 API 方法,这对于所有相关方来说都更容易编写代码。
  • 优秀的 UI 人员知道向最终用户询问什么问题,并且知道这些用户何时不知道他们在说什么。 我当然没有这个能力。
  • 你可以做你最擅长的事情,他们也做他们最擅长的事情,从而打造一个整体上更强大的团队。

缺点是显而易见的 - 你不仅需要为有才华的 UI 开发人员找到资金,而且还需要找到有才华的 UI 开发人员!

现在,我不能代表你和你的公司在你的市场中的地位等等(我也不做商业演讲:)),但如果你能负担得起另一名员工,它会给团队带来的回报比成本更多位置。 它对我有用!

I'm in the same boat as you are - I basically live on the command line, and I'm completely out of touch with the modern UI (both web and desktop application).

The solution for me was using a real UI developer for all my GUIs, and I just live in the back-end as it were.

There are quite a few benefits of this arrangement:

  • You don't have to debug your own crappy UIs anymore :) that's their job, and they're better at it than you, so no worries.
  • Your code will naturally gravitate to a MVC or at least tiered API approach, which is easier to code against for all parties involved.
  • Good UI people know what questions to ask end users, and know when those users don't know what they're talking about. I certainly don't have that skill.
  • You can do what you do best, and they do what they do best, making a stronger team overall.

The cons are obvious - you need to not only find the money for a talented UI dev, but you need to find a talented UI dev!

Now, I can't speak for you and your company's position in your market etc etc (I also don't do buisnessspeak :) ) but if you can afford another hire, it will give back more to the team than the cost of the position. It did for me!

别闹i 2024-07-23 10:18:52

您问:“我们如何向利益相关者解释可用性的重要性?” 但我不确定你们自己是否明白!

当“重要”的事情完成后,交互设计 (iD) 和可用性并不是您可以附加到现有产品上的东西。 它们应该从一开始就存在,最好通过小测试和研究以小迭代的形式完成。 我说的是廉价而肮脏的 iD/可用性,诸如低保真原型、仅由四个人进行的用户测试、拥有足够的统计数据来检测用户错误等。

如果您从一开始就不重视 iD/可用性,那么您可能会面临与竞争对手相同的蹩脚产品和/或在用户需要手术时为他们提供创可贴的风险。

You ask, "How can we explain the importance of Usability to our stakeholders?" but I'm not sure that you yourselves get it!

Interaction design (iD) and usability aren't things that you can tack on to an existing products when the "important" things are done. They should be there from the very first start, preferably done in small iterations with small tests and studies. I'm talking about cheap and dirty iD/usability, stuff like lo-fi prototyping, user testing with just four people, having enough stats to be able to detect user errors and such.

If you don't to iD/usability from the start, you risk ending up with the same crappy product as your competitors and/or providing users with band aids when they need surgery.

沫尐诺 2024-07-23 10:18:52

您的用户想要什么? 他们可能是最适合确定需求的人。

What do your users want ? They're probably the people best placed to identify requirements.

一梦等七年七年为一梦 2024-07-23 10:18:52

您是了解并理解该产品的人,因此不要仅仅因为其他人的头衔中有“可用性专家”,就认为雇用他们会以某种方式使您的产品可用。

另外,不要削弱你自己对可用性的直觉。 作为一名程序员,您一直在使用软件,您认为哪些产品最有用? 考虑一下您喜欢它们的哪些方面,并将它们与您的产品进行比较。

想想您的产品的用途,想象一下您是必须使用该产品的人,并想象希望它如何工作。 想想用户希望使用您的产品实现什么目标,并想象他们需要执行哪些步骤才能实现这一目标。 看起来很容易理解要做什么吗? 可以用更少的步骤完成吗?

最重要的是,与您的客户交谈。 找出他们认为令人困惑或难以完成的事情。 看看他们是否想出了自己的解决方法,以您最初没有想到的方式使用您的产品。

如果您在可用性方面投入与改进可靠性和部署一样多的思考、规划和努力,您最终会得到更好的产品。

You are the ones who know and understand the product, so don't assume that just because someone else has 'usability expert' in their title that hiring them will somehow make your product usable.

Also, don't undercut your own instincts for usability. As a programmer, you use software all the time, what products do find the most usable? Think about what you like about them and compare them to your product.

Think about what your product does, and imagine that you are the person having to use the product and imagine how you would want it to work. Think of what a user wants to accomplish using your product, and imagine the steps they would have to go through to do it. Does it seem easy to understand what to do? Can it be done in fewer steps?

Most importantly, talk to your customers. Find out what they found confusing or difficult to accomplish. See if they have come up with their own workarounds for using your product in ways you didn't initially picture.

If you put as much thought, planning and effort into usability as you did into improving the reliability and deployment, you will end up with a much better product.

萌面超妹 2024-07-23 10:18:52

在分析下一步时,这实际上完全取决于业务需求和需求。 目标。

高层管理人员是什么样的? 他们精通技术吗? 他们愿意接受新想法吗? 他们认为目前的产品是否需要调整、改进等? 该产品的需求仍然很高吗? 市场是否发生变化,导致产品/服务很快就会过时? 等等。

如果有真正的商业原因需要花费美元/时间/资源,那么您就可以开始探索产品改进。 然后考虑之前发帖者关于用户意见的意见。

When analyzing the next step it really all comes down to business requirements & goals.

What is upper management like? Are they tech-savy? Are they open to new ideas? Do they think that the current product needs adjustment, improvement, etc? Is the product still in high demand? Is the marketplace changing such that the product/service will soon be obsolete? etc. etc. etc.

IF there are real business reasons for spending the $/time/resources then you can begin to explore product improvements. At that point consider the opinions of previous posters regarding user opinion.

你又不是我 2024-07-23 10:18:52

我认识很多极客,包括我自己,他们都了解可用性,所以一种方法就是学习它。 另一种方式是引入可以进行 UI 设计和可用性的人员。

为了让他们相信可用性很重要:
如果你不会使用它,那就毫无用处!

我不知道你构建了什么样的产品,但你总是有客户,而客户总是喜欢可用的应用程序。 这将增加销售额、满意的客户数量并减少技术支持。

I know so many geeks including myself who know usability, so one way would be learning it. Another way bringing someone in who can do UI design and usability.

To convince them that usability is important:
It's useless if you can't use it!

I don't know what sort of product you build but you always got clients, and clients always love usable applications. This will increase sales, happy client count and decrease tech support.

梦屿孤独相伴 2024-07-23 10:18:52

它对您的用户有什么作用? 他们对可用性有何看法? 也许这对他们来说不是问题。

使其对您的用户更有价值。 提供更多商业价值。 帮助您的客户获得更好的投资回报。 通过让它做更多他们需要做的事情,做得更好(更准确、更快速、更可靠、更有用),或者以更低的成本(运行它所需的基础设施更少,降低维护成本)来做到这一点因为你提高了可靠性),更灵活(处理他们的业务变化)......

许多维度确实与你所指的技术维度相关(可用性、可靠性、稳定性等)。 但付费客户通常关心他们的业务需求/功能,而不是提供它们的技术需求/功能。

去和你的用户(或潜在用户)交谈

What does it do for your users? What do they think about the usability? Maybe it's not an ssue for them.

Make it more valueable to your users. Deliver more business value. Help your customers getter a better return on their investment. Do this by making it do more of what they need it to do, to do it better (more accurately, more quickly, more reliably more useably), or to do it at lower cost (less infrastructure needed to run it, reduced maintenance costs because you improved reliability), more flexibly (deals with their business changes)...

Lots of dimensions which do connect with the technical ones you refer to (usability reliabilty stability etc). But paying customers normally care about their business needs/features, not your technical ones that deliver them.

Go talk to your users (or potential users)

柳絮泡泡 2024-07-23 10:18:52

我关于可用性重要性的一句话:

  • 一个不可用的可靠系统有什么用?

如果您有一个已有用户的现有产品,那么是什么让您认为当前的 UI 不可用?

您是否怀疑可以进行一些微小的更改来极大地提高可用性,或者是否需要一些更具革命性的东西? 如果是后者,那么你现有用户的需求如何,他们是否愿意重新学习全新的UI?

编辑

由于多种原因,用户界面可以被认为是“差”的......

  • 它只是简单丑陋/过时/不“看起来像Windows应用程序”
  • 它使用与用户无关的隐喻或工作流程理解或想要做

第一个问题相对容易解决,特别是如果您聘请了一位出色的设计师。 解决办法相当于重新装修你的休息室并购买新沙发和电视。 同一个房间,不同的体验。 您现有的用户仍然可以使用此应用程序。

修复第二个问题会变得更加复杂和复杂,并且可能会真正影响您的代码库。 如果不了解有关您的应用程序的更多信息,则很难进一步发表评论。

My one-liner about the importance of usability:

  • What use is a reliable system that is not usable?

If you have an existing product with existing users, then what makes you think that your current UI is not usable?

Do you suspect that there are some minor changes you can make that will greatly improve usability or is something more revolutionary required? If the latter, then what about the needs of your existing users, will they be willing to re-learn a whole new UI?

Edit

A user interface can be considered "poor" for a variety of reasons...

  • It is just plain ugly / old fashioned / does not "look like a Windows application"
  • It uses metaphors or workflows which do not relate to things that the user understands or wants to do

The first of these is relatively easy to fix, especially if you hire in a great designer. The fix would be the equivalent of redecorating your lounge and buying a new sofa and TV. Same room, different experience. Your existing users would still be able to use this application.

Fixing the second of these gets a lot more complex and involved, and might really impact your codebase. It's hard to comment further without knowing more about your application.

瑾夏年华 2024-07-23 10:18:52

我认为答案是按事物的顺序排列的,你说它:

“首先 - 让它工作;然后,让它可靠;然后,让它可用​​”

但这里最重要的是“让它工作”。 功能“工作”的接受标准是它实际上可用。 如果没有,则不会执行。 那么它只是一块死代码。 死代码首先就不应该出现在系统中。

I think the answer is in the order of things, you say its:

"first - make it work; after that, make it reliable; after that, make it usable"

But the most important thing here is "make it work". Acceptance criteria for a functionality to "work" is that it is in fact - usable. If not, it will not be executed. Then it's just a block of dead code. And dead code should not be in the system in the first place.

为人所爱 2024-07-23 10:18:52

制作一个用户界面。

然后扔掉它,在尝试使用第一个之后再制作另一个。 然后尽可能地简化。 只要您可以通过编程方式确定用户想要从输入中获得什么,而不是进行多个显式选择,就可以这样做。 太多的按钮会导致瘫痪。

Make a UI.

Then throw that away, and make another after you tried to use the first one. Then simplify as much as you can. Any time you can programmatically determine what the user wants from inputs, instead of multiple explicit choices, do so. Too many buttons induces paralysis.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文