Process & Method

An adaptation from the speech I gave at Phoenix Design Week’s Pecha Kucha talks.

I am a UI/UX Designer & Frontend Developer at Synapse Studios. We develop single-page javascript applications for startups, enterprises & government/educational institutions. We build software that our users are going to spend a lot of time using so getting the interface right is extremely important.

I am going to go through the process I employ when designing and building software and afterward I’m going to speak on how I stay motivated & inspired on a more global scope.

Before I get into my process though, I thought it was important that you view it in the context of Atomic Design Methodology. Atomic Design is a way of creating reusable components for the web.

There are five stages of Atomic Design; beginning with the simplest, Atoms. Atoms can include fonts, inputs, buttons, labels and colors.

The second stage, molecules, are groups of atoms that function as a single unit when combined.

This pattern encourages reusable design components.

Third, we have organisms. Organisms are distinct and complex sections of the interface such as a navigation panel, header or footer.

Templates are comprised mostly of organisms to create page level objects.

Finally, pages are specific instances of templates that hold actual data and real content.

In that light, I begin each project by researching and using similar products to discover how they solved problems that I expect to encounter as well.

I also define my applications users and their expectations.

I use this gathered data to begin making design language decisions such as tone and voice.

After research, I begin sketching. I only sketch the more complicated components of the interface and I skip well known UI patterns.

This allows me to simplify complex ideas, iterate quickly on them and get things out of my head and onto paper.

Using what I’ve gained from research and sketching, I can start wire framing the app with support for the design decisions I make.

My wireframes are typically very low fidelity and serve to solve workflow problems more than design problems.

I spend the most time prior to code in the mockup stage. In this stage, I finalize design direction and make high fidelity comps in an app called Sketch (http://www.sketchapp.com).

I also begin to consider how everything will interact.

Which leads me to prototyping.

Ultimately, I would like to use prototypes in production code but until it is more feasible, I use an another app called InVision (http://invisionapp.com).

With InVision I am able to link static comps together and even animate them to mimic the behavior of live code.

From all of this I am able to move to code with an excellent understanding of what the app will look like and how users will interact with it.

I employ Atomic Design Methodology and start by building the smallest pieces(atoms) and adding them to a live pattern library so I can pull from them as needed.

Using elements from the pattern library, I start assembling organisms, templates and pages.

Wash, rinse, repeat until I am finally able to see the entire design system come together and function.

I am going to switch gears now and go over the things that keep me striving to become a better designer and keep me loving the work I do.

At the top of that list, for me, is the importance of a solidified, yet flexible, process.

What we, as designers, do isn’t magic and we shouldn’t treat it as such.

I expect and plan for client intervention.

Sometimes clients will do simply asinine things in a deliberate attempt to crush your spirit.

The willingness to meet these expectations is the best way to avoid exile on Disappointment Island.

I make myself uncomfortable.

I will try out a new plugin, library, framework, build process or technique or even revisit those I’ve already given up on.

For me this is where discovery happens.

I read… a lot.

You won’t find me reading a novel from cover to cover. I’m not talking about that kind of reading.

I’m talking about industry related publications, blogs, doc and even tweets. There are many people far more knowledgeable than me and I can learn so much from them.

I work on passion projects.

…even if I have no intention of ever finishing them.

I make Codepens (http://codepen.io/canfie1d/) to make proof of concepts just to see if it can be done and I contribute to discussions and help others with questions they may have. This increases understanding for them and me.

I work on Saturdays.

I only work three or four hours but it is the most productive time I spend all week.

There are zero distractions and it allows me to get an early jump on Monday which makes for an easy start to the week.

I suck at things. …but I don’t intend to continue to suck at them.

Attempting something that I think or know I can’t do keeps me humble.

…but I don’t intend to continue to suck at them.

Attempting something that I think or know I can’t do keeps me humble.

I ask a shit load of questions.

I find that people are eager to share their knowledge but are often just waiting to be asked.

Adding a variety of other peoples’ knowledge of a certain topic to my bank of knowledge allows me to have a more diverse understanding of that topic.

I borrow from established patterns.

Most of the time problems I come across while designing have already been solved by other designers. This is not to say that their use case is/was the same as mine and when I do borrow, I adapt it to fit my particular need.

Finally, and perhaps most importantly, I reject complacency.

The number one most important thing to me is that I am creating inspired work. I work with and for people who inspire me and I use a combination of everything I’ve mentioned to become a better designer and I rely on others to push me to that next level as well.