Illustration by Connie Noble for this article.

Most problems don't have one single solution.

Most problems have many possible solutions. Our job as digital creators is to identify the trade-offs and constraints that will enable us to select the best possible solution for any given problem.

The job we have is not to identify the "one true solution," as there often isn't going to be one. Pursuing an imaginary "perfect" solution can lead to wasted time and effort. We must buck our instincts of pursuing perfection and instead seek to find a solution that is best for the specific occasion, audience, and contexts, in front of us, given the information we have available.

To design the best possible solution for any given problem is not to seek perfection in our work but to create in small, iterative steps that will uncover more information for improving the design over some time. Such a process is good design.

Yet, as a designer or digital creator, how often do you find yourself paralyzed with indecision? Afraid of selecting a lesser solution out of fear of how it might fail or wanting to impress those that rely on your expertise, you dilly-dally and procrastinate until the project clock starts to run low.

At some point, you have to decide on a design solution; you're just holding off until the decision point is "out of your control. At which point it's easier to say "I ran out of time!" than it is to say "I was afraid of making a poor decision."

Back when I was an individual contributor at a large, globally known tech company, I believed my role was to select the single, absolute, best solution to any given problem. I would spend inordinate amounts of time researching existing solutions, auditing competitors, or tackling menial tasks, all beneath the guise of productivity but really out of fear and anxiety. Working alongside some of the best minds in software design led me to believe my job was to be the best at my role too.

I procrastinated because I was afraid of making a bad judgment call, miss a crucial characteristic of our existing design system, or overlook an edge case that would break the entire solution.

As the time available to me to develop a design solution reached its maxima, I'd inevitably have to make a call and cross my fingers. In almost every single case I can recall, my fears turned real. I had overlooked a critical edge case. I did miss an existing component or design pattern used elsewhere in the product—something the team could have easily reused. I had slowed the entire initiate down out of fear I'd not come up with the ideal possible solution to the challenge at hand, only to do just that.

Over time I've learned there will always be something in the problem space we won't know about until the design gets out into the real world.

“It is not necessary to be perfect; we can make thousands of mistakes during our voyage. What is required is that we commit ourselves to a course and remain alert to the actualities of each moment, so we can guide our adjustments.”

Our job as creators isn't to design the perfect solution to the problem at hand, and trying to convince ourselves as much will only lead to more frustration and wasted time.

Instead, we should focus on putting in the work to understand the implications of our design solutions, knowing there will be things we miss, overlook, or fail to get right. As long as we are willing to progress toward some designed solution, we can learn where the design has fallen short once it's out and in the world. Then our job shifts to be adaptable and responsive.

Too many of us stress and procrastinate over trying to find "the one true solution" to a design problem, but the reality is we don't know what we don't know. The only way to learn is to pick the best solution you can with the information you have, then learn from getting it out into the world.

Pick a solution and learn from it.

Illustration by Martyna Wieliczko for this article.

How do you know what design's impact is on the product you're building? Even if you could measure design, how do you identify what parts of the product experience are worth measuring in the first place?

These are the types of questions digital designers inevitably end up asking themselves. They're also the types of questions business leaders look to design for clarity around. How do we know if our design team is doing the best, most impactful work for our customers? How do we measure the effectiveness of a design change on revenue? Where should the design organization be spending most of their focus?

It turns out there are many straightforward methods and strategies for measuring design impact. Two areas I recently combined while exploring the design impact at Gem—where we're building the source of truth for top-of-funnel recruiting—are top tasks and PURE (Pragmatic Usability Ratings by Experts). Here's how I did it.

Note there are many important ways of measuring product usability and design impact. This is just one small part of a larger effort and is in no way meant to be a complete, comprehensive way of measuring design impact.

1. Identify and map stages of user jobs

To start: I needed to understand the essential work our product seeks to solve for customers. My go-to for figuring out user needs related to workflows in a product is what's known as "top tasks."

The Nielsen Norman Group defines top tasks as "a list of 10 or fewer activities that users should be able to achieve using a design. If people can't do these things, the design has failed." Therefore, the first step for identifying top tasks is to outline all significant tasks. To do this, I started by outlining the various "jobs" our customers seek to accomplish. (Similar to Clayton Christensen's Jobs to Be Done framework.)

Identifying the main jobs customers use our product for was easier said than done. As someone new to the recruiting space, I had to leverage internal stakeholders and external resources like blog posts and conference talks to identify the primary "stages" of recruiting.

I learned that the recruiting process—or "lifecycle"—tends to have seven typical stages:

• Preparing
• Sourcing
• Screening
• Engaging
• Managing the interview process
• Hiring
• Onboarding

Once I had a grasp of the stages, I documented each step. I began listing out the various jobs and tasks within each, enlisting the help of external experts at the company to help audit and contribute to the list. I formatted the text document as follows:

Stage

Job within this stage

• Task for accomplishing the job
• Task 2 for accomplishing the job
• etc.

An example stage, job, and task breakdown within the document ended up looking something like this:

Stage 4: Engaging

Managing passive candidates

• Continue messaging candidates with strong resumes
• Set reminders for candidates that aren't actively looking right now
• Connect team members with passive candidates to schedule "coffee chats"

2. Survey internal experts on perceived job pain

Once I had a relatively comprehensive list of all the stages, jobs, and tasks a typical recruiting team faces, I then created a visual "map" in Figma of that same data.

Creating a graphic format of these stages, jobs, and tasks would be essential for helping internal and external stakeholders better visually parse and interpret the information. Quickly scanning and understanding each stage and task was critical for the next step of the process: surveying internal experts for their feedback and emotional rating of each job.

To do this next stage of the process, I selected groups of three to four internal experts at random to participate in a 30-minute workshop, with a total of 10 participants. The workshop format consists of two 15 minute sections.

The first 15 minutes: quiet, heads-down time to provide feedback on the visual map. Were there any stages, jobs, or tasks that felt out of place? Were there any tasks that were missing? Fixing typos, ensuring I was using industry language, and checking that generally, everything made sense were the goals of this time.

During the next 15 minutes, each participant to access a private, just-for-them, version of the map in Figma that was immutable except for a series of small circles with a question mark (?) in them that sat above each job. I asked participants to use the circles to select an emotional response for each job based on what they know or have experienced around it. Answers could fall into one of four emotion classifications.

• Exciting
• Satisfying
• Annoying
• Upsetting

Even if a participant wasn't an expert in the job they were evaluating, I asked them to each leave an emotional response regardless. The more raw data I had to use here, the better the outcome would be for identifying top tasks.

3. Survey customers on job pain

Once internal experts at Gem had given feedback and rated each stage's jobs on perceived emotion, I reached out to external customers for their ratings.

This step of the process took the sort of a Google Form. For each job I had identified, I created a question that the participating customer could rate. Because this meant customers would be evaluating more than 30 unique "jobs," I also offered customers the chance to win one of two $100 Amazon e-gift cards for their time. Offering an incentive to participants significantly increased participation and meant I could get a broad audience to participate in the research.

Once customer ratings were in, I filtered responses based on 1. Time the customer had worked in the recruiting space, and 2. Job role. Specific job roles (like hiring managers) weren't likely to have a broad swath of insights needed for the whole end-to-end recruiting process, so I removed those responses from the final tally. In comparison, users who were talent executives or full-cycle recruiters I prioritized.

4. Index all pain ratings

With internal expert ratings and external customer ratings available, I transferred each stage and job to a Google Sheet and put each emotional score near them. The breakdown was to pair emotional responses with a numeric value, with Exciting being the lowest (1) and Upsetting the highest (4).

The reason for this was I wanted to track the most "painful" parts of the recruiting process. Added to the Google Sheet, I was then able to quickly create an index of which details from the recruiting lifecycle customers and internal experts viewed as being the worst. I then added the totals for each column and row and calculated the average, aggregate, max, and min for each job and the entire index. From there, a simple set of color conditional formatting showed me where the most critical areas for our team to focus on were.

5. Identify task flows for the most painful jobs

At this point, the team had everything they'd need to evaluate task flows for the most painful jobs (the "top tasks" identified by most painful in the pain index).

I took a look at the most painful jobs—those with the highest scores in our index—then looked at the individual tasks within each job area. Those tasks became the most critical areas for our team to monitor and evaluate. The intention here is that if we can improve the efficiency and ease with which customers can accomplish these specific tasks, we'll be helping to design a product that improves customer's lives.

Here is where the team is today: we know the top tasks as identified through internal and external workshops and surveys, now we need to break down those tasks into individual steps users have to take to achieve them.

To break down and evaluate each step, the team looks at each set of tasks behind a job. These task steps become workflows that we break down into a Google sheet. The result looks something like this:

"1. Go to the Prospects tab. 2. Click to filter on rejected candidates. 3. Select a candidate who was recently rejected. 4. Click to send them feedback. 5. Enter a feedback message. 6. Send the feedback. 7. Confirm the feedback was sent successfully."

6. Conduct PURE against each task flow

In the final stage of measuring design's impact, we take these task workflows as identified for the most painful jobs our customers face and ask three internal experts to follow the workflow and rate every step on a scale of 1-3 (good to bad) for three variables:

• Ease of use
• Speed
• Efficiency

This type of testing is what's known as PURE: Pragmatic Usability Ratings by Experts. The "experts" are internal Gem employees who may or may not be experts on the product but are experts when it comes to an understanding our customers and their pains.

The ratings these internal experts provide are calibrated and added together for each job area. The job areas are then given a total score, with lower scores being better.

For example, we may end up with a usability score of 38 for the customer job of "Giving feedback to job candidates." Compared to a score of, say, 22 for a different job we identified, we can add these scores together to get a complete usability score of 60 for the product.

As the team focuses on improving the usability of these workflows within our product, we then re-evaluate all workflows, jobs, and usability scores every quarter. If the score lowers—say, it drops to 52—then we know our team's work on the design and usability side of things is having an impact.

These PURE ratings are not the end-all-be-all of the work we do as a design team, of course. We also track progress toward new feature goals, leveling up the foundations of the product holistically, looking at how we collaborate and communicate with other business units, and look at many different areas of ownership for our team.

Using top tasks and PURE analysis means our team can set some level of measurement for monitoring the usability of our design work. Having a set area and method for measuring the work we do, we can align efforts and how we think about the most important work we do. This process, in turn, ensures consistent design efforts toward a shared objective.

Illustration by Raul Gil for this article.

Nobody warned me how challenging being the Head of Design at an early-stage startup would be. Then again, nobody warned me how much I would love the challenge.

How did I get to this point?

The journey started for me over a year ago. I had spent a small part of my earlier career managing a team and after a number of years I found myself longing to get back to that. I wanted to feel again what it’s like to not only design products but also business groups, organizations, and the processes around each.

There is no more significant design task than getting a group of people to work together toward a shared objective, growing and evolving as they go.

Additionally, I found myself wanting to be in a position much closer to the core business of the work I was doing. I wanted to not only and continue to see design's impact on customers and products, but also get close to the metal and manage how the function of design impacts and influences a business's bottom line.

What is the bridge to head of design?

As a creator, I feared moving into management would mean missing out on time spent actually designing things.

For many designers, moving into management means exactly that: the end of making. Managers tend to miss out on being close to the craft and instead must dedicate their time to helping manage and lead the team. Meetings, managing calendars, presenting work and representing the team, negotiating with executives... I wasn't sure all of that was what I wanted to do with my time as I started exploring my next career move.

Then Nick Bushak, CTO and co-founder at Gem, reached out for coffee, and through conversation with him I had a revelation. As a Head of Design I could spend a good year or two in a player-coach position before having to decide which path I'd like to take more long-term.

Being Head of Design at an early stage startup often means building and managing a design team from the ground up while also doing the work expected of a very senior individual contributor. You have to do both because both are needed at the early stage and small size of a series b company. As the company grows, the need to balance both managing and designing subsides as new members join the team, eventually pushing the Head of Design into either a senior designer role or focusing on management as a Director of Design.

Moving into the role of Head of Design meant I would be tasked with identifying headcount, hiring, defining what the team's purpose is and how we’ll operate, what parts of the product development process design is responsible for, and creating a vision for how we would grow. It also meant I'd have ample opportunities to get my hands into the work because the design team would be small early on, but the work required of us would be plentiful. I'd be not only a coach for the team but a player too.

Of course, a Head of Anything in a startup faces obstacles and issues you don't get if you are only an individual contributor or a manager.

At the bridge between both manager and individual contributor roles, you face challenges at both ends.

If you’re acting as both manager and designer, how do you know when to focus on team building and processes as opposed to focusing on the craft itself? How do you show up to lead and manage the team when you're also spending a reasonable amount of time showing up as a designer too? Where do you draw the line at being a partner to your team and their manager? Possibly most important: how do you help others on the team (the design team and the leadership team) understand what to expect of you if you're constantly doing both leading and designing?

To answer these questions I did three things immediately upon joining the team at gem:

1. Set out to define what matters most to me as a leader
2. Sought to understand what matters to the company in a leader
3. Sat down for 30 minutes with every single person in the company to learn of their perspective on design, the most pressing needs as they saw it, and what they wish design would tackle first

As part of a Stanford class on leadership, I outlined my leadership values (what my team and peers can expect from me as someone guiding a function in the company) before starting the role. I then created an outline of how I see the design team role functioning, based on early conversations with other design leaders I had developed connections with over the past few years.

Alongside guidance from my manager, Nick, I was able to identify where I should spend my time and draw lines between the tasks ahead of me as a new Head of Design. (I also found this article from McKinsey to be very helpful.)

Each of these things helped set expectations around the role for both myself and the broader company.

Crossing means expanding and refining skills

Moving across the chasm between individual contributor (or IC) design and management meant facing many skills and problem areas I never had to think really, truly, deeply about before. Things like:

• How should a design team be structured? What roles does the team need inside the company to be most effective? What's the right time to bring in specialists vs. hiring for generalists?
• How do finance and talent teams play a part in the planning of a team? How do you negotiate the importance of a role on the team?
• How do you find and source high-quality design candidates to join the team this early in its formation? (Product plug here, because Gem is making this process a little easier!)
• What work is most pressing for design, and what work can wait? What will help the business achieve its immediate goals, and how will that work be prioritized against more long-term investments in user experience?

As a result of some of these questions, I started the job at Gem by focusing my time on two core areas:

1. Capitalizing on immediate design wins

Immediate wins for the company were easy enough to tackle as a former IC designer. I spent a few weeks up-front auditing the entire product, talking with every member of the company, and working directly with customers to understand what design work needed to be done right away. I asked: what could help demonstrate the value of design to the company while getting me familiar with the product, customers, and culture? Within a few weeks, I had shipped minor but readily apparent changes to the product and begun shaping processes around the role of design as a function.

2. Preparing design to scale and create business influence

Scaling a design team was a new space for me to work in. I never had to think about building and scaling a design team as an IC. As such, I relied on external resources and help from other design leaders in the industry to spotlight the skills I would either need to improve in or learn for the firs time. Amongst the skills I identified:

• Business strategy: How does our product solve real needs in the market, how are we growing our presence in the industry, what are our strengths and areas of opportunity as a business? How do we establish ourselves as leaders and convert that presence to dollars? What is design's responsibility for each of these things?
• Organization building: How do we get the most benefit from a team of people? How do we align business objectives with team structure and career planning for individuals? How do you hire designers for a rapidly growing company?
• Communication, negotiation and product strategy: Three skills not only belonging to managers, but skills I hadn't needed to become truly an expert in previously (as my peers in engineering, product management, and design leadership could fill in my gaps for me as an IC).

Most helpful for me during this time of identifying skill gaps was having a personal "board of directors" I could reach out to. Whenever I encountered a challenging situation or whenever I'm unclear about something as it relates to my role, having this close group of people I can seek guidance from has been rewarding.

Being in a Head role can be overwhelming and leave you feeling like you're on the verge of failing at any moment. There’s so much to be done and only one you. Having a small group of peers who have done the role successfully before can be all the support and inspiration you need to stay afloat.

First brought up for me during the DesignX State of Leadership panel. The idea is simple enough:

• Find people in the industry who have successfully done what you're doing now
• Build a close connection with them
• Regularly meet with them to glean insights from their experience

Surprisingly, not a single design leader I have reached out to over the past year has declined time to chat. Many of those conversations have grown into regularly recurring catch-up calls.

Without this personal board of directors, I'm not sure I could survive the dynamic world of a fast-paced startup, let alone the role of attempting to cross between management with designing at the same time.

What it means to grow a design practice

As many of the people the design team works with at Gem haven't worked with a product designer one-on-one before, I found it essential to live our company value of transparency and make the design process as straightforward and clear as possible to everyone in the company. This emphasis on working transparently is great because it aligns with my personal values as a creator and leader.

Early on at the company I started hosting weekly, hour long, Design Reviews on Fridays, inviting everyone in the company to attend and see a bit of my work process. The company at this stage was very interested in the topic, and I found upwards of 90% of the company would regularly attend these virtual meetings to see what this new “design” function was all about.

Over time as the design team has grown, I've pushed for us to continue this practice of transparency in other ways.

As a design team, we share work daily in Slack. We host Design Reviews each month for discussion with anyone in the company who wants to attend. We also host weekly Open Office Hours for anyone in the company to ask questions and work with us collaboratively—in real-time—on problems. These things have helped connect design to the business and demonstrate how our function does much more than just turn an ugly screen into something pretty.

Scaling the team and lessons learned thus far

One of the biggest focus areas in my role is thinking about how the design team will scale inside the company.

Kristin Skinner and Peter Merholz wrote a book on designing the design organization in a company, in which they outline a time-tested process for building and scaling a team.

The book, aptly titled Org Design for Design Orgs, is an excellent reference and helpful guide for any organizational leader who needs to understand how design might scale in their company. Though the book is a good reference, it's also relatively generic and requires deep thinking into what your specific company might need as it scales. For Gem, this meant looking at the company size, product-market fit, and investment in the product itself.

As I thought about building the team, I landed on hiring strong design generalists first, then scaling to include specialists (across design functions like writing, research, motion, and interaction design) later. By focusing on generalists out of the gate, our small team could work in a scrappy way to accomplish whatever needs to get done quickly. The outputs of this small group’s work may not be ideal or perfect, but when it comes to a startup, done really is better than perfect. If you’re not moving quickly—producing work, snuffing out fires, and focusing on scaling—the competition is always there in the wings waiting for their chance in the spotlight. Design generalists are exceptional at moving quickly, no matter the task.

During the first few months at the company, I also learned just how difficult hiring can be.

I've participated in interviews before, but have never been responsible for defining an open role, writing the job post, creating a rubric for evaluating designers, and putting together an interview guide.

When it comes to hiring, that's not all: during the first few months of looking to hire designers, I had to actively reach out to potentially strong candidates and show them why joining a small, early team like Gem design was a good move, even though externally it can seem very risky as a career move. It’s a hard sell for many designers who cherish stability and certainty over the potential reward of being an early leader at a growing company.

General wisdom when it comes to hiring is to go with who you know. Close connections—the people you have worked with before—are easier to hire for and more reliable in the long-term but also introduce a ton of bias. I knew from the start I wanted to build a diverse team of designers from many different backgrounds and expertise areas, not just from my network of former colleagues at big tech companies like Facebook and Lyft.

So, after countless months of talking with designers, reviewing portfolios, calibrating the hiring team, making offers only to have them declined for various reasons, we landed two incredible designers within my first eight months on the job. Melinda Kilner and Wandi Liu joined the team, and each has contributed heavily to the overall makeup of how we work and what it means to be a team. I could not be more thrilled with both of these designers and the work we’re doing together to build the foundations of what will inevitably be a truly world-class design team.

If you’re hiring designers you can’t be afraid to hire from smaller companies than the big FAANG ones. You should look for designers with strong processes, adaptability, creativity, and grit. You may be surprised what you find when you give a conversation a chance.

Of course, having such great designers on the team has meant my perspective of leading them has evolved as we continue working together and scaling the team.

When we say "head" of the team, I now view that as helping to gently nudge decisions, demonstrate practices and processes, and provoking meaningful discourse and debate for both the team and individuals on it.

I've learned an incredible amount in this role already. I've learned about startups and how to both show up and not show up as a leader (those messages you send on Slack intended to be witty and humorous, for example, tend to have a different punch when you’re a leader). I've learned about the way design can subtly influence decisions inside and outside the company (a vision workshop can be helpful for driving vision, but only if it’s regularly referenced).

More than anything: I've learned I made the right decision bridging the gap between IC and manager. Because in this role, I've discovered my passion for getting to know the individuals I work with so closely daily. I've uncovered just how incredible (and incredibly hard) it can be to get people aligned and doing great work. I’ve learned from my team, and I’ve seen the mistakes I’ve made in the past as an IC designer. I’ve grown a lot, partially out of ambition but probably more so out of necessity.

I now wake up every day both excited and anxious for what the day holds for me in this role. Where will I fall short? What new obstacle will I uncover and have to maneuver around? Am I making the right decisions for my team and the company? Am I contributing in a way that is helping move the bottom line? Is this road going to be one I want to stay on for a long while? Only time will tell.

For now, I'm loving it all. The challenges and opportunities.

Illustration by Molly Magnell for this article.

The value of a good one-on-one meeting is nearly immeasurable.

It's a time to sync on things in a format you can't get any other time or in any other medium. You don't have an audience waiting in the wing to jump into the conversation, nor distractions to pull your attention away from the other person. I believe a great one-on-one is where your best work often gets done.

To make your one-on-one's more effective:

• Define and agree upon their purpose together
• Be clear about the schedule
• Use the time to sync on anything you can't anywhere else
• Work to keep things casual

Define and agree upon the purpose up-front

First-and-foremost, you'll want to set a clear plan or purpose for your one-on-one meetings.

The plan can be high-level (e.g. "Catch up on everything that happened over the last week in our lives.") or focused (e.g. "Discuss a decision I need to make tomorrow around Project X."). The key is to have a clear purpose or agenda both parties understand before the meeting. Whether you're meeting for the first or hundredth time: get aligned on the purpose and plan of the time.

What do you each want to get out of the time? What would a successful sync look like for both people? What is most valuable to the relationship? Even if you spend time catching up, that's an important use of time for teammates to have.

Be clear about the time and recurrence

It's not enough to agree on the purpose of your one-on-ones. Both people should know in advance just how much time will be dedicated to the meeting and how often they will occur.

Some people use 1:1s as a way of getting updated on work. Others use it as a chance to chat and get to know the other person casually. In either case, the amount of time required will play a part. Discuss and agree on how much time you'll need to fulfill the sync's purpose and how often you should be meeting.

Consider how close your relationship is to the person: weekly is the right cadence if you work very closely. If more casually, as far out as once a month can suffice. It will vary for every person you meet with and the purpose. Staying in-sync on personal goals can be less regular than meeting to stay connected about the work.

Use the time to discuss things you can't elsewhere

Email, group posts, Slack chats, and more are all excellent ways to stay up-to-date with your peers about ongoing work, in asynchronous methods more often than not. You may not have the ability to sync on more personal or pressing matters with a level of emotion or nuance to them in these methods, however. One-on-ones are for things you can't say in the other means or something that may not be suited for those channels.

Focus on the individual, the working relationship, or things that may impact others but need to be figured-out in-person, in advance. Consider the value of any one-on-one as being able to discuss these crucial subjects on a micro level, without interference or the ears and eyes of a larger audience.

Ask yourself (and the other person): "What conversations are we not having elsewhere?" Those are what your one-on-ones are for more often than not.

Keep it casual and human

It's worth noting: one of the best aspects of one-on-ones is you have them in real-time, usually face-to-face, with one other person. Meaning: you can see the person, you can better understand what they're saying or how they're listening, how they're responding to what's being said (in real-time), and you can interject the conversation with questions or ideas on-the-fly as necessary.

The work we do as teams ultimately comes down to the work we do as individual human beings. Often when we get buried in project scope documents, design mocks, and customer feedback requests, it can be hard to remember we're all people functioning together.

Keeping one-on-one conversations as casual and friendly builds the working relationship and enables you (as a team) to better tackle work subjects.

One-on-ones can be awkward or time you wish you were spending doing work, but ultimately the investment made in a good conversation with one other team member can pay immense dividends. A good one-on-one is any one-on-one where both people understand the purpose of the time, where they have agreed on how long and how often the time should be spent, and where each person uses the time to connect at a human, casual level.

Illustration by Bonnie Kate Wolf for this article.

To effectively navigate product complexity as a designer, think of the narrative around the product.

The story we tell ourselves, our peers, and our customers about the product and how it works is ultimately the resulting work we put out into the world.

To design effective experiences it’s not enough to think of our work in terms of features, patterns, or libraries, but rather experiences that play out in a narrative arc, wherein the user is the star. This narrative is always one that encompasses much more than what we can control and yet is the space within which we must play, experiment, and create.

This is unfortunately not how many designers are taught to think about the work they do.

Designers will often think of only features or feature areas as they work: "This is the profile part of the product" or "This is the billing or settings part, this is a list of controls for this particular thing." Understandably, it can be both challenging and/or exhausting to think more holistically.

Having a micro perspective of a design task is important for focused ideation and execution, but each of these things—features and feature areas—are always part of a larger whole, and if we forget that fact we often end up designing something that doesn’t really do it’s job; what the late Clayton Christensen defined as "Job to be done."

Jim Kalbach, in his book The Jobs to Be Done Playbook, breaks down the five elements of any job to be done:

1. Job performer: The executor of the main job, the ultimate end user
2. Jobs: The aim of the performer, what they want to accomplish
3. Process: The procedure of how the job will get done
4. Needs: Why the performer acts in a certain way while executing the job, or their requirements or intended outcomes during the job process
5. Circumstances: The contextual factors that frame job execution

When considering a design experience we tend to emphasize our attention on job performer and their jobs, only occasionally pulling in the process of how a job will get done via interaction design patterns we create.

But, as with any good story, we also need to understand motivations and context—the circumstances and needs around the job performer and their job—to develop a complete picture of what it is we’re solving through our designs. This is the product narrative designers need to understand and develop in order to do their best work and grapple with the complexities of large-scale product design.

Even if the scope of work a designer is responsible for is feature-level, understanding the larger product narrative helps ensure the feature work aligns with the bigger "job to be done" of the end user. No user comes into a designed experience with a completely fresh and empty mind, ready to partake in whatever experience has been designed for them. No! Everyone comes into an experience with a lot more than we can intuit: are they having a stressful day, do they want to race through the experience or take their time, are they casually browsing or actively seeking solutions?

If you want to create more cohesive experiences across a large system or platform, think not only in terms of feature areas, but of the narrative behind the system itself. That story is what ensures the work will… well, work.

A product narrative will come as a result of many diverse forms of conceptualization: a static user experience map, a low-fidelity prototype of a complete product experience, a series of recorded phone or video calls of customers describing their day-to-day process, or a set of storyboards highlighting the core experience of the product.

These artifacts are not necessarily "the product narrative" but rather elements that inform the narrative. Teams need these artifacts in order to start the dialog around what the narrative will be. The product narrative itself is how the team and users talk about the product.

If the team you work with isn’t telling the same story, you’re going to create features that don’t align with one another or you’ll run into differences of opinion or principles as you work that create unnecessary roadblocks. Your team needs to make story telling a team initiative.

If you have product managers, this is often a fundamental part of their job: creating and disseminating an initial version of the product narrative. Designers and product managers should work closely together (with customer success leaders, sales members, executives, and others) to ensure there’s a narrative about the product that is internally shared and agreed-upon.

A simple narrative written out can have lasting effects, particularly when considering the additional "chapters" to the story that influence new features or areas of work. Asking "How does this new area of work play a role in the existing product narrative" is one of the most effective ways at ensuring work the team does is aligned to a larger initiative that pairs well with company trajectory.

To learn more about creating a strong product narrative as a team, listen to this episode of the Inside Intercom podcast with James Buckhouse who says:

"You start with personas, and you map out the personas. Those personas are the character in your movie….Each one of those characters is important, and each one of those characters is going through an arc… At the very beginning of a design project, I would find the engineering lead, and the product lead, and the design lead – or if I was the design lead I would be there. We’d have a sheet of paper and we’d talk about the problem in the world. I would take out a pencil and I would make the smallest mark I could on the page, like a circle, and I’d say, ‘This is the user.’ I’d hand the pencil to the engineer, and ask, "‘What are we trying to do?’ As soon as you can get the engineer to draw on the paper with you, and you can literally draw together to make a solution, everyone’s invested in co-creating this thing."

There’s much more to creating a product narrative than what I’ve teased here, but that’s a story for another day. For now, know that if you’re designing anything it’s part of a much, much larger story, and if you want your work to be effective it’s important to be in-tune with that narrative.

So much of design work comes down to the story we tell ourselves about the experience we want *others* to have. If we don’t know the full story, it’s hard to know what small piece our work can play in it.