Building a Code-Friendly Design

In Development, Prototyping, UX Design
Click for TL;DR (Summary)
Our goal was to create a website for the Getty art initiative, Pacific Standard Time. As a project for an art client, we would be faced with the temptation to create outlandish and non-code-friendly designs; however we were able to design responsible through open communication with our local tech team and prototyping within code and Axure.

For most web projects, I believe UX designers can get by without knowing how to code.  Static sites can be designed with simple click through interactivity and a good developer should be able to have a open dialog about requirements.  Where it gets tricky is when interactions become more animated and complex; when it comes to these more “creatively open” projects, there can be the propensity to create a development nightmare. Therefore I have always been a proponent of code-responsible design–using an approach (and tools) that understand and acknowledge (at least at a high level) the systems that actually produce the final product.


Pacific Standard Time

Pacific Standard Time (PST) is an art initiative held by the Getty foundation every few years across Southern California. Various art exhibitions are featured over the course of the initiative, all centered around a common Southern-California-based theme. It is a collaborative effort between various participants and sponsors, so there are a lot of stakeholders that need to be taken into consideration throughout the process.

The Task & Team

Those of us at TBWA\Chiat\Day were tasked with doing their visual rebranding, creating their advertising as well as designing their updated website. As a User Experience Designer, I was brought in just for the website portion.  Also working on the project were Visual Design Director Anders Svensson and Lester Dizon, the UX Lead.  The actual development would be outsourced to a company called Area360. Because this was a website for an art initiative, visual design was of the utmost importance so Lester and I did our UX work at the same time that Anders did visual explorations, taking a pseudo-Agile approach (quite a step from the traditional waterfall model that traditional advertising agencies are built upon).

The Situation

The Needs

The first step in understanding what we were building was understanding the requirements of the site:

Introduction and Information

First and foremost, the website is meant to introduce people to Pacific Standard Time. The initiative has been around for something like 14 years. I’d imagine with backing by Getty and every major art institution in Southern California, it is well-known in the art circles. However, the site is also meant as an opportunity to introduce art to the uninitiated by drawing a connection with the Southern Californians and showing art in the context of their rich history. But, of course, there will always be that issue of brand equity, as “Pacific Standard Time” is usually said in the context of time zone.

Exhibition Information

The site serves as a way to excite people about the different exhibitions that are participating in the initiative. Ideally this can provide a preview of the content, a brief background of what went into each art exhibit as well as times, dates and locations.


Dozens of partners all over Southern California are opening their doors for this event, so there isn’t a central location where someone can just “attend” Pacific Standard Time. There needs to be some way to list all of the different locations for Pacific Standard Time participants in one place.

Press Materials

Press are absolutely pivotal in driving interest to PST. A lot of people are initially resistant to new things like art, but are more open minded in the context of media partners they follow (for example LAist or Timeout). In order to best-equip these press partners in drawing in more visitors, we need to provide information and high-resolution assets.

Sponsor Love

Pacific Standard Time is part of a non-profit organization and a lot of its operational income is from sponsors. There needs to be a place to present these sponsors on the website as a way to show appreciation.

Competitive Research

Art, like anything else that vies for attention, does have a level of competition to it; the PST website would surely be compared to the websites of the other art exhibitions both in Southern California an across the world.  Even if the average user doesn’t make a conscious effort in comparing the Pacific Standard site to, say, the Guggenheim’s website, there is still the possibility of a subconscious expectations of content and presentation.  Therefore I took a look at art events and other popular events in an effort to benchmark the industry standard as well as grade the utility of the Pacific Standard Time website.  The Competitive Analysis can be found below:


We took a look at not only the Art institutions but also cultural events in which patterns for finding event information would be practiced and reinforced. Therefore, in addition to big art names like LACMA, MOCA and The Broad, we looked at events like Coachella and Creative Time Summit.  I was able to grade each of the categories with a Green (positive), Yellow (neutral) and Red (negative) background so we were able to lock down best practice features as well as growth opportunities.  Through this we were able to work with the clients to identify the task we had ahead of us.

The Challenge

By looking into the competitive sites, we were able to settle on a goal of a friendly medium–it would have the utility of the Los Angeles County Museum of Art website but also feature some of the magic that went into Guggenheim’s interactive exhibition discovery process. This was our compromise into making a site that would be able to stand alongside the art that it is featuring while still retaining usability and functionality.





Now it would be easy to get carried away with injecting art into a site–working with a set schedule and an external development partner, we had to be very conscious of feasibility and scope as we fit into a larger waterfall process. Therefore we found that the best way to design the site in a way that would provide clear direction to the development team would be to build a functional prototype in Axure RP Pro. Because the design team was all in-house, we would be able to tweak and iterate all of the interactions quickly and be able to hand off the prototype for relatively seamless development.

The Solution

For this particular write-up, we’re going to gloss over the lion’s share of the pre-prototyping design process. Yes, we have some robust wireframes and yes, a lot of work happened prior to the actual prototype. But for the titular subject matter of designing a code-friendly site, the prototype provided the richest source of documentation for our development partner. Just to provide context, though, below you can find the visual comps that the UX team settled on with Anders from visual design:

Screen Shot 2016-06-06 at 12.17.35 AM

And without further ado, here are some of the biggest learnings from creating a code-friendly design:

Imitate Front-end Languages

Axure is a certifiable pocket knife of tools. In exchange for ease-of-use, it has one of the most robust toolsets for creating rich experiences with nearly production-level interactions. The design UI itself, however cluttered, creates a framework of drag-and-drop objects that can change and react to most web events and actions without any knowledge of front-end languages. However, by remaining a tool that could be universally used, devoid of client-side compatibility issues, Axure-exported websites are made of coordinate-positioned divs and flattened images. This meant that true CSS would not be natively included and therefore would need to be imitated when possible. This caused some hangups where the CSS structure would normally have been simple.  Let’s take, for example, the simple structure of having two window-sized sections stacked on top of each other with the second div having 400px content in the center:

.section {
width: 100vw;
height: 100vh;
.content {
margin-left: auto;
margin-right: auto;
width: 100px;
<div class=”section” id=”section1″> Content
<div class=”section” id=”section2″>
<div class=”content” id=”centerContent1″> More Content

This is a fairly light and straightforward approach and can easily be implemented within a webpage. On the other hand, in order to retain proper div size and positioning in Axure, we would need to understand when events needed to be fired in order to recalculate coordinates and sizes.  I then created a framework was based on event listeners like onPageLoad (when the page loads), onWindowResize (every time the window size is changed) and onMove (every time a specified object is moved).

onPageLoad move windowResizeTrigger by [0,0]

onWindowResize move windowResizeTrigger by [0,0]

For windowResize Trigger, onMove

  • Set section1 size to [window.width x window.height]
  • Set section2 size to [window.width x window.height]
  • Set centerContent1 size to [400 x section2.height]
  • Move section1 to [0,0]
  • Move section2 to [0, section1.height]
  • Move centerContent1 to [(section2.width-this.width)/2, 0]

As you can see, it is equal parts doable and unintuitive (and most assuredly not native to the Axure platform). Sure, the nature of this solution means that the page will be slowed by the Javascript event listeners looking for the window resize in order to fire this trigger.  However this is meant to be a communication tool for the developer to write production code, and this type of sizing and positioning isn’t slowed down enough to warrant moving to a fully-coded prototype.

When in doubt, inject code

The above example can be done within the realm of Axure (or potentially any substantial prototyping tool).  However, there are some things that are not natively going to work.  Take for example the Pacific Standard Time scroll interaction.  At the top of the page, the Full PST Logo (sundial with words) is shown as part of a fixed upper nav.  However, on scroll, the navigation shrinks down and the image actually changes to the Condensed PST Logo (sundial only).

Logo Gif

Let’s first take a look at how this might be built within Axure

  • Create a dynamic panel Nav to be fixed to 0,0
  • Within Nav, create another dynamic panel called navLogo with two states:
    • State 1: Background-image is Full PST Logo (sundial with words)
    • State 2: Background-image is Condensed PST Logo (sundial only)
  • onWindowScroll: set var scrollAmount = [window.scrollY]
  • onWindowScroll: move navCollapseTrigger
    • Move navCollapseTrigger
  • onMove for navCollapseTrigger:
    • if scrollAmount = 0:
      • Set navLogo to state 1 (fade 100 ms)
      • Set size navLogo to 84px (pin top left 100ms)
    • else if scrollAmount does not equal 0:
      • set navLogo to state 2 (fade 100ms)
      • Set size navLogo to 64px (pin top left 100ms)

In theory this setup should work. Functionally, there’s a scroll listener, and every time a scroll happens, it activates a trigger that checks to see if the scroll is all the way at the top.  If it is, it then activates the grow function; otherwise it activates the shrink function. The problem is in the inefficiency of the event listeners.  The onWindowScroll function isn’t perfectly firing every pixel, so it misses the 0px mark on occasion.  On top of that, each of the 100ms actions is uninterruptible, so scrolling to and from the top tends to break.  Since this isn’t wasn’t an ideal situation for a functional prototype, the better option was to use a hybrid of Axure and code.  Axure projects can be exported with a code injected into the <head> of the page, so this particular feature would do well with jQuery’s addClass method:

<script type=”text/javascript”>
        $(window).scroll(function() {
                var sc = $(window).scrollTop()
                if (sc = 0) {
                        $(“[data-label=’JS Header’]”).addClass(“small”);
               }  else {
                      $(“[data-label=’JS Header’]”).removeClass(“small”);

        div [data-label=”JS Header”]{
                height: 84px;
        div .small {
                height: 64px;

*Note: Formatting above is handled by WordPress; every time I publish, spacing takes on a mind of its own.

The initial benefit to doing a hybrid meant that I was able to make the prototype more functional since it didn’t rely on physical manipulation of javascript event listener. Additionally this meant that the project was closer to a language that developers would be able to translate into production code; something pivotal in a relationship with an external development partner.

Create a Framework for easy tweaking

In the initial designs for the Pacific Standard Time “About” page, there were various content blocks that would scroll and fade in and out via parallax.  Prior to this I hadn’t worked on a parallax project and I had an incredibly difficult time wrapping my head around the idea of scrolling via pixels and animation, and I was coming up with some really insane and nonsensical formulas for positioning:


However, at some point around around 2 or 3am I finally realized something: the scroll is a timeline and all of the actions are simply pieces on that timeline.  This seemed like a no-brainer to me since I have a background in film editing from when I once had aspirations of becoming the next Spielberg. Therefore I was able to create a formula which converted scroll values into modular timelines of 10000 units, which I would then map out interactions.

Parallax 2

It was around this time that I also realized that, although I was building this prototype and working on bringing some of the “magic” to life, I wasn’t the only stakeholder involved in the process. I would need some way to tweak the timing and positioning quickly and effectively; therefore I needed to create a live editor. Luckily I had the foresight to not hardcode anything and instead use local variables for all of the values which affected the animation.  I then created a barebones editor interface (lovingly dubbed the parallax engine), allowing us to make changes on the fly and enabling us to fine tune a solution within minutes.

Parallax Engine


Phase one of the Pacific Standard Time website is live currently in preparation for the actual PST initiative start date of 2017. The jury is still out on the effectiveness of the website, but certainly the design process was beneficial to this particular workflow. In addition to creating both an engaging and code-responsible design, we were also able to create frameworks which would be able to be used in other projects. I spoke with our TBWA\Chiat\Day technology lead about the parallax engine that I built, and I was able to help him write formulas for another parallax project that we’re working on.

Final Axure Prototype

Live PST Website