Two years ago, I was managing a team of developers and analysts who were creating a “metadata driven data warehouse” that would make it easy for our many different types of users to slice and dice their often complex data to satisfy their unique needs. We’d finished the core system, and we were just about to start cranking out a series of custom mini-data warehouses when we discovered a tool called Alteryx. Alteryx was expensive, but it promised to remove most of the need for any coding; any “power user” who is comfortable with Excel could do very sophisticated analysis by dragging and dropping to their heart’s content.
Given how complex our needs were, deciding either way it was a pretty big risk. So, we decided to do a quick and dirty bake-off. I felt sick, because from the outside it looked like making a big change in our strategy and going with Alteryx was the way to go. But much to my surprise, Alteryx’s shiny drag-and-drop approach got its butt kicked.
A lot of the reasons we stuck with our original approach were because of the unique problems and constraints we faced. But the bake-off also uncovered a fundamental weakness with a drag-and-drop approach. Something graphical works great when you’ve got a simple problem. But to do just about anything our users wanted, first you needed to prep the data by joining together a bunch of tables of data and sift it using complex logic. And that level of complexity produced a graphical picture that looked like a scene out of a rat’s nest or an episode of Hoarders. Paradoxically, if you used text — i.e., code — to capture that complexity, it was much easier to understand.
So as I begin my deep dive into the research on improving the user experience (UX) of coding, it’s worth remembering that sometimes a picture isn’t worth a thousand words. Or to put it another way, sometimes a bunch of words are worth a lot more than a picture.