In November, I attended a great conference in Boston for usability professionals. User Interface 16, put on on by Jared Spool and User Interface Engineering, was a challenging and informative experience. However, in the midst of learning about HTML5, CSS3, Mobile Device Usability, and the challenge of matching user knowledge, there was a constant complaint, an elephant in the room that noone really knew how to solve:
Not between client and designer, or whether Mac, PC, or Linux was king (although I was in the majority with my MacBook), but between the UI/UX team and the Engineering team.
Almost everyone I was sharing tables with came from an art background. With few exceptions they all hated (and by hated, I mean loathed entirely) agile development models. They didn’t like the compressed timelines. They didn’t see how they could match their design techniques with the reality of pushing out code every two weeks.
Going through my head the entire time was an initiative Mike Seidle and I had begun working on just days before I left for the conference. An adaptive, modularized UI framework. The goal of the framework was to allow rapid prototyping of projects so that they would have a degree of polish and usability from day one, and not require a full redesign later on.
Now, as we hit the end of the year, our first version of the framework is up and running (it is, in fact, powering this very website). It made development easy and fast, but also kept the user experience from being compromised in the name of rapid deployment. But most importantly, the framework embodied an elusive trait between our Design team and the Engineering team:
The framework removed the need for the UI to dictate how the site was programmed, and kept said programming from influencing the user experience. When an engineer needs to put up a form, all they need to do is follow the proper semantic markup for the form. If they follow best practices and then load the UI framework, then in most cases, the framework will already be capable of handling it, even if it’s a vanilla rendering.
Even if it can’t, it doesn’t matter to the engineer. They just notify the designer that it isn’t handled and move on. The designer then modifies the framework to include the new element. This is a much smaller task then redesigning an entire page to accommodate the new element, and it can be done in parallel with the engineering work, so neither the designer or the engineer needs to stop and wait for the other.
It’s not a perfect system. We still have debates over whether things like IMG tags are legit in the HTML or if a plugin meets our UX needs. However, these debates get resolved and rolled into the framework - so they happen once, and once only, and it’s always about the framework, not stepping on toes.
In the coming weeks, I will post more about how the framework is built and how we use it.