Hi Mike! I've been using XD quite a bit recently and it's been great to see the constant improvement and refinement. Thanks for posting an update.

If you're able to answer, I was wondering if you could shed a little light on your internal process for road mapping feature releases. For the last few updates at least, it feels as though "nifty" features have been prioritized over heavily-requested, mission-critical ones.

For example, we've had a few releases with incremental improvements on voice prototyping, but we're still missing essentials like rulers, guides, and basic text transforms (all of which are near the top of the "Top Ideas" list on UserVoice).

How are you balancing user requests with your own internal requirements? Could you possibly provide a little insight into how this process works now? Thanks!

Hey Mike! Thanks for posting. Do you have any plans to integrate XD with InVision (or any other existing web prototyping software), or is XD intended to be a standalone solution?

I don't fully agree with this. You're taking a hardline stance that saving as a concept is irrelevant across the board, which seems to be based solely off your personal experience with touch screen experiences. I do agree that the concept of saving is irrelevant for certain applications, but there are so many other types of experiences where saving is not only expected behavior, but a requirement. The world of software is much bigger than touch screen applications, and I don't think it's fair to make a wholesale assumption like this.

Bitcoin ATM Radar maps the big ones out and lets you search near you.

I read through your post and the info on the site and I'm still confused as to what this actually is. I get that—at its core—it's a usage-based billing service, but I'm having a hard time understanding the use case for this. Can you provide an example?

I see what you're getting at, but I don't 100% agree. More often than not (in my experience, at least), clients have a lot of difficulty articulating their needs and problems. Getting a wireframe at the outset usually cuts out a lot of unproductive back-and-forth and gets everyone to the solution more quickly.

That said, this only works if everyone is operating under the understanding that the wireframes are only suggestions and that you, the designer, will be interpreting them and modifying them appropriately based on the business needs. To your point, though, a lot of clients don't operate that way and just want you take what they've made and make it "nice".

This thing looks seriously powerful... it seems like they're coming back around and addressing the concerns with not focusing on the professional market.

I think they said it's somewhere between "one kidney" and "second mortgage on your house".

I'm wondering what qualifies him to say what is and isn't "hard" work. I'm curious about how many manual labor jobs (his benchmark of difficulty) he's worked himself to give him perspective to write this.

Most of all, though, I'd love to hear what he thinks about his own company. Since he works in tech—and not on a farm picking lettuce—starting, growing, and managing his multi-million dollar company must not have ever involved hard work... right? Hell, if we're going there, why should he even bother giving his employees all those nice benefits if their work is not hard? If their work isn't "hard", then they shouldn't need any of that stuff, right?

I might have taken this a little far, but my point remains: This man seems wholly unqualified to define "hard work" means for everyone else.

FYI, they do have an icon for saltiness. You might find it relevant, so I'll share it here (since you didn't read the report).