By Aaron Gustafson CHAPTER 7It’s especially helpful when the different members of that team have
different spheres of expertise. A product manager, content strategist, UX
designer, visual designer, front-end engineer, and back-end developer all
bring different, but valuable ideas to the table.
Not only will each person be able to shed light on the positive or nega-
tive effects each decision may have on his or her primary area of concern,
but each will likely empathize with our users in a slightly different way.
In my office, UI construction flows are generally the low fidelity first
pass we use for organizing our thoughts and making sense of the different
interaction paradigms. From there, we move into rough sketches.
Our team tends to sketch on paper or whiteboards, but you may be
more comfortable in OmniGraffle, Photoshop, Illustrator, or any of the
many wireframing and prototyping tools out there.
Use whatever makes you comfortable and efficient, but be conscious to
not get bogged down in details. Sketches are a low-risk way to flesh out the
experiences in a UI construction flow.
Next, we begin prototyping in HTML, CSS and JavaScript, referenc-
ing the low fidelity spec we assembled in the UI construction flow and
our sketches. On occasion, we will stub out some back-end functionality
if we need to reference an API or something, but often we fake that with
static JSON files.
We use the prototype to see if the ideas we came up with actually
make sense and operate as we’d expect. If something falls apart in a cer-
tain context or doesn’t work in a certain form factor, we regroup and try
something else.
We iterate on the prototype until we are generally happy with the dif-
ferent behaviors and then we begin to flesh out the design, tune the code
for performance, and hook it into back-end functionality as necessary.
The result is a living, breathing adaptive component that can be added
to the pattern library and dropped into whatever context we need.