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 implementation.  However, it gets tricky when interactions become more animated and complex; with the more "artistic" projects, there can be the propensity to create a development nightmare. I have always been a proponent of code-responsible design, using an approach that acknowledges 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 & The Team

Those of us at TBWA\Chiat\Day were tasked with doing their visual rebranding, advertising as well as 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 UX Lead Lester Dizon.  The actual development would be outsourced to a company called Area360. Because this was a website for an art initiative, getting an early start on visual design was of the utmost importance so Lester and I parallel pathed our UX work at the same time.  We took a pseudo-Agile approach, checking in and piecing together the experience one feature at a time.  This lead us to explore motion and layout with a fine-toothed comb and in a way that could help us compose interactions that fit Anders' vision.

The Solution

Pacific Standard Time

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 platform for iterative interaction design as well as descriptive documentation for our development partner, Area360. Just to provide context, though, below you can find the visual comps that the UX team settled on with Anders:

Screen Shot 2016-06-06 at 12.17.35 AM

Imitate Front-End

Axure is a certifiable pocket knife of tools. In lieu of ease-of-use in a working interface, it has one of the most robust toolsets for creating rich experiences with nearly production-level interactions. The canvas 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 (i.e. in order to not alienate Internet Explorer users), Axure-exported websites are made of coordinate-positioned divs and flattened images. This meant that true CSS would not be natively supported and therefore would need to be imitated when possible. This caused some hangups where the CSS styling 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: 400px;
<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, onMoveSet 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, section1.height]

As you can see, it is possible, but certainly not native to the Axure platform. Sure, the nature of this solution means that the page will be slowed by the Javascript event listeners (e.g. the looking for the window resize in order to fire a trigger), but the end product serves as not only a communication tool for the developer to write production code against but also a conversation point on responsive design with Anders. All in all, this type of sizing and positioning isn’t slowed down enough to warrant moving to a fully-coded prototype.  However, other interactions might.

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 navigation logo 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 entire navigation shrinks down and the image actually changes to the Condensed PST Logo (sundial only).  Let's start by taking a look at how this would look using Axure.

Logo Gif




  • 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 navCollapseTriggerMove 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 native and javascript.  Axure projects can be exported with 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;

The initial benefit to doing a hybrid build meant that I was able to make the prototype more functional, since it didn’t rely on physical manipulation of a 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.

I will admit that I was ridiculed for using jquery.

Create a Framework for Easy Collaboration

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, 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:

Parallax 2

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 once had aspirations of becoming the next Steven Spielberg and was familiar with video editing timelines. Therefore I was able to create a formula which converted scroll values into modular timelines of 10000 units, which I would then use to map out interactions on a micro level.


 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 "Axure parallax engine"), allowing us to make changes on the fly and enabling us to fine-tune a solution within minutes.

Parallax Engine


As of today, phase one of the Pacific Standard Time website is live, awaiting full rollout of the PST initiative sometime in 2017. The jury is still out on the effectiveness of the website, but certainly the collaboration process benefitted from 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 algorithms for future parallax projects.

All in all, wireframes, specifications, prototypes-- basically all UX deliverables are communication tools.  The key to proper collaboration is understanding the stakeholder needs and picking the right canvas for them.

Selected Works

Understanding SleepUser Research

Code-Responsible DesignRapid Prototyping

The Best UI is InvisibleMulti-Platform Design

Like what you see?

I'm always looking for people to connect with.

Feel free to email me at

Note: Although I'm always happy to help, I tend to miss shotgun requests.
If you want to connect please let me know what your favorite Star Wars movie was and why.

Or, there's always LinkedIn

Copyright © 2017 - Alan M Shen