Be nice. Or else.
Instead of quickly judging the bar, take a moment to understand their process--this is a good example of a mature (but lean) design team making a big decision using insight instead of opinions.
Notice where and how they measured their hypothesis (instead of relying on opinions), how much ideation they did before even starting the project, how they did usability and A/B testing while staying lean, etc.
I found it really helpful :)
Lots of valid points here, there's still a lot of work to be done on XD. Most popular feature requests are here: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/filters/top
That said, many of the requests listed aren't necessary for XD to be considered production-ready on a lot of UX/UI teams. If they fixed numbers 1, 2, 6, and 13, plus the ability to comment directly on prototypes, I'd be about ready to switch from both Sketch and Invision.
Here are my favorite XD features for the curious:
So a UI component would be a Table for example. We have a bunch of versions of our tables in Sketch--tall rows, short dense rows, sortable tables, etc. These are defined w/ pixel precision on an 8pt grid using the standard set of colors and type on each platform (web, ios, android). There's only one high-res spec for table, though.
The "feature" spec is separate--an example might be the Rainfall History page. The spec includes how the amount of rain should be formatted (units, degree of precision), how many days to show, what to show if there wasn't any rain, and what the columns should be. A different page, Heat History, would have different content in a similar format--this time units in degrees, with different columns, etc. The images on these pages are just rough wireframes of a table, but they both link to the original Table hi-fi spec.
Happy to answer any more questions if that's not clear!
I've been running the product design team at FarmLogs for a few years, here's how it went for us.
We didn't use anything more than casual documents or Invision for a long time. As our product grew large, it made it really hard for engineers, designers, and PMs to understand how our own products worked. Backend refactors would subtly break something without us knowing until a user complained much later, important details in how we showed data got lost in redesigns when a new person came onboard, etc.
Now we have two forms of specs: our "Design Language" is in Sketch documents shared in Zeplin, which help us maintain the latest version of all of our UI components, visual styles, animations to some degree, etc.
Our "feature specs" are wireframes and descriptions about the product itself in a wiki. They're co-owned with engineering and product management, and they describe what each page does, how the information should be displayed, edge cases, etc. These feature specs link back to the hi-fi Zeplin components so engineers know what "building blocks" to use to build each page.
It's a pretty new distinction for us, but the separation between abstract components that "hold" data and the data and pages themselves has already been a big help to our team.
I dig it
Ha! That actually describes our workday pretty well.
My hunch, too. Very useful, thank you.
I love it so much I moved across the country to do it! (Current positions are open for remote work now though).
Basically I tell people we're taking some of the most complicated kinds of data--geospatial satellite imagery of crop growth, real-time commodity market prices, etc--and distilling it down for an audience that needs extremely straightforward insights in their pocket.
I think the number one thing I look for in work is meaningful impact. Agriculture's impact on humans and the planet puts it at the top of the list.
Very interesting, thank you