A Bit About Process

Design Process Lite.png

What I do and how I do it

I work to understand the problem in front of me, then identify a path towards a solution using some combination of tools and process I’ve learned over the years.

First step is to get context. In order to prevent a product (or suite of products) from becoming simply a collection of features I need to understand the overarching strategic goals: what is the overall vision and what will differentiate our offering? Then, by employing straightforward HCI rigor with sound design principles we can collaborate as a team to build and release something in service of this vision that’s of value to both users AND the business (“feasible viable desirable.”). I’ve outlined the phases of this process below.

Insight: Discover & Define

You need to understand a problem in order to design a solution. So it’s important to first answer the who, what, where, when, and why before addressing the how.

The initial phase involves listening and observing in order to understand business goals and learn about stakeholders, users, the brand, and the state of any existing products.

Activities

  • Stakeholder interviews 

  • User interviews

  • Market and usability research 

  • Competitive analyses 

  • Content inventory and audits 

  • Card sorting and affinity mapping

Using my findings from this Discovery phase I’m able to sum up users’ goals, aspirations & needs, motivations, and frustrations, and from there develop experiences that help further define the original problem.

Artifacts

  • Initial user stories

  • Personas

  • User journeys

  • Mental models

  • Red route identification.

As this phase winds up the entire team will have a better grasp on who the target audience is and be able to focus on their needs. And goals and success criteria will be defined allowing us to begin solving the right problems.

Creation: Ideate & Prototype

With goals now defined I develop an informed point of view (“lean hypothesis”) and start working collaboratively towards a solution. The objective is to develop and visually communicate abstract concepts to generate feedback, with the intention of uncovering usability issues and validating design decisions. This iterative phase is driven by the design team and includes all stakeholders’ input. 

Activities

  • Structured brainstorming sessions with stakeholders

  • Iterative sketching (whiteboard, pen & paper, etc.)

  • Evaluative testing and re-testing

  • Technical review and consultation

Artifacts

  • Low fidelity initial mockups

  • User Flows

  • Sitemap

  • Wireframes

  • Page descriptions with user stories

  • Interaction prototypes: rapid (pen & paper) to medium fidelity

  • Polished, engaging documentation for internal stakeholders

Execution: Refine, Implement, & Monitor

At this point in the process many of the UX design issues have been identified and solutions have been proposed and tested. The next step to determine what will be built — from the specific approach to the MVP version of that approach — and then begin handing off assets to the engineering team. This is not a cold waterfall-style handoff as all disciplines will have been involved from the start and will continue to be involved going forward. As a designer I shift to more of a support role during execution, providing documentation, clarifying intent, and addressing any necessary minor design changes. There is also considerable visual design work done on the UI refining wireframes into high fidelity comps and design specs..

After the design has been built, approved, and released I work with product owners to review metrics and evaluate how the design is performing. If something points to a flaw or an opportunity to improve, the design process repeats.

Activities

  • Solution approach selection

  • MVP review

  • UI microcopy (coordination)

  • Design team review

  • Demos for the working team

  • User feedback

  • Metrics analysis and design validation

Artifacts

  • Lean reference design 

  • High fidelity mockups (if necessary)

  • High fidelity prototypes (if necessary)

  • Redline specifications (if necessary)

  • UI Toolkit and/or Style Guide

  • Art assets (e.g.- icons)

Conclusion

This is by no means an exhaustive accounting but rather examples of processes I have personally directed or participated in and found work well. (All imagery above was authored by me.)

I work in many of the typical designer software tools including Sketch, InVision, the Adobe CC suite, Omnigraffle, Gimp, Keynote, etc., plus an ever-evolving list of productivity platforms common in most technology studios today: Slack, Jira, Confluence, Trello, Github, YouTrack, etc. I learn and use whatever tool makes sense for the job at hand with a bias towards software that bridges the gap between Design and Engineering (e.g.- Sketch preferred over Photoshop) and software that is more commonly used by non-designers (e.g.- Omnigraffle preferred over Illustrator). Basically, I feel it is essential for me to have broad & shallow experience in a lot of tools, and then commit to learning certain software when it becomes productive.