Design and development processes are something we really don’t appreciate early in our careers.
I was once a pretty typical student. Working on anything, be it a website, poster, visual system, I would dive into my project head-first. I would lay it out in Illustrator, InDesign, Photoshop or move directly into code. While the customer or whoever was in the loop, little up-front research would take place. My main goal was to “create cool shit.” This “ready, fire, aim” approach often yielded results that didn’t measure up or missed the mark completely.
The Winchester House
As an example of the perils of not having a plan or process based on empirical information, I sometimes tell my students about the “Winchester Mystery House” in San Jose, California. If you’ve ever visited San Jose, you may have heard this story.
Marriage and tragedy
So…in the 1860s, Miss Sarah Lockwood Pardee married Mr. William Wirt Winchester, the heir to the Winchester Repeating Arms Company fortune. The Winchester Repeating Arms Company was based in New Haven, Connecticut and produced the Winchester Rifle. The Winchester Rifle is one of two firearms that claims the title: “The Gun that Won the West.” Suffice to say, they were very wealthy. However, tragedy struck their family not once, but twice as they lost a child and later Mr. Winchester from illnesses.
Moving and building
Mrs. Winchester was understandably distraught by this and had become highly depressed and eccentric. She had come to believe that her family was cursed and haunted by all the people who had been killed by their famous rifle. Further (and no, I am not making this up), she also believed that the only way to temporarily appease these spirits was to move out west and build a house whose construction was to never end.
So that is what she did. She took her tremendous financial resources and moved to California and began to build….and build….and build. She hired contractors to work day and night…for years. You can imagine how big this estate became.
Sometimes it feels enticing to just jump into a project and start design or development. I see this a lot in my own undergraduate students. Despite the fact that we lay a basic design process right out in front of them, they are reluctant to follow those steps or even improvise one for themselves.
Worse, when we base our ideas on something other than objective reality (research, facts, etc.) we may end up with a giant, proverbial seven-story house that defies common sense. I have seen projects with large, moneyed customers and vague requirements drag out for years and waste money with no real usable results. It’s not pretty.
Trial by fire
My own awakening to the beauty of a process took place during my first year of graduate school. I took a course called “Design Methodologies.” This course centered on a series of exercises that made us take a critical look at the way we thought and worked. Suffice to say; when you’re presented with a series of visual problems to solve against a two-hour window, you’ll quickly discover what works and what doesn’t. Half the battle was discarding years of bad habits and embracing a process. The other half has been ongoing…discovering what works, what doesn’t, and refining.
OK…so…where are we going with this?
My intent is to share my own process, briefly here and with more detail in later posts. I come from a background that combines user experience, visual design, and code so my own process covers a large swath of the research, design, and development of a digital product. While my process is linear, I’m not writing this to debate the finer points of other development methodologies or frameworks (waterfall vs agile). This is simply what works for me. It’s pretty standard and you may do something similar or completely different. You may be new to the game and may not. Who knows.
Each phase builds upon the last.
Phase 1: Rescovery – Requirements and Discovery
Famous last words: “Easy enough, right?” In this phase, we do a few things. First, we define the problem(s) we’re going to solve. This goes beyond what is often at first the superficial. Imagine whenever someone has said they want to “make our site look modern” or “fresh” or “pop” or the nebulous: to “spread awareness.” Take a deep breath and slowly back away. Those reasons are mostly silly ones.
“Why” is the real question. “Why” drives us to ask:
What problem are we trying to solve? Are we trying to increase site traffic or sales?
Who is our audience?
What motivates them?
What tasks do they need to perform?
Who is the competition and what are they doing that works or doesn’t?
What technical, content, or usability requirements exist? These requirements can be dictated by the overall goals, the environment(s) our product will exist in, or target user.
This is also the time to review any pre-existing metrics and brand assets/strategy. In my experience, few customers have metrics or analytics. Sometimes you luck out though.
Phase 2: IA: Information Architecture
As much as it’s a cliché, content is indeed king. With our target audience and requirements in mind, we first gather and then refine content. We must also take care to outline not just the needed content, but also the overarching information structure of the site. How is this hierarchy laid out? How does the user move from area to area? Once we’ve got a high-level view of the information structure planned out, we can move into creating a page-by-page view in the form of wireframes.
Phase 3: Visual Design
During Visual Design we take the plans and scaffolding we created in the previous phase and build visual assets as well “skin” the layouts. Careful attention is taken to make sure that our design aligns with any preexisting branding and identity elements.
Previously, a lot of this was done in Adobe Photoshop or Illustrator, but it’s now not uncommon to create a functional prototype in software like Adobe XD, Axure, or one of the bazillion pieces of “cloud prototyping software” out there. User testing should also be performed against members of the target users defined in the first phase. Design, review, refine.
Phase 4: Development
This the build-out phase. Development is performed in an environment that mimics the production environment (i.e. what platforms/browsers/etc. the final product will exist on). The site is created using whatever tools or frameworks needed.
Customers are kept in the loop while iterative development occurs. The digital product is tested in whatever environments were decided during the first phase. This is where establishing clear requirements up front pays off…we know which browsers to test in, or which edge-cases will be most relevant to our users.
Phase 5: Deployment
Upon customer acceptance, the site is moved from development onto a live environment.
What happens next?
Beyond the main five stages, it’s essential to keep our eyes on our work in the wild. Any in-scope changes or maintenance can occur afterward. Even further out we may conduct a post-mortum and see how our results performed against our desired goals and metrics. The beauty is that if we succeed, we have a clear process and results that are likely repeatable.
That’s my story and I’m sticking to it. More to come on each phase in future posts.
// About the Author
Jason Occhipinti is a designer and developer from Upstate New York. He's an MFA graduate of Savannah College of Art and Design (SCAD), and when he's not running Positive Space LLC, he's teaching communication and interactive design at PrattMWP and Lindsey Wilson College. He also sometimes likes to talk in the third person.