My Process

May 9/2019 · Presentation · Thoughts

“What’s your process?” Is a question I get asked a bunch.

Process for design work is difficult to show with a screenshot of the “final” product. Not unlike math homework, people want to see your work. They want to know how you got from “I have this problem!” to “Here’s your solution.”

My answer starts with “It depends…”

There’s a metric ton of possible variables in any given project’s equation that affect your approach, making each project unique. Think about roguelike video games, you’re doing a lot of the same stuff, but it’s always a little different.

Generally speaking

Every project I take is processed through my patent-pending organic methodology of Communication, Empathy, and Curiosity. These three concepts form the foundation of my practice, and guide everything I do when approaching design problems tiny, or super-massive.

Communication is a designer’s bread and butter. You need to be able to know the right questions, and understand how to properly deconstruct the answers. As a designer you need to be able to articulate and present your proposals in a way your customer can understand and participate in. You must understand that communication is a through-line for the entire project.

Empathy. We’ve all heard that a designer needs a thick skin. I disagree. Empathy is a skill that a designer should practice daily. You need to understand your client’s audience, and the best way is to walk in their shoes. The more you understand your customer, the better you’ll understand their problems.

Curiosity is a key trait for a good designer. Exploring options, proposals and solutions is a great way to hone your craft and intuition. Don’t settle for your first idea. Dig deeper, purposefully explore options that seem obviously bad, work through the muck, and you’ll find gold!

Employing these skills/traits through-out my process, and understanding it’s not a series of linear steps, but a three-celled organism that is constantly shifting and changing as the project goes on puts me ahead of the game every time.

More precisely

My approach varies depending on the context of the project, team, and resources available to me.

Deliverables range from sketches on graph paper or Post-its™, to fully rendered wireframes and user-flow diagrams.

If I’m working on a project and I’m both the UX and the UI designer, I’ll get by with graph paper and rough pencil sketches to guide my design work, in addition to any research available like user interviews, personas, and journeys.

Various UX sketches

If I’m working within a team, and I’m not filling multiple roles I will produce more polished and legible documentation. These are especially handy when you need to communicate your proposals, and/or the implementation details to other people, who aren’t you.

A presentable wireframe
A presentable user flow

I employ a design system, style guide, design unit testing, and the nine states paradigm.

Design systems are great, they put everyone on the same page. A well documented design system paired with a thorough style guide can speed the development of your projects ten-fold.

Unit testing allows me to identify and fix problems with a specific UI component early on, prior to it making it’s way into the project.

A style guide

Nine States is particularly useful because it puts you in a constant state of thinking about all the ways a specific component of the UI may appear within different contexts. This helps greatly when it comes down to implementation. Everything is mapped out and ready to go. Level up; This way of thinking trains you to pay closer attention to the small details.

Nine States, visualized

What about tools?

If the work is getting done, and everyone that needs to can access that work, it doesn’t make any difference how it was created or what tool it was created in.

That’s not to say I don’t have preferences, or that I’m opposed to using a tool of choice in the context of a specific role. I do, and I’m not.

Bottom line, whether you choose to use Sketch, Figma, Framer, Illustrator, or another tool-du-jour, as long as everyone on the team is working in the same ecosystem and understands how to collaborate within that system the tool choice itself is unimportant.

My preference depends on the project and what needs to be made.

tl;dr

Every project, company, and client is different and you have to be adaptable with your skills and tools so that you can approach each task with knowledge and patience.

Be water my friend.

Bruce Lee 1971
Photo of James Mathias

James Mathias is a father of four, husband of one. Internet improver, board gamer, fitness amateur, yoyo player, artist, writer + outlaw. → More

hire James 615 249 8113 Dribbble GitHub