3 ms·

My take from this paper is that a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from

My take from this paper is that a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors. These are all obviously very hard to do, and you have to really want them yourself or they won't happen. I'm surprised how controversial speedy UIs are, for example. JIRA is the most popular issue tracking system, and it's just SLOW compared to newer things like Linear. I see JIRA and would immediately disqualify it for use because the UI is so slow; it takes a minute to enter a bug, or a three-screen process to move a bug from one team to another, etc. But it has every feature people are looking for on its little checklist, so it gets chosen over systems that are speedy and productive. If you're doing electronic medical records, you need to implement all those long-tail features, and you need to make it fast. Paper is fast. You can't make logins take 1 minute, they need to happen in milliseconds. You can't discard peoples progress when they move to a different workstation. Things like that; the PM just has to say "no, this isn't acceptable", and find a team that can implement it well. I guess this doesn't happen, and look at the mess that it created.

axg11 4y ago
This is a great point - too many companies forget to optimize for speed of UX. My theory is because speed of UX isn't a strong selling point to decision makers. JIRA sells well because it's a safe choice (recent fuckups not-withstanding) and is very full featured. Speed of UX matters for the end user, unfortunately too often the end user has no say in the software they're using.
908B64B197 4y ago
> a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors. The problem here is we're talking government software, or IT-as-a-cost-center software. So the buyer is looking at the cheapest bidder. They aren't getting a team like those who solved the UX trifecta in the past (looking at the iPhone team at Apple here). > Paper is fast. You can't make logins take 1 minute, they need to happen in milliseconds. You can't discard peoples progress when they move to a different workstation. Paper isn't fast, it's cached. Parsing, archiving and indexing of paper is extremely slow (when actually done). The slowness of input in a computer system might annoy the user but the system overall is way more efficient. Now auth taking more than a second or two is just lazy programming (bet it's not exactly Google caliber engineers working on the project). > the PM just has to say "no, this isn't acceptable", and find a team that can implement it well. The problem here is he'll have to 10x the budget.

axg11 4y ago

This is a great point - too many companies forget to optimize for speed of UX. My theory is because speed of UX isn't a strong selling point to decision makers. JIRA sells well because it's a safe choice (recent fuckups not-withstanding) and is very full featured. Speed of UX matters for the end user, unfortunately too often the end user has no say in the software they're using.

908B64B197 4y ago

> a PM just needs to deploy the usual impossible UX trifecta: make it fast, make it easy, integrate all the different systems from other vendors. The problem here is we're talking government software, or IT-as-a-cost-center software. So the buyer is looking at the cheapest bidder. They aren't getting a team like those who solved the UX trifecta in the past (looking at the iPhone team at Apple here). > Paper is fast. You can't make logins take 1 minute, they need to happen in milliseconds. You can't discard peoples progress when they move to a different workstation. Paper isn't fast, it's cached. Parsing, archiving and indexing of paper is extremely slow (when actually done). The slowness of input in a computer system might annoy the user but the system overall is way more efficient. Now auth taking more than a second or two is just lazy programming (bet it's not exactly Google caliber engineers working on the project). > the PM just has to say "no, this isn't acceptable", and find a team that can implement it well. The problem here is he'll have to 10x the budget.