IMG_0227.JPG

Written

The blog I've always dreamed of writing, written.

Development Tempered User Experience

Originally published May 12, 2015 5:13 PM

Ancient History

UX professionals come from generally one of two camps - visual design and academic HCI, or architectural design and development.  I’m firmly in the latter group.  My experience entering User Experience Design and Architecture was built firmly in the trenches of Front End Development.  

My earliest positions in digital marketing were titled Web Production, mostly because it was a component of a larger team that needed support on the front-end. Internet marketing in these days was managed a lot like print, but the rules for how to make content work, even simple links, frames and HTTP/IP routing were not so widely known. For smaller sites, that was the realm of the Webmaster.  The state of the art of web pages was table-based layout. In those days, we were pioneering loyalty-email marketing so reporting and tracking was paramount.  It was before search was so dominant, and content publishing was highly manual.  Email marketing to this day remains a mine-field of arcane, incompatible client code-bases. Troubleshooting email is like dealing with 100 different flavors of IE6.

Fast forward past an acquisition and you’ll find I’d self-grown experience with more arcane front-end techniques, such as DHTML and Javascript-enabled web components like XSLT and Ajax. Browsers were starting to support more CSS, but we still relied on Flash for highly visually-interactive modules. Performance of the code in the browser was an important value for high-traffic places like a homepage with daily visits exceeding 100,000.  
Before long, I was transplanted into start-up life in the pacific northwest. This team was working on installed enterprise applications, but using a web-front-end.  The framework was J2EE based, using an MVC framework for rapid development (Tapestry).  The expectations for interactivity exceeded anything I’d done in the consumer space, and required realtime process control instrumentation for a new market space called “Run-book Automation”.  No one else knew how to design AND develop for the web-UI on the team, but I was able to take a rough coded mockup from static to running code for a secure and scaleable web platform.

In those days, we ran software scrums to align the entire product and engineering teams to our objectives.  It was all too common to whiteboard out the basic idea with product/engineering/qa all at the table. The next couple days would be spent defining the exact interaction and getting a nightly build running with the results. More frameworks were starting to mature, and we integrated early jquery and dojo libraries. Visual design was left to the engineer closest to the code needing visual treatments(me), so I experimented with visual / aesthetic design. The app was for IT people, so expectations were low.

Two acquisitions later, and our little run-book automation tool is now part of Hewlett Packard and a pillar of their IT Automation suite of products spanning servers, networks, storage and other IT infrastructure components. Our private web-platform app is now being sold in international markets. We’ve moved from hand-rolled javascript interactions to more enterprise-grade tools like Adobe Flex and Google Web Toolkit - a Javascript generated application written in Java and cross-compiled.  Localization and Internationalization becomes a priority along with Accessibility and Performance.

This was the end of my time spend as a pure engineer with meager design skills. I was consulting with other UX Architects in the engineering branch of HP at this time, and decided that my interests were less aligned to code-reviews and bug-reports than they were to answering “What’s the value of providing feature-set X?”  or “What kind of person would find this interaction helpful and usable?“

While I was perfectly capable of monitoring clicks and running ant-build scripts to test out my changes in half a dozen browsers running in virtual machines, or spending the afternoon resolving a merge-conflict, it wasn’t as challenging as drafting a proposal for a new interaction flow, or a new way to present and understand the behavior of the system.  I found myself asking “why” over and over. Gradually, it became apparent that the more creative, design-thinking component of my activities was going under-served.

I pivoted in my next position:  UX Designer, team-of-one on another start-up engineering team.