Crate Design Process
Applying a design process that I've built upon over the last nearly twenty years as a UI designer.

By the time I joined Nike, and began working on Crate, I had been a designer on two different UX teams and multiple long term projects. Over that time, I developed a design process that I felt allowed me to iterate quickly and limit the amount of churn that typically happens on the design side when working on big projects. What I will be describing below is typically where I start after all the initial UX work has been done and requirements, KPIs, etc. have been established.

User Flow Diagrams

There are many types of flow diagrams out there, but the trick is finding the appropriate form and content for the problem you are trying to solve. In most cases, I find that framing the flow in terms of a user journey through the feature is the most helpful when the audience is more on the business side. I will sometimes create a more technical flow diagram that shows where and how the feature touches different parts of the overall system when needing to get sign off from a technical team. In either case, these are extremely helpful to do before any design work has started because it helps reveal the true scope of the work required to design and implement the feature. When working with development teams, this step has helped break the work into phases, instead of getting too far down the development track and realizing, too late, that you've underestimated the scope of work needed.

Axure UI Library

Over the years I have made fewer and fewer sketches or wireframes, instead using a took like Axure to create nearly finished UI in the same amount of time it takes to whip up a quick wireframe. For Crate, I had developed the style guide in Axure which allowed me to take the individual UI elements and turn them into a library of UI widgets that I could drag on to the page when "wireframing" a feature. This helped immensely on two fronts. First, my stakeholders were very visual people who just couldn't respond to sketches or wireframes the same way they could something that looked like finished UI. Secondly, it is extremely time consuming and error prone to recreate the wheel, or grab from an existing file, every time I needed to mock up the same UI elements. With Axure's widget library I was able to have one source of truth for UI elements that I could use to quickly produce mockups with final looking UI that my stakeholders could respond to. This was also quite helpful for the front end developers doing the implementation because they could envision the final product much earlier in the design process.


Another effective tool for demonstrating how users would move through the UI, and how the UI would respond, is the prototype. Axure is a very powerful tool when it comes to prototyping user journeys and UI behaviors. Typically, if UI behavior patterns have already been established, I won't create a prototype. When I am designing a feature that requires new UI behavior, being able to prototype it helps to get stakeholder approval as well as bridging any gaps with the development teams in how the UI should behave.

UI Specification

Once a feature has been approved by all of the stakeholders, I create UI specification that, in conjunction with the style guide, helps the development team implement the feature correctly. The specifications are also used by QA engineers to validate that the feature was implemented according to specs.