Benefitting from Code Prototypes

The dashboard—the web application our audience engagement team will use to answer incoming questions—is a complex application with many parts and before we hit the ground running, I thought it would be prudent to create prototypes.

This decision was informed by the lessons Brian and I learned at General Assembly’s Mobile Prototyping Bootcamp. Though the workshop was centered on mobile apps, we picked up some cross-disciplinary techniques like creating prototypes out of paper and code. We learned that prototypes were a great way to test out an idea without investing too much time and resources to learn if we were correct in our assumptions and to answer any questions we might have about the project’s design. Also with the prototypes we made in the workshop, we had a common language with which we can talk about features and user flows. You would be surprised at how designers and web developers can describe and think of the same action in completely different ways. Prototypes can help bridge disciplines.

As I briefly mentioned in my last post, I created prototypes to evaluate each framework to learn what we were getting into. Two questions I wanted to answer were: “How easy it is use to this framework?” and “Does this framework have everything we need to build the dashboard?” I figured the best way to answer these questions was to use the frameworks to build the same web app and then to compare and contrast.

My approach to creating a prototype was to pick a critical user interface element and to quickly build it out. As I mentioned previously, I picked the chat window.

My goal was to quickly build it out; which meant that I can disregard best practices and settle for an ugly design. A prototype is not meant to be released publicly since the feature being prototyped could be immature or the code could be buggy. It is for demonstration purposes, for “drafting” a feature or for testing an idea. If the chat window was usable, it was a working prototype.

By making a prototype I learned that if we picked Backbone.js, we would have more code to maintain because unlike Angular, Backbone.js is a minimal framework that doesn’t have as many features that Angular has.

After we chose our code framework, I built another prototype, this time using our chosen framework, Angular. In addition to implementing the chat window, I also prototyped the queue and the “research pane,” where hosts could tag conversations with related art objects.

While visual designs could give us an idea of the look and feel of the dashboard, a working prototype could gives us an idea on how what it would be like to use the dashboard. Visual designs are static while prototypes are interactive; interface elements like buttons and text dialogs are clickable.

A side benefit of making prototypes is that they can serve as documentation that could help us plan and communicate how the dashboard worked. For example, Brian and I were discussing an animation that occurs when a user selects a name. After a user selects a name, a confirmation dialog should pop-up with an animation. I wasn’t too sure what direction he wanted to go in, so I quickly coded a few examples.

Another example is when we were designing the snippet creation flow. Brian had designed the following user experience: The user is presented with a conversation and they are able to select individual messages to create a snippet of that conversation. I wanted to confirm that Brian and I were on the same page in terms where the user was able to click and what would happen after the user clicked a message. You can view this prototype here: http://codepen.io/amycheng/full/cLIBw/.

Visual designs and code prototypes were being created concurrently, which led to one influencing the other. This also prevented designs and code prototypes from going too far in the wrong direction. Working this way helped us answer questions like: Does this user flow make sense? Is the screen too busy? Is this functionality too complicated?

At one point in the project, Brian was in the process of finalizing designs for the activity tab and I was in the middle of building a quick prototype of the activity tab. We discovered that the activity tab, which could potentially contain the conversation queue, a conversation window, and a research pane with any number of related art objects, could look cluttered on narrower computer monitors (Brian was designing on a much wider computer screen than mine). This discovery allowed us to come up with strategies to mitigate the differences between screen sizes.

It was a good idea to create prototypes because it helped us to clarify our thinking about the user experience and code architecture.