My Process

Well...it depends.

Context is everything, and one of the strengths I pride myself in is my ability to adapt quickly and effectively to whatever constraints come associated with a design problem: “We’re down a developer”; “Can you have me something to show in my presentation by Tuesday?”; “It has to work in IE7”; etc. etc. Given the plethora of techniques at our disposal as UX professionals – journey maps, personas, competitor analyses, and on and on – the specific parts of my toolkit I choose to employ vary from project to project.

That said, there are a predictable set of key steps I [strive to] progress through in reaching the final deliverable, and as a case study I’ll lay those out as they map to my recent work on Kubernetes Dashboard. Because I’ve seen enough buzzword-y descriptions of the UX design process (typically liberally gradiented & drop-shadowed), I’ll try here to avoid the predictable bits and instead underscore what makes the Dan Romlein Version® the Dan Romlein Version®:

Step 1: Define

Why. Why do we want a UI for users to interact with Kubernetes when they have the command line? Why are we building a product for non-traditional students? Why do you want a ‘more contemporary’ website? For me, it all starts with why; it’s my favorite thing to ask in the whole world. What drew me from branding, graphic, and web design to UX was it let me push on the process – it holds up to critical analysis. At the bottom of that winding series of "whys" is a bedrock of support for the decisions that will then follow. It feels authentic to me, and authenticity is one of my core values, both in my work and in my personal life. 

This phase establishes the success metrics of the projects. What are we trying to accomplish? As Zig Ziglar put it, “If you aim at nothing, you will hit it every time.” Figuring out stakeholders’ goals and the business strategy enables my ability to drive things toward those. I do my best to ensure all these objectives are rooted in user-centered thinking. Throughout the project, a high standard of empathy for users serves as a benchmark to assess progress against.  

Notes around these initial steps all go into Google Drive. First thing I do when I have a new project is crack open a new doc (shift+T, for those not already power-using, *ahem*), and start jotting down key relevant info: contacts, links to existing artifacts (e.g. Github issues), timelines, etc. This doc then serves as my enduring project management nexus; I know that’s where I start anytime I’m working on a given project and can trust that any relevant threads will be pulled together there for me to reference. 

Step 2: Research

Once step 1 lays out some strategy, I let my insatiable curiosity run wild in learning about the end users. On Kubernetes Dashboard, for example, the people I’m working with to build the thing conveniently are the end users. Learning about their problems, concerns, and motivations can be as easy as creating a Github issue and dialoguing there with the community.

Shown here, to get a bit meta, is me creating an issue to discuss Kubernetes Dashboard user types with Kubernetes Dashboard users. In this example developers are very familiar with the needs of the target user, however as a designer I am not. This means that other than the most basic of best practices, (“No, Trajan is probably not the best selection for this audience”), I am completely reliant on user research to guide my decisions. I like this about the very complex problems found in the enterprise UX space: I’m not even tempted to “fool” myself into thinking I fully understand what an IT operations specialist at Fortune 500 company needs to accomplish. Instead, I’m forced to go through the process of talking with them, reading about them, and creating an evaluable persona.

Adequate user research engenders in me empathy which in turn serves as motivation for the work to come. Empathy gets talked about as it relates to design a lot, but it took me a while to understand that it’s not just some abstract ideal to check off a list: I actually need to feel for the people for whom I’m designing. When I’m asking “why”, it’s transforming me from a pixel pusher who merely gives things some “polish” (a role to which designers are too often relegated), to a craftsman with intimate knowledge of the problems to be solved. If I can’t put myself in the shoes of the end user for a given feature of something I’m working on, that’s an indicator it’s time to go talk to some more of the intended audience.

Step 3: Ideate

Now that I’ve had sufficient input, I can begin to output in earnest. Time to get “creative”, as it were. A misunderstanding I sometimes encounter of what a designer’s role comprises is that we’re primarily artsy fartsy types who spout a steady stream of dazzling visual ideas. That view fails to tell the whole story: before I can craft an effective solution, I need to progress through the aforementioned steps so I have building blocks with which to be creative. I like to document these prerequisites in a brief of some kind: somebody else can make it; I can make it; it can be long, short; it can evolve; it can be called something other than a “brief”...the important thing is that there’s some mutually agreed upon (by stakeholders) spec to base designs upon.

Though I dislike the formality it connotes, in Dashboard our process includes writing a Product Requirement Document (PRD).

Ideating with others is more powerful than by myself, so the more collaboration I can drive, the better. I’ll prod and coax engineers to make an attempt at some level of visualization – whiteboard, napkin, whatever. I find getting those ideas externalized is a vastly superior method to relying exclusively on words to communicate, and the simple act of putting something loosely on paper frees up cognitive space to then generate new ideas. Regardless of what method someone’s most comfortable working in, I’ll approach the process on their terms. This is where earlier investments in building trust and relationships pay off big time. Leah Buley says that the #1 secret to being a successful “User Experience Team of One”  is to “truly listen”, and I think that applies regardless of the size of your team.

This stage is typically where eureka-level ideas bubble up, so I try to create space for that serendipity to happen. You know: long introspective walks on the beach, or getting out of the shower to write something down in a Moleskine. Abductive thinking

A lot of ideas – good and bad – get generated by this “What if...” thinking though, which necessitates the next phase:

Step 4: Refine

Brainstorming ideation in the previous step is a time to be playful and even silly. In refinement I become a bit more serious and start to  reign-in the myriad of options hatched by abductive thinking. Design thinking opens up a broad spectrum of possibilities; critical thinking narrows it down. I have a bit of a left- as well as right-brained disposition, so I love that in UXD I get to flex both of those.

At all of these stages, if you’ll recall back to the most recent gradiented & drop-shadowed UX process diagram you saw, there are cyclical arrows back to earlier steps; i.e. revisiting the why question and checking in with stakeholders to make sure things are still on track. That happens here, and as fidelity increases through information architecture and wireframing, guiding that progression are the high-level principles established early on.

Step 5: Prototype

Say it with me: “Ehm-Vee-Pee.”

I subscribe to Lean UX’s philosophy of striving for a Minimum Viable Product as a means of assessing the value of a given effort’s direction. If users aren’t getting it, better to learn that sooner rather than later. To that end, it’s time to take those rectangles of various fidelity that we have digitized and start cobbing those puppies together to be interactive! InVision personally was a game-changer for this when it came on the scene, and I’m still a fan.

Oh yeah: and what most people think of as “design” happens in here somewhere, viz. making things like buttons and dropdowns in the design tool du jour.

Because it was a feature for an existing product, the RBAC Management case study I’ve been using already had an established design system (Material) to draw on, so we jumped from the wobbly grayscale lines of Balsamiq right up to near- pixel perfect mockups to then discuss and evaluate.

I try to make what I’m putting together in InVision as close in semblance to the final result as possible. The RBAC Management prototype comprised 19 screens, allowing usability testers to click through user flows and note troublesome points in the journey.

Iteration is one of those project aspects that varies widely by how much time is available. At each step of prototyping I’m soliciting feedback and revising artifacts accordingly. If everything goes as planned, each cycle of creation / feedback moves us closer toward satisfying the key performance indicators identified early in the project. For Dashboard design work, Slack is one of my first stops for sending out prototypes for feedback. Kubernetes is one of the most active open source projects on the planet, so getting free, qualified, testers isn’t usually an issue.

Step 6: Ship

All the previous steps culminate in shipping. Seth Godin points out in his talk “Quieting the Lizard Brain” that our job as makers is not to come up with lots of great ideas – that’s pretty easy; it’s instead to execute and ship those ideas. The most pristine comps in the whole world are worthless if they’re not done in time to be implemented for the next critical release. Though arguably I on occasion take my predilection to self-discipline too far in some areas of my life, it serves me well in having a track record as someone who ships.

As Google’s Principal Designer Nicholas Jitkoff wrote in the blog post announcing Material.io, “Design is never done,” and of course my work doesn’t end when I send my deliverables to the project’s developer(s). As long as I’m a part of the team responsible for the product, I’m continually reevaluating solutions and striving to improve our users’ experience. That means dipping back into any and all of the previous steps, questioning why decisions were made, and accepting a certain level of inherent ambiguity in creating products that solve complex problems.