What's missing?
Before I started working on the upcoming refresh to my Adobe XD course, https://www.dhirubhai.net/learning/learning-adobe-xd-14458903, I asked one simple question: “What’s missing?”
As it turned out, the answer was: “Where does XD fit into the UX process? “ Go broader than XD and that could be applied to any prototyping application.
There are a ton of what I call “whizzy” tutorials and examples out there with stunning designs, animations, interactions and so on. Then I started looking at other prototyping applications and, once again, I saw lots of “whizzy” eye candy. This was expected because they are prototyping tools. What is rarely, if ever discussed, is those “whizzy” prototypes are disposable. They will eventually get ripped apart by the developers and tossed out or filed away for reference.
That got me wondering about a few things.
The first, in many respects, is prototyping roughly falls into the middle of the UX process. There is a lot that goes on before these apps are flamed up and after the flames die down. The question was, “Can they be used to document the process leading up to the “flame up”. Turns out the answer is yes. There there are a ton of plugins and features built into these applications designed to do just that but I find it odd this part of the UX process is rarely, if ever, discussed or presented by the application manufacturers or the tutorialists.
Do developers ever turn to the designer producing these “whizzy” prototypes and say, “Nope. Can’t do it.”? Especially in Dark Mode. Tons of very subtle complex gradients, complex components with lots of interactions and motion and all there because it is cool. I am pretty sure, if subjected to User Testing, cool will quickly get downgraded to practical. Just once, I would love to see a developer jump into the comments section and say, “Cool design that works in theory. Then again, communism works … in theory.”
Do the manufacturers or tutorialists ever acknowledge the simple fact that a Design System not only lives in their project but also lives, in code form, on Github or elsewhere? Not really. Lots of “Use our app to build the Design System.” This is somewhat true. The visual elements are there and the document or library is a visual representation of the elements of the Design System but the tokens and other things that actually bring it to life live elsewhere. The design system is constructed through a close working relationship between the developer and the designer. When it works properly, it reflects the designers saying “Here’s how I see this button working.” and the developer saying, “Here’s how it really works”. I am not seeing a lot manufacturers, tutorialists or designers acknowledging the fact the Design System used does nothing more than strictly following the nomenclature agreed to between the designer and the developer and a visual representation of the elements of the Design System.
The end game, of course, is development and I don’t see the manufactures, tutorialists or whomever, acknowledging this simple fact: Prototyping applications are not development applications. Mind you , they will tout they are “Developer-friendly”, whatever that means. Developers will rip these prototypes to shreds as they wire it up. That cool, whizzy prototype, for want of a better analogy, is destined to become nothing more than a bunch of Lego pieces dumped in a box that eventually gets shoved under a couch.
Hopefully, I will have dealt with much of this in my course refresh because I asked a simple question: “What’s missing?”