Single biggest technical thing, anyway. IMO, the single biggest thing is focus and clarity in their communication. If people without a working mental model of software development can’t instantly understand the tangible problem it solves in their existing business process, they won’t even scroll past the break, let alone pay for it. Consolidation and modularity are solutions, but people don’t go shopping for solutions without a problem. Have you ever gone out looking for a better commercial version of work-related software you didn’t have any problem with? “App chaos” is way too abstract of a problem for most people to grasp. Do people have trouble sharing google docs over slack? Do companies have trouble with sharepoint and teams not being integrated enough? Does your tool do it better? Does your tool do it approximately as well, but cheaper? More reliably? If so, do people find the existing solutions too pricy or unreliable, or does that not impact them enough to care?
Unless they define, upfront, specific problems people really have, that their unified solution solves, then nobody is going to pay attention.
The second biggest problem is having an interface design team that makes all of those disparate apps consistent enough to be more usable than individual solutions. The fact that nearly no popular user-facing applications are developer-managed FOSS (as opposed to Firefox/blender/signal/et al which are managed by a company that hires professional designers) despite being free, tells you everything you need to know about dev-driven UI/UX. This is coming from someone that worked as a full time developer for years and contributed many thousands of hours of coding to FOSS projects before switching to design.
Fair point. I know little to nothing about design, and don’t really care about it. It’s not that I think it’s unimportant, it’s just not something I want to expend any time learning. To be fair, I’m also not trying to create any user-facing products.
To me, rsync.net is peak design. It has just enough modernity to appeal to people who might expect that, but it quickly gets out of the way and tells you what it is, why it matters, and how much it costs.
At the other end of the spectrum, there’s tarsnap.com, which is probably a turnoff for anyone who doesn’t like text. I love it (as, apparently, do enough other people to keep its author comfortably employed), but I get that it’s an extremely narrow niche.
There’s less than no shame in not having expertise in something outside of your area of expertise, and realizing that’s the case puts you way ahead of the pack. There’s a reason most designers you work with have relevant degrees, and the ones that don’t that are in high level positions in good organizations might as well have them— it’s just a lot more complex than most developers assume. When they realize that, great! When they’re swinging around giant Dunning-Krueger derived overconfident declarations about something you’re designing… not so great.
As a full-time developer for a decade, and in other technical roles for a decade before that, I had a few similar experiences with designers. One repeatedly insisted that Wordpress along with their ramshackle loopdy-looped spaghetti php plugin (still including comments from the tutorials they copied tidbits of code from) was robust enough to enough to replace our very tight Django-based code base that did a hell of a lot more than serve up our website… but they insisted it would take half as long to reimplement it all in php. There wasn’t even a good reason for it– they learned everything they knew about development by osmosis from working on web projects, and a mishmash of articles they read on the topic over the years, and after getting one piece of code to work in a low volume application, thought they were a dual-field specialist. That’s actually pretty rare among designers, but developers that feel that way about design are the norm. We all know what Larry Wall thought the three most important traits were for developers…
Unless they define, upfront, specific problems people really have, that their unified solution solves, then nobody is going to pay attention.
The second biggest problem is having an interface design team that makes all of those disparate apps consistent enough to be more usable than individual solutions. The fact that nearly no popular user-facing applications are developer-managed FOSS (as opposed to Firefox/blender/signal/et al which are managed by a company that hires professional designers) despite being free, tells you everything you need to know about dev-driven UI/UX. This is coming from someone that worked as a full time developer for years and contributed many thousands of hours of coding to FOSS projects before switching to design.