Strategy Blog: Viget Labs

Brian Talbot - User Experience Designer :

(X)HTML Prototyping and Agile Development go hand-in-hand. When working in a faster, more iterative process, there are definite benefits to using (X)HTML to communicate an interface and the various flows users traverse through it. Along with those benefits come challenges that many UX professionals continue to wrestle with. Existing wrestling matches aside, another challenge presents itself once the prototyping phase has served its initial purpose. After that point, do you throw away that front-end development work or re-cycle it into the foundation of the project to be visually designed and technically developed?

The Scenario

On a recent project that involved developing an application on a very aggressive timeline, we came across that very question after jumping into agile project planning. During planning, Jackson and I were tasked with rapidly designing the application's interface. To save time, we agreed to divvy up the interface (based on common user flows) and sketch concepts as a first pass. Validating and solidifying these sketches by jumping into (X)HTML prototyping was our next step.

Following those process decisions, we tackled the question of whether to recycle or toss our work (once our goals were accomplished). For our team at-large, the decision to re-use the markup made a lot of sense given the limited schedule, small team involved, and collective experiences we UXers had in producing production-level markup. For the developers on the project, that meant using our prototypes to inform the application's modeling, structure, and eventual output. Recycling -- for the visual designer -- meant visually theming the interface we'd design, and then visually styling the markup we'd use for our prototypes.

With that plan in mind, we set out an iteration timeframe ahead of the designer and developers. A few busy weeks went by.  And while I am extremely proud of the work, collaboration, and final product that the team produced, the debate on whether or not to use prototype (X)HTML during production still wages on for me. Here's where my thinking on the topic:

The Benefits

1. Efficiency — When prototyping in (X)HTML, there's the potential to save time and effort down the road by taking a first pass at items such as semantic markup, general interface layout, and content generation.
2. Using a Universal Language — Producing a prototype in a format that not only your UX team knows (cough .graffle files cough), but your own cross-disciplinary project team has more experience with can have a huge impact on the team's understanding of the interface, and its scope and capabilities. (X)HTML is perfect for this, as often both developers and designers alike are more than familiar with it. The extra semantic weight, consistencies, and information (X)HTML gives the content within an interface can add to these groups' understanding of modularization, functionality, and even different states of the interface as it gracefully degrades.
3. Eliminating Ambiguity — Recycling front-end development in future project phases means that elements such as status messages, in-page interactions, and various conditional states within an interface are at least noted, if not discussed and acted upon during the first UX pass. Often, when prototyping through paper and passing along, these are easier to overlook.

The Challenges

1. Blurring Responsibility — Being the first individual to touch the markup means becoming the local authority on it, as well. This doesn't completely match up with the traditional list of responsibilities requiring the visual designer or front-end developer be the keepers of the (client side) code. It can mean extra efforts and time spent on maintaining and communicating practices around this code instead of on UX-related tasks.
2. Conflicting Interests — A focus on using the medium of (X)HTML to review a more interactive form of an interface can be trumped by larger project and other long-term team concerns. While it is good enough for a proof-of-concept, is the markup generated production-ready? The markup may contain consistency and flexibility for prototyping purposes, but does it adhere to any internal or client-based standards? Repetitive items may be pulled into re-usable snippets to developers; however, is that code re-factored and abstracted appropriately?
3. Pulling Multiple Shifts — In Agile iterations -- or, at the least, in accelerated waterfall process steps -- things move fast. As Richard Cecil notes, this can leave a UX designer with the simultaneous responsibilities of carrying forth research and making design decisions for an iteration two steps away; developing the prototypes for the next upcoming iteration; and supporting the validation and implementation of the markup from the prototype now being used for the current iteration developers and designers. While, with planning, this can be manageable, the extra focus involved with implementing markup from the prototype demands could dilute the amount of attention given to the quality of future iteration work.
4. Trading “Popsicle Sticks and Paste” for “Brick and Mortar” — While the UX gains of prototyping in (X)HTML center on swift validation within an interactive medium, the tradeoff for those gains is, in many cases, stability in interface construction methods. Shortcuts are used to erect a scaffolding, styling used to show form for functionality's sake only, and states are described, but merely toggled without true logic. This philosophy certainly does not match up with the bulletproof-level quality of a completed application's logic and code. So, where does that transition happen from the former stateto the latter? It can be harder to cleanly move to the production-ready level when carrying over a foundation of assets created from the prototyping philosophy above. Artifacts of the scaffolding can easily be forgotten or misinterpreted and embedded within the production-ready work. Questions arise on if and how to logically segment the replacement of prototype-era with production-era work without disturbing other current prototyping or production work simultaneously happening.

For Future Consideration

Projects, especially in this economy, will continue to lean towards optimizing budgets and schedules. That means these scenarios of potential re-use aren't (nor are their benefits and challenges) going anywhere. So, how can we address the challenge of designing in the medium of (X)HTML, CSS, and JavaScript, and have our work used later in a project's life-cycle while still achieving the outcome we need from the exercise?

• What Were We Here For? — Don't lose focus of the primary purpose of using HTML for prototyping. It is imperative that the goals of the UX phase (validating the effectiveness of the interface against user expectations and behaviors) are fulfilled through this exercise first. If that's not completed, you're running the risk of spending even more time revisiting this phase than if you had taken a more static and traditional approach to begin with.
• Cut Your Work Out Ahead of Time — Practice Parallel Track Development, which includes preparing the proper amount of research and design work in time to also participate in the support of the current iteration's implementation. Sketching, re-usable and lightweight (X)HTML and CSS Libraries, as well as JQuery trusted plugins and state handlers such as Polypage can help you avoid re-inventing the wheel and cut some heavy lifting time while still producing a representation of heavier functional designs all within single-iteration timeframes.
• Play Well With Others — When working with designers and developers, communication is key. This means clearly communicating the state (e.g. in progress vs. complete vs. integrated by development) of prototypes to be handed off. We used a set of pre-defined classes on the <body> element of views to show their status of completion in attempt to avoid extra questions and confusion. Controlling the various revisions through version control of prototypes is a must as well with this. Virtual (through Campfire in our case) as well as in-person walkthroughs and Q&A sessions were a common occurrence during our collaboration to help with measuring scope, receiving team feedback, and prioritizing tasks.
• Reach Out to the Experts — If you're rolling your interface design work into an application or CMS, chances are you'll be working with not only client-side languages, but server-side technologies wielded by developers as well. And that (X)HTML you've written? Down the road, it is going to have to accommodate the visual designer's creative vision and theme. With those things in mind, reach out to the developers for a basic list of server-side syntax (includes, partials, links to other views, etc.) that may be helpful to you in expediting your work and revising it in the future. Similarly, asking for and adhering to any web and front-end development standards or conventions your visual designer may have will go a long way in providing a solid foundation.

And Yourself?

How common is the re-use of UX (X)HTML Prototypes in production in your experience? Do you think its valid to re-use the front-end development work completed as part of the prototyping throughout the project? If so, do you have any thoughts or resources you use for support?