Hacker News Reader

Comment by js2 | Hacker News Reader

This is an example of administrative burden. In this case, it's due to bureaucratic incompetence, but it is often an intentional policy lever to limit access to benefits:

https://www.nytimes.com/interactive/2020/01/28/upshot/admini...

https://www.nytimes.com/2018/01/18/upshot/medicaid-enrollmen...

View on HN

And just as often, I'd add that it's more about systemic factors. Let me quickly tell the story of GetCalFresh: https://www.getcalfresh.org/

This was built by some friends of mine, my former colleagues at Code for America. Their basic notion was that applying for CalFresh (our version of food stamps) was too hard. So they applied classic Lean Startup techniques to solve the problem. They ran Google ads and directed assistance seekers to a simple Typeform that had barely enough information for the best case, and figured out how to get people benefits Then they iterated rapidly. You can read more of their story in this two-part article: https://leanstartup.co/part-1-from-root-hypothesis-to-functi... https://leanstartup.co/part-2-from-prototype-to-real-transac...

From the stories I've heard from them over the years, the real problem was neither incompetence nor malice. It's that doing anything involving a lot of different people is really hard. The counties actually had online application for years. But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec. Like so much enterprise software, user experience just ended up being a low priority. There are lots of causes for that, but it's not like any single person is to blame. Everybody's just responding to their local incentives, trying to get by.

Happily, a lot of the people in government I've met truly believe in public service. For me the moral of GetCalFresh is that almost everybody involved wanted things to be better. The trick is showing them how to make that happen in the context of the system they're in.

> But those systems were built by large government contractors, and they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec.

Gets me to thinking about 'large enterprise' stuff in general. In the situations I've been on large enterprise projects, most of them were just modifying existing processes ('streamlining', etc), but there was no huge payoff at the end. In most cases, whether the end users could use the system at all, or 10% faster, or 50% faster, no one's job was going to be significantly changed. The 'enterprise' as a whole wouldn't change all that much.

I worked on a different system - years ago - creating a web-based ordering system. Previously, the company had orders faxed or mailed in, then keyed in to a system. This process took 2-3 weeks per month to get all the orders 'in'. We put up a web system, and they had all their orders in, in electronic format, in 18 hours, with no need to bring in temp workers to key in orders. That was transformative, but... even though the new system is vital, there's not much more that can be done with it - reducing 18 hours down to, say, 9 hours, won't have any effect on the company's operations. Going from 3 weeks to 1 day was transformative - they could make different supply chain decisions, better scheduling for materials/staff/etc.

At some point, many 'enterprise' system changes may not deliver transformative benefits, just incremental, and it may be harder to get anyone to care about incremental changes.

I get that for sure. But one of the lessons I take away from Toyota's history is that continuous improvement can make a big difference if it's tackled systemically.

There's a graph in one of Mike Rother's books, probably Toyota Kata that shows per-worker productivity of major automotive manufacturers. Toyota started behind; they were catching up from Japan's decimation in WWII. the US Big 3 eventually leveled off. Toyota caught up and then just kept going, allowing them to produce much better cars for much less.

At some point a US automaker in trying to understand it ordered parts from a Japanese supplier. When they received the parts, they did their standard QA checks, measuring part size and variance. Except they couldn't measure the variance, because their instruments weren't precise enough. That high precision allowed downstream improvements: higher quality, lower cost.

So sure, the local optimization of order entry from 3 weeks to 1 day removed a bottleneck, improving the whole flow of the system. But it's not like the system had no bottlenecks. As always, the bottleneck just goes somewhere else. And even when a given process isn't the bottleneck, removing waste is always beneficial. The problem isn't that the change isn't worthwhile. It's that a company's threshold for "significant" is too high.

> removing waste is always beneficial. The problem isn't that the change isn't worthwhile. It's that a company's threshold for "significant" is too high

I don't disagree in theory. But convincing someone to spend time money on something with a low ROI is usually a challenge. A bunch of low ROI projects, coordinated over time, can provide a larger ROI when viewed strategically, but you have to have the right people in place to take that view.

Definitely! And I think that's often symptomatic of other organizational issues. E.g., A lot of American business culture focuses on local incentives and optimizations. If a manager is being evaluated and paid based on metrics A, B, and C, how much can we expect them to ignore that and solve systemic problems?

The standard MBA solution to this is that higher-level managers must design ever more elaborate systems to correctly measure the right behaviors. But a) that's somewhere between hard and impossible, b) the people filling those positions are only human, and c) the average CEO tenure is ~5 years, and executive tenure in a given position is even lower, so there's not a lot of incentive for anybody to create a system optimized for long-term value.

> they focused on satisfying the law and the rules. They focused on completeness, on perfection, on conformance to spec

Did the gov contractors do things like ensure the site was accessible? Because those laws exist for a reason, and the official government website SHOULD be held to comply with them. Sometimes this is detrimental to how slick a site looks.

While your friends site has much less of an obligation to comply with this kind of requirement, a quick check shows that something as simple as contrast is not good enough for vision impaired users https://wave.webaim.org/report#/https://www.getcalfresh.org

This ideas that > user experience just ended up being a low priority may be better stated as > user experience for people like me just ended up being a low priority

I feel compelled to step in here and hopefully provide some insight on what that report means, because it doesn't appear to be what you implied.

* Edit: The header image failed to load for me and complicates much of what I said in the following paragraph; it isn't as cut and dry as it first appeared.

First off, that automated WAVE report is stellar for GetCalFresh. The color contrast here is an excellent example of strict conformance to WCAG 2.0 AA contrast requirements. (Most of the site is hitting AAA contrast requirements, which is above and beyond.) The report identifies a issue for an image element's contrast in the footer. Please note that this is a false positive; the actual visual contrast meets the requirement.

Heading levels are always a bit of a mess as projects get larger, but as the linked report shows, they could easily be improved slightly in this case. That's not going to outright break the site or render it inaccessible; however, it is a slightly less navigable experience for a user.

Finally, it's important to look at both the spirit and practice of conformance to accessibility standards. In spirit, these are usability standards. You can build something that checks all the automatically enforceable, auditable boxes in the standards, but is unusable in practice. Or you can focus on delivering a strong experience to users, focusing on the POUR principles, and I'd argue that's what an accessible experience should look like (not to exclude ensuring the more baseline elements of conformance, of course).

Thanks for clarifying! I am not an accessibility expert so sounds like I misread the report :D

What GCF did is commendable, and I am happy to hear that they did well on the accessibility side. At the same time my goal was less to point out an issue with GCF, but rather to point out that government websites may not feel as slick as we're used to for a variety of reasons that a quick look may not reveal.

Thanks for pointing it out! I don't know anybody working on it any more, but I encourage you to contact GCF and let them know.

You're welcome to evaluate the government contractor sites yourself. You can start here, but the tool varies by county: http://www.benefitscal.com/

Picking the first one, I see more errors: https://wave.webaim.org/report#/https://www.mybenefitscalwin...

And I should add that technical compliance with standards is one thing, and actual usability for people with disabilities is another. Given that the contractor-built application tools were hard for everybody to use, I would be surprised to learn that they were notably better for people with disabilities.

The specifics aside, I think you make a great point. Governments are mandated to serve everybody, while startups are mostly interested in people they can easily profit from serving. So startup-world techniques need to be applied differently in government contexts."Up and to the right" isn't enough.

Perhaps the needs of the many should outweigh the needs of the few?

No. One, the needs often aren't in conflict. Building an accessible website doesn't hurt people who don't need it. Two, government is there to serve everybody, and in practice a lot of the people it serves directly are the ones already neglected by commerce, so it needs to be especially good at not just ignoring "the few".

I think that this is the exact opposite of the point of government programs. We try to build these programs in such a way that they avoid the tyranny of the majority. Especially when you consider that those who need accessible interfaces are more likely to need government assistance in other parts of their lives.

There is little need of any sort of trade off as simple enough sites are trivial to make accessible.

The convenience of the many outweighs the needs of the few.

Not for The Ones Who Walk Away From Omelas.

Clear summary. As a security pro, I've stopped developing products and solutions aimed at enterprises because I'm just no longer interested in helping them. A product "aimed," at anyone is going to fail anyway, but what clicked was building something to enable somebody's bureaucracy workflow isn't improving lives, and any product that sidesteps, replaces, or breaks bureaucracy is going to find itself isolated by it. Bureaucracy isn't a problem to be solved, it's just their way of life.

Next project is going to help individual people, and not organizations.

Is there a list anywhere of bureaucratic processes like this that could use a more streamlined tool built on top of them?

This type of project seems like a much more impactful use of developer side project time than almost anything else.

I don't think building the tool is the real problem. I think it's figuring out which tool to build. And creating strong enough relationships that somebody on the inside will work with you long enough to iterate your way to enough success that you all can prove the value in what you're doing.

Exactly, and it’s not just in one state. Florida’s website was apparently designed to keep the reported unemployment rate low, by making it difficult or impossible to file.

https://www.huffpost.com/entry/florida-unemployment-website_...

Reply on news.ycombinator.com