Hi, I’m Chris Kark, a product designer based in Denver. Trained originally as a teacher and researcher, I’ve worked in a variety of design and content strategy roles for nearly a decade.
Prior to becoming a designer, I taught Spanish language and literature. What, pray tell, do these have in common? A lot, it turns out. Learning another language entails much more than memorizing verb endings; it involves exploring and, little by little, thinking from another vantage point. It commands an understanding other ways of seeing the world without accepting them as your own.
The intellectual empathy required to master a language is also at work in human-centered design, alive in reconstructing the user’s worldview to solve a concrete problem. Design, for me, is like speaking a universal language, one that, when practiced carefully, everyone understands with ease.
Product design isn’t a process with a definitive beginning and end. It doesn’t begin with wireframes and end with handoff; it’s a discipline that touches every part of an organization. It sits at the confluence of business goals, user needs, and technical capabilities, each of which depends on a host of other factors that impact design—budgets and sales targets, customer support metrics and the allocation of development hours.
Paramount among these factors is the working relationship with product managers and software engineers. By tradition, designers sit midway between product and development, their core responsibility to translate user needs into flows and components that engineers bring to life. Yet practice belies theory: designers often get involved in drawing up product specs and dabbling in code to communicate with developers. I believe that the better you understand product management and software engineering, the better your designs will be.
My design process emerges from the interplay of these relationships and dependencies.
When setting out to design a new product or revamp a current one, I first gain an understanding of the problem by conducting a series of interviews not only with end users, but with those who serve them—sales representatives and account executives, product managers and customer support agents. Whenever applicable, I look into industry-wide trends. Like pixels, each perspective sharpens my understanding of the problem into something approximating the real thing. The more varied and numerous they are, the better.
By themselves, data aren’t that useful. What you do with them is. Thus when thinking through how to tackle a particular design problem, I quest in search of ideas and inspiration—how other designers have tackled similar problems. Nowadays, users expect websites and apps to use common user interface patterns: wizards for processes, massive CTAs on landing pages, carousels for testimonials, and fixed navbars for ease of navigation. But what happens when you need to compact a lot of functionality into a small amount of space? Will a nested dropdown do the trick? Are checkboxes superior to a multi-select menu? Or would it be better to advocate for more space? Like reading masterworks of literature, contemplating the best designs can offer insights into how to bring simplicity to complex problems.
This is the stage during which I devise and discard solutions. I chart user flows and sketch screens, workshop ideas with product managers and developers, and double-check that they meet user needs and product requirements. What begins as a series of disparate notes and back-of-the-napkin scrawlings slowly coheres into wireframes and design documentation. It’s not pretty, but the transition from divergent to convergent thinking never is. Once pieced into the design equivalent of a first draft, I review the idea with as many stakeholders as possible. Their feedback and the extra time to mull things over whittles the idea into a workable solution.
It’s at this point that I either assemble components from a current design system or create one from scratch. Principles of hierarchy, typography, and color all come into play, as do concerns about states and interaction patterns. Unless I’m building an elaborate click prototype, I try not to design every screen for every scenario; instead, I supplement mockups with extensive documentation that appears in the technical specs. Doing so drastically reduces ambiguity and the time to handoff. Sometimes, to illustrate an interaction or animation, I code prototypes myself.
Handing designs off to developers kicks off another chapter in the design process. Devs often have questions about how to handle edge cases or potential contradictions that the designer could never have envisioned. Most of the time this results in clarifying or adding to parts of the design documentation, but once in a while calls for changes to the designs themselves. While sometimes frustrating, a thoroughgoing review of the designs and accompanying documentation can prevent rework. It’s worth the time.
Designs are only valuable if they work. Before testing them with users, a matter of course, I perform acceptance testing and extensive CSS audits. It’s here that all of the gaps and unvoiced assumptions in my designs manifest. You see what you missed and what needs clarification. If you’re lucky, you also see what’s working as intended. After a few rounds of testing and revision, I test the prototype (usually, the app in a dev environment) with a group of five to eight users. To each tester I assign a few tasks based on a common user flow. Two or three testing sessions reveal quite a few insights and most, if not all of the major bugs in the first version of the app. Though I prefer to test and revise as many times as needed before introducing a functional MVP to market, some of the best feedback comes from real users relayed by the support agents and account managers.