It was 10:59 PM on Friday night. I was a single 25 year old locked in a staring contest with a computer monitor. At a time when nothing in the world was more important to me than the next weekend night at the bars with my urban tribe, I was a web developer at the mercy of a merciless ‘experience designer’, backed by a business client that demanded pixel perfection for every version of every web browser you’ve never heard of.

The code freeze for the current release wasn’t until Tuesday, and despite the fact that the internet’s most feature-advanced checkout and fulfillment processes were cleared for deployment, I knew full well that I would be back for a minimum of three consecutive 14–hour days to get through this ridiculous list of horizontal and vertical spacing defects that were logged during design QA. I was being robbed of my intelligence, and my youth – I could not have imagined at the time that my deep disdain for the black turtleneck and beret types would ever subside.

That was the summer of 2001, only a couple releases before the dot com revolution dot bombed.

As ecommerce jobs became fewer and farther between, the fortunate among us web developers were swept up by a wave of business application rewrites, whose sponsors were eager to abandon client server architecture for the cost advantages of centralized support and deployment (that only web applications could deliver at the time). Suddenly I and several developers from my former team found ourselves in business application architecture roles, and most of us would come nowhere near the likes of an ‘experience designer’ for several years to come. When the old team got together to socialize, we would often celebrate that fact.

Life was grand in the absence of creative ‘a-holes’ making us write code to render rounded lines and test them for pixel rendering flaws across 17 browsers. We were finally in charge as developers; chartered to deliver multi-million dollar business systems on ATG and Websphere. Deference to the UI was among the furthest concepts from our imaginations. If our queries returned data or content to the browser, we were ostensibly a source file check-in from happy hour. When we found ourselves working on the weekend, it had to do with critical data or system performance issues, NOT UI defects.

It wasn’t until 2004 that I would begin to realize the absence of those deplorable creative types in our professional lives had something to do with our alarming project failure rate. At least in part, this is because no one bothered to tell us our failure rate was alarming, or that we were failing at all. So long as we were within tolerance of leading industry statistics, such concepts as ‘over budget’, ‘bad requirements’, ‘scope creep’, ‘delayed deployment’, and ‘failed user acceptance’, were simply realities of the daily grind. If the politics of the situation came to a head, we [the developers] produced good reasons to blame the business for poor articulation and they [our clients] returned fire with good reasons to suspect poor translation. Business goes on.

Were it not for the misfortune of my project getting cancelled in late 2003, I might not have had the great fortune of witnessing first hand the impact a talented experience designer can bring to the process and outcome of a business application development effort.

I was asked to lead development for a new hybrid BI application, and it was evident early in the analysis phase that we were faced with some vexing UI challenges. Another BI project team in my pyramid recommended a local UI design firm they had recently worked with, so I requested budget to enlist their help.

Frankly I wasn’t sure what to expect going in. I knew only that this particular creative group had earned the respect of some of my own technical heroes, and I was cautiously hopeful they would be able to help us. I certainly did not expect the experience would inspire me to an evangelize about the value of UI designers in development of business software, nor did I suspect it would permanently change the way I approached software development.

Beyond elating our business clients and making the technical team the envy of our pyramid, our project outcome earned the collective attention of the CIO and the board of directors - who formally recognized us for innovation. With an IT organization of 3,000 strong, this was not an insignificant feat. It was the first time in my career I would experience clients vocalizing excitement more than frustration about the software they would be using for work. Further, I knew their impression didn’t come from the thinking or abilities of the technical architects, business analysts, or developers on my team. Sure, we sourced and wired the data to the UI and ultimately delivered the system, but it was clear to all involved our clients were reacting to the user experience.

Difficult to swallow or not, we would never have achieved a similar result with the usual roles working in the usual process.

Had we done things in the usual way with the usual roles, all of the meaningful conversations between the technical and business teams would have occurred after the application was developed and deployed to a test environment (when the business had something tangible to react to). Because most of the time and money would already be spent, and because the UI would have been largely assembled on the fly by developers, we would also have experienced the usual tension between business and technical partners regarding change feedback.

“This is not what we envisioned” vs. “But these are your requirements?”

Our design vendor helped us avoid this predicament by teaching us to follow a process they referred to as UI-forward or experience-driven software development. All we had to do differently was develop the UI model before the data and object models; involve our business clients as approvers in the UI modeling process; and defer UI design decisions to UI subject matter experts [our design vendor]. These three subtle distinctions combined to make all difference in the world to our clients, management team, and executive leadership.

The hardest part was getting us [the developers] to concede what we considered to be our territory. In the end we were still able to contribute our core expertise to the project, but this time we were recognized far more for our accomplishments than we would have been if we had gone it alone - and we all knew it.

Three years ago I stopped developing software altogether and made it my mission to share this formula with the industry. In the time since I have yet to witness an experience-driven software project failure, and I'm excited to be a part of a team that continues to share this successful approach with technology organizations of all shapes and sizes.

_______________________________________________________________ Will Determan joined Factor_UE as the Accounts Director in February of 2006. Will brings the experience of a diverse technical background in development of large eCommerce and enterprise business applications. His efforts in varying project roles have been recognized with awards for project excellence in speed, client service, and business system innovation.

0 Comments on this article