Hacker News Reader

Comment by ripe | Hacker News Reader

I was going to say exactly the same thing. This is precisely the issue with UX-led processes. When you're dealing with very hard engineering problems, you really don't yet know enough to be designing a product.

I think it's very interesting that Apple went back and forth on the purpose of the project: were they building an electric car that people could use? Or a self-driving dream car? This is a critical question. Depending on which one you want to build, the process has to be completely different, no?

My outsider impression: most Apple groups excel as "productizers" of technology that has already been developed, but perhaps not as developers of technology themselves. I guess the chip making shop that produced the M1 and M2 would not be this type of group.

View on HN

It depends where you draw the line in the tech stack. On the hardware side they've always worked at least at the same hardware level as any workstation or PC vendor, and often arguably lower than that working with component manufacturers to custom spec particular components.

They're an aggressive early adopter of new tech, putting in the work to adapt it to their product categories, sometimes directly funding tech development with partners to make that happen. They jumped on the tech for laser cutting aluminium laptop and mobile device bodies from aluminium blocks, gorilla glass for mobile devices, helped develop the specs and tech for retina and 5K displays, were actively involved in the development of open technologies like Wifi, USB, Firewire, etc. They've never been content to just buy parts off the shelf, pushing to promote the development of and get early access to new stuff other competitors didn't have.

On the software side they hired the best, including about half the former staff of Xerox PARC, the developer of the MACH microkernel, the developer of LLVM. You could argue that Apple didn't invent these technologies, but people at Apple did.

> This is precisely the issue with UX-led processes. When you're dealing with very hard engineering problems, you really don't yet know enough to be designing a product.

I suppose we can get into the weeds on how you define "designing a product," but under the right circumstances targeting a specific experience and working backwards to the technology has pretty clear benefits.

Ignoring Apple - because this kind of over-the-top process is just how they're wired - look at something like a modern automatic defibrillator. Literally any human being can use one with zero training because the goal was "make a defibrillator that someone can operate with one button" from the beginning.

If your goal is instead e.g. "make this existing defibrillator easier to use," you might still end up with a really good product but you probably don't have something that my mom could reasonably be expected to deploy if she runs across someone having a heart attack on the street.

>This is precisely the issue with UX-led processes

As opposed to engineer-led processes, which as we all know are infallible and always produce products that go to market 100% of the time :)

>I think it's very interesting that Apple went back and forth on the purpose of the project

This is the real reason it failed. The fact that nobody at Apple could say "this is what we're aiming to do" and then stick to that vision is more telling about Apple culture than it is about any UX processes.

> I was going to say exactly the same thing. This is precisely the issue with UX-led processes. When you're dealing with very hard engineering problems, you really don't yet know enough to be designing a product.

It's like the Wright brothers, before working on the Kitty Hawk, worked on mocks up of an online ticket ordering system.

Reply on news.ycombinator.com