How design teams can demonstrate impact to a doubting product org

image credit: Esteban Lopez

Many years ago, early in my career as a UX designer, I was at an agency finishing up wireframes for a client. The account executive came to my desk with questions and a suggestion. He stated he had doubts about how I had designed a particular feature.

“Why did you design it that way?” he asked. So I provided an answer citing current design trends and how this approach eliminated clicks. He was unconvinced, and argued for a different design approach. I referenced ease of use and insights we gained from user interviews pointing to my approach being better. The account executive called into question whether the research was sound — “why that way?” he asked again — and again pushed for his approach citing how he thought users would behave. Round and round we went, me making the case for my design based on my experience and expertise, him questioning it and pushing for his approach. He was not moved by anything I said. Finally, quite exasperated, I responded to his latest “but why that way?” question with: “Because I’m the UX designer and you’re not!”

I’m rather embarrassed by that response. I’ve thought about it many times over the years and I cringe every time. It was absolutely the wrong thing to say. I did go up to the account executive afterwards and apologized for my behavior and we cleared the air. Still… uggh.

Many designers struggle to justify their work to others. The above example, if not the poor response by me, likely sounds familiar to many designers. It should be self-evident that design matters and is valuable. The struggle is real. Many organizations wrestle with this challenge: how do you quantify the impact of design?

Now the easy answer here is: focus on metrics. Yes, do that. Design teams need to frame their work through the lens of business metrics. Define success criteria before the work kicks off and measure the change in those metrics when work is completed/launched.

But for this post, I wanted to share examples of how design can demonstrate impact and value beyond just improved metrics. I’ll share three real world experiences where my design teams have delivered results and changed perceptions of our efforts for the better.

1. Stop calling… please

When I first arrived at Liberty Mutual I was tasked with building out a new design team for our part of the organization where one had not previously existed. Most of the PMs and engineers were not used to working with design and as such we didn’t have their trust. There was a lot we wanted to push for but was not making progress. What we could do and how much change in features and page construction was very limited. Often we were asked to use only existing (old, poorly designed) components.

At that time there was a big push to reduce calls. Calls cost money and Liberty wanted to push more people to a digital self-service model (that didn’t quite exist at the moment; more on this later).

Data analytics identified the page that generated the most calls into Liberty Mutual: the Contact Us page. I was asked to have my team redesign the page so it generated fewer calls.

Liberty Mutual Contact Us page, 2017

The problem is the page was already designed in a confusing manner that made it hard to find a phone number. In fact, users found prompts to mail a letter or fax a request before you came to a phone number. There was little I could do to make the page less directive to calling (short of transposing digits in the provided phone number).

My team started by reviewing the available analytics for the page. One data point that stood out was the high number of call transfers it generated. There are two main numbers for Liberty Mutual — one for customer service and one for sales. Liberty had calculated that the cost for a representative to transfer a caller from one call center to another to be $3.50 per switch. So we ran an A/B test: the test page would display clear headers indicating one phone number was for customer service and one was for sales. The control version was the existing page without headers.

The results were dramatic. In the control version calls were evenly split between the two numbers (571 calls for sales vs. 452 for service). For the page with headers, almost all calls were for customer service — 852 for service vs. 29 calls for sales. Users were now getting to where they wanted to go. We virtually eliminated call switching, which saved Liberty hundreds of thousands of dollars annually.

This was a simple test that didn’t really require design work. But what it showcased was design’s ability to evaluate a problem, hypothesize a solution, and deliver results. This small success put our nascent design team in a positive light. We earned just enough trust to explore more involved changes. We would iterate on content and design patterns that made the Contact Us page more aesthetically appealing while also better helping users accomplish what they needed to. We leaned into self-service, getting users answers and increasing login-rates. We would even launch a successful chatbot.

All of this became possible because we could succinctly demonstrate the ability of design to solve real business problems and deliver meaningful results.

Liberty Mutual Contact Us

Let design lead the way

One summer the engineering team at Drizly was bogged down in extensive, and necessary, infrastructure work. It was all-consuming and demanded everyone’s attention. Except for design.

With a lighter workload, I had the design team take advantage of this lull to focus on users. Specifically, we undertook the effort of mapping out the primary user flows of our consumers. What were the main tasks they wanted to accomplish and what was the experience actually like for them. We documented everything. We also layered in available user research findings. We zeroed in on every point of friction for users, calling them out. We also identified opportunities to make different points more joyful (one of our design principles). We had everything laid out for onboarding, browsing, gift-giving, checkout, and several others.

This wasn’t busywork or a way to continue practicing our craft. I had an insight. Q4 is the busiest time of the year for Drizly. Historically we’ve been slow to get work done ahead of Q4 that we know will improve the Drizly experience. We end up rushing out quick fixes scattershot. I also knew the rest of leadership and the PMs hadn’t had time to think beyond the infrastructure work. We would need a plan. To borrow a hockey metaphor, I was skating to where the puck would be.

I pitched the C-suite on what I was doing and got buy-in. I presented our work at a product team all-hands. Sure enough, there had been little planning done on what to launch in Q4. The design team’s work solved that. I met with senior PMs to break down the findings and plan out the work. We decided our big focus should be on gifting enhancements. We had queued up 55 tweaks, fixes, and general improvements to the gift-giving flow that became the consumer team’s priority. We launched them in time. What we saw was a dramatic reduction in customer-service contacts (the need for Drizly CX to contact recipients) and a flattening of order void rate. Historically gift-giving void rates were much higher than non-gift orders. For this holiday season, the rate was the same as all other orders.

Some unknowable answers are knowable

One fall while at Drizly, I was part of a lengthy discussion with senior leadership about developing in-store pick-up as a new feature for order fulfillment. Drizly is an alcohol delivery service, but the theory was that users may like to order ahead and pick up at the store if it’s nearby or on the way home.

This was actually a discussion that was had multiple times. We would discuss it, try to pull some numbers on the opportunity, feel the data was inconclusive. And then we would have the same discussion again a month or two later.

This felt like an unanswerable question. It seemed as though the choice was to build it and find out, or not build it. But results would be determined after it launched. There seemed to be no way to know ahead of time if users would want this feature.

I will state for the record that at the time, I thought it might be better to build the feature than to not because at the very least it would be something some people used so… bonus?

There was one thing that changed that fall. I had onboarded our first UX researcher. More interesting to me than whether we should build this feature or not — and be right or wrong about it — I felt this was an excellent opportunity to prove the value of UX research. After conferring with our new researcher, we developed a study that could help get an answer to this question and I positioned UX as the team to solve this question from the C-suite.

We conducted what’s called a Kano analysis where users are asked about a bunch of features to evaluate their interest in those features. It will show some signal about whether users think the feature is exciting, considered table stakes, or something that’s just not that compelling. We asked users about a bunch of features related to fulfillment — the last mile of the experience.

The findings of the study showed that users weren’t excited about in-store pick-up. People might use it, maybe a nice-to-have, but not a driver. What the study also showed was that user’ biggest interest was around transparency. Once an order was placed there was no information available until a driver showed up with their delivery. Users found this frustrating. Users were interested in more information about their order post-order. This led us to prioritize live order tracking.

Live order tracking for Drizly is a bit more complicated than the same feature on Uber Eats or DoorDash. With those examples, the driver is part of the delivery service (Uber drivers and DoorDash drivers). With Drizly the driver is employed by the store, so we have less real-time data to provide. This makes the service a bit more complex. But the Kano study and some additional user interviews gave us the confidence to build live-order tracking. We would launch it the following year to great success.

Drizly live order tracking

Design demonstrates impact

Three examples of design proving their value, showing the impact the team can have on the organization and the products they build:

• Design able to properly diagnose the problem and deliver a solution that returns desired results.

• Design able to anticipate organizational needs and develop quarterly roadmap planning when teams are focused on immediate concerns.

• Design able to answer questions that seem unanswerable, identifying the features and innovation that users desire.

So yes, as a design team you should understand business metrics and organize your work around delivering those results. But more than metrics, design practices a methodology that helps organizations move forward — to identify opportunities and quantifiably determine the best paths forward.

image credit: Yulia Matvienko

The one thing leaders should focus on when building a successful team

Building successful design teams is something that I’m passionate about. I’ve had the opportunity to do this at several organizations and I think I have a certain talent for it. It’s definitely rewarding. Bringing together a collection of designers — of well-meaning people — and through process and coaching helping them to become a cohesive unit that elevates the output of each other and the larger product org.

I’ve talked previously about how I build teams. You can read about it here. What I haven’t talked about though is the one metric I most closely monitor when forming a team (and maintaining its health). That one thing is: team members’ talk time. I’m paying attention to how much time each member of the team talks in any given meeting or gathering. Is it roughly equal? Then things are good. Is one person or a small segment of the team doing most of the talking? Then we may have a problem.

The more clinical way to describe the metric is: Equality in distribution of conversational turn-taking.

It’s a little obvious when you think about it. Is the culture of the team such that everyone feels able to speak their mind, contribute, and have a sense of support and safety as they do it? Or are people reserved in meetings, worried about saying the wrong thing or and being criticized for it?

Project Aristotle

In 2012, Google embarked on an effort to identify what makes a team successful. What are the markers that all accomplished teams have? Researchers set about quantifying this and looked at all factors they could think of: previous success, years of experience, awards, educational background, years together. They looked at it from every angle they could measure. This research effort was code named Project Aristotle.

Eventually they began to focus on team norms. Through research, study, and various social experiments, they found that how a team was set up — the behaviors that were encouraged and the behaviors that were discouraged — had an outsized impact on the performance of the team. More specifically, this could be boiled down to equality in distribution of conversational turn-taking (team members’ talk time). When people felt safe to speak their minds in a positive and supportive environment, the collective intelligence of the group went up (leading towards more success). Conversely, when the free flow of ideas from members was hindered because people felt less safe to share, the intelligence went down.

All of this was written about in the New York Times Magazine back in 2016, in a feature issue examining the science of working more effectively. I read the article when it came out. This was early in my time as a design leader and the lessons have stuck with me; I think about them often. You should take the time to read the article yourself, which you can find here.

As the researchers studied the groups, however, they noticed two behaviors that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘‘As long as everyone got a chance to talk, the team did well,’’ Woolley said. ‘‘But if only one person or a small group spoke all the time, the collective intelligence declined.’’

Tending your team’s culture garden

Any group of team members will naturally form a culture, a way of behaving when together. These norms may be positive or negative. The only thing you can be sure of is that they will form. These norms are what an effective leader should be focusing on as their team forms.

One can be explicit in defining norms, and I think group discussion and affirmation of those norms is important. But what behaviors are written down aren’t necessarily how people act. It’s important for leaders first to model the behavior — adhere to the agreed upon norms. And it’s important to encourage the behavior, through conversation and consistency.

I think about culture and team norms like tending a garden. Provide the proper nourishment (encouragement and support) where appropriate. Weed out the elements (actions) that threaten the team’s growth. Be mindful and always attentive. Absence will lead to bad outcomes quickly.

Equality in distribution of conversational turn-taking

Which brings me back to talk time. In meetings with my team, I think about this often. I take mental note of who has spoken and who hasn’t. I solicit opinions from those who haven’t contributed. I do this in a positive way (nothing shuts down discussion like calling people out). I demonstrate real interest in what each person has to say.

I’m also mindful of my role as the boss and the weight that carries. And then I try to counteract it. In discussion I recognize that I can end discussion when I speak. Who’s going to argue with the boss? I try to withhold my thoughts till the group has shared theirs. I also encourage push back — I ask directly for people to disagree or critique what I’ve said. And I genuinely listen to the feedback.

As a leader, your job is not to have the right answer. It’s to build a team that consistently finds the right answers. Creating an environment where each member of the team feels supported and safe to share their perspective, to listen to others and adjust their thinking appropriately, is the best way to achieve this goal.

Talk time. Roughly equal amongst the diverse members of your team.

---

Seriously, take the time to read this New York Times Magazine write up of Project Aristotle and what Google learned about building effective teams.

4 thoughts on the intersection of UX and AI

photo by Greg Rakozy (Unsplash)

I recently had the opportunity to take part in a panel discussion on the intersection of UX and AI. It was really fun. I got to meet some really smart people (Alex Candelas, Jon Peterson, Tcheilly Nunes) and we had a really interesting and engaging discussion about how AI is impacting the world of product design, and by extension, the digital world we all inhabit. You can watch the panel discussion here.

Designers absolutely have a huge role to play in AI — how it will be developed, productized, and introduced into user experiences. From that panel, I wanted to share 4 things I’m thinking about.

#1: AI will change everything. But the designer’s job will not change.

Everyone is predicting that AI will change everything in the next few years. It’s already upended so much, finding applications in healthcare, finance, retail, and media. Companies everywhere are rushing to add AI capabilities (often before figuring out what/why they need AI for their business). Data scientists and machine learning engineers are in high demand as LLM are developed and vast amounts of data are being crunched to power these systems. It’s all engineering-intensive and technical and certainly opaque to the uninitiated. How can a designer make a meaningful contribution to all of this?

By doing their job. A designer’s job isn’t to make something look aesthetically pleasing, stylized or beautiful. A designer’s job is to understand the user, understand the problems they face and the things they hope to accomplish. A designer’s job is to define the problem (correctly) and design solutions that address that problem in an effective and desirable way. And so it is with AI. The designer must figure out how AI can be used to solve real user needs (or not when AI isn’t the right solution). Everyone’s integrating AI into everything with little to no innovative ideas of how to apply it. Designers are needed to craft solutions that matter to users. They’re not designing chatbots. They’re designing experiences.

#2: AI is a tool, not the solution.

AI is a very powerful technology that seems to just be getting started. Its power and capabilities seem to grow exponentially every year. Companies are racing to add AI to everything, stand up some product enhanced by AI (and then market the hell out of the fact that they “have AI”).

Users don’t care about this in any meaningful way. Maybe they’ll try your product out of curiosity, but this is not likely to lead towards regular usage. AI is not the point for users because AI isn’t the solution to the problem they have or task they need to accomplish. AI can possibly help in addressing that need, but as a means to an end.

It’s the designer’s responsibility to figure out how to integrate AI into a product or experience that is effective and desirable for the user.

#3: AI should be invisible, not human.

ChatGPT can be fun to interact with. Alexa can be genuinely helpful in certain situations. Siri, not so much. All this effort to create AI that is more human, that you can chat with feels to me to be a wrong path, possibly a dead end. AI as it currently exists cannot become “more human.”

AI is trained on large data sets. It identifies patterns in those data sets and then offers up what it predicts will be the next sequence in that pattern. It cannot learn to be empathetic or creative or curious. Any behaviors it exhibits are merely programmed responses that a developer created to make AI appear more human. But it’s not real. For me at least, every time an AI-powered product provides a “human-like response” it feels fake and insincere. The contours of the response immediately become rough and jaggest, the illusion dissipates.

AI seems to be most effective when it’s not noticed, when it can’t be seen but the results it powers are desired. When Spotify plays a string of songs you hadn’t heard before but really love. When Netflix recommends a movie that turns out, you really like. When Google answers the question you typed into the search bar at the top of the results page rather than have you click into a page and find the result.

When AI creates a seemingly auto-magical experience — the answer or outcome you desire without having to go through the steps to achieve it yourself — the technology seems to be most effective. These should be the types of experiences we’re trying to build with AI.

#4: Be curious.

This is probably the most important thought I have on this topic.

AI is a new technology and it will impact and transform so many industries and experiences. It will be used to create unique experiences that we can’t even imagine today. So start getting familiar with it.

Play around with chatbots and image generators. Use ChatGPT to generate a list of ideas for blog posts. Have it create a first draft of an important email you need to send but have been putting off. Use it to generate a list of user interview questions and then refine them. Experiment with different prompts to get a better understanding of what’s effective. Read interesting Medium and LinkedIn posts about AI.

As much as you can, immerse yourself in AI tools and the discussion around it. By becoming familiar with AI, you’ll gain a better understanding of its capabilities and limitations. The edges of what is possible and what is not (today). This will position you to be able to leverage AI in the future experiences you will design and build.

Discussion on the intersection of UX and AI

Last Thursday I got an opportunity to be part of a panel on the intersection of UX and AI. It was a really fun experience. We covered a lot. Great points made by lots of people. You can watch the video here:

Panel discussion on UX and AI

Building user research into your product process

Establishing an effective user research practice can prove to be a huge unlock in the maturation of a product design team and the larger product organization. It not only helps you evaluate the effectiveness and desirability of new features you launch, or tell you what’s not working with the current experience, but it can also point you towards fertile ground in developing new services and solutions that help users in meaningful ways.

At Drizly we set up a very effective user research practice that supported and influenced every part of the organization. It took a lot of effort from a lot of people - not just the research team. Ultimately we transformed how the organization planned and built features from beginning to end and became a valuable tool in quarterly planning and defining our North Star.

The obstacles

I see two obstacles in establishing a robust user research practice. The first and biggest obstacle to overcome are the misconceptions others in the org have about user research - what it is, how it’s conducted and (most importantly) how much time is needed to do it effectively.

Most people have a concept of user research. They’ve witnessed user interviews. They’ve heard of prototype testing. They may know that there are quantitative studies and qualitative studies. What most people don’t fully grasp is that there are many types of user research tasks that can be conducted. The trick is understanding the type of question the team wants to ask (or the thing they hope to learn) and then applying the most relevant task to get at that answer.

A good way to understand this is the NCredible Framework which helps identify what you’re trying to learn and that determines the type of tasks best suited to answer those questions. Most product teams are not familiar with this and so they piecemeal their understanding of user research, not understanding the methods and rigor that goes into effective research.

credit: Twig + Fish

Another aspect of this first obstacle is the perception of how much time user research takes. There is typically an assumption that it takes a lot of time. Meanwhile squads are on hold and getting behind. Better to rush forward than pause or delay, so the thinking goes. These time assumptions are usually incorrect (you’d be surprised how fast an effective research team can move) and also a result of not planning up front to include user research.

The second obstacle I find is on the research/design team. It’s important to understand where a company is in their maturation and the pressures they’re under to get work done. Introducing a new method (user research) into a process that’s under immense pressure to deliver is asking a lot and PMs and engineers need to see the manifest value of a new process before they adopt it. Quick wins and positive experiences are critical in adopting user research and should be the primary focus early on. Too often I’ve seen research get bogged down in process and poorly communicated timelines. This leads to frustration on the part of product teams. They will not buy in.

I want to stress here that while it’s important for researchers to conduct their studies quickly and deliver quick wins, I am not advocating for slipshod work or cutting corners. Researchers should never compromise results with improper methodology.

Building User Research at Drizly

When I joined Drizly, we did not have a formal user research practice. Designers would conduct their own ad hoc research when they could find the time - maybe an unmoderated online prototype test or occasional retailer interviews - but no dedicated researcher with extensive training and expertise. To Drizly’s credit, they had budgeted for hiring a user researcher, a role I would take responsibility for filling.

To begin, I needed to define the role and its responsibilities. This was an important hire and ideally they would be responsible for setting up the foundation for the research discipline. I identified the areas that this hire would need to cover, three different hats they would need to wear:

User Researcher. Obvious, but important. They would need to be an excellent user researcher, versed in all the different methods and approaches, able to identify the right approach to whatever situation. They would be the only researcher at first. They needed to be able to do the job.

Educator. With many teams working on different aspects of the Drizly platform - one that serves three distinct audiences - the reality is that one researcher wasn’t going to be enough. But if the researcher could teach others to conduct research, impart the basics and advise on methods and tactics based on the situation, then we could extend research’s reach. We would enlist others to conduct research, starting with the rest of the design team and then extending to PMs, engineers, etc.

Promoter. With a new - and important - function being developed, we needed to make the company aware of it. We wanted other teams to get excited about the prospect of leveraging user research, incorporating it into their product team’s process. We needed someone to highlight all of the good and impactful work we would be doing.

It’s important when starting with one researcher, they can effectively serve each of these roles within it. I was blessed to find an amazing candidate, Kat Rutledge, who is a talented researcher who checked all three boxes. She is empathetic and entrepreneurial in her approach to building our research practice. She is an incredible partner.

Iterative learning

At the time we had a directive from executive leadership to make meaningful improvements to our overly complicated PDP. We already had multiple stages of development planned. I wanted to get user insights into the project. But things were already planned and moving. I got significant pushback in attempting to conduct research. We could not slow down.

We were still in the design phase for several components. We had a couple of weeks before engineers would begin working on them. I knew we could get initial studies conducted in that timeframe. I proposed two-tracking it - design would continue while research would run. These learnings could influence designs in real time, as they came in. No need for delay. Additionally, as we learned more things, we could adjust designs/builds on the fly.

This changed peoples’ perception of user research. It was not a drag on timelines. And as we learned, informing design, we began to realize the efficiencies of building what’s backed by research as opposed to guessing and learning after launch.

Answering seemingly unanswerable questions

A feature idea that frequently came up at Drizly was in store pick-up. This was a feature considered by executive and product leadership. We would discuss it in meetings, debate pros and cons, work up estimates, and the punt on making a decision. We repeated this cycle several times. It seemed to be an unanswerable question: “would users like and use this feature?” The pro side was that once built, it was an additional fulfillment option for users. It could be a passive win. The con side was that it would require a not insignificant amount of front end work and a lot of training for retailers to set this up in the stores. It never got prioritized, but it was always being considered.

I should say at this point I was for building the feature. My assumption was that in cities where people live closer to retailers, they would be more likely to use it.

More than my assumptions though, this was something I felt we could leverage user research for. Kat developed a study leveraging the Kano model, which evaluates users’ excitement or interest in various features. The study looked at different last-mile related features. In store pick up did not rate high. Consumers were “indifferent” to it, which means it would not move the needle.

What did generate enthusiasm though was live order tracking. This is a feature we had not prioritized because of the complexity inherent in Drizly’s operating model. Deliveries are not carried out by Drizly drivers. Retailers are required to provide drivers for delivery. As a result Drizly has almost no visibility into the order being delivered. This created a number of challenges to doing it well. Nonetheless, the study gave us the confidence to set aside in store pick up and pick up live order tracking. We built and launched it a few months later to great success.

Building research momentum

As part of Kat’s onboarding, I had her set up regular check-ins with the PMs. I met with leaders throughout the company. We were gathering information about work planned or needing to be scoped, looking for opportunities to set up a research study. It was slow going but we built a backlog of opportunities. We also presented findings at Product team meetings and company town halls. We set up learning shareouts where people were invited to listen to the readout of a recent study and ask questions. Kat put together a monthly newsletter of research activities and built a repository of study readouts.

This had a flywheel effect: the more research was shared and discussed, the more people were interested and bringing potential research opportunities to us. We quickly went from an outreach approach - can we conduct research - to an intake process - fielding incoming requests. Calendars were created. We hired another researcher. We invested in a research platform (Usertesting.com).

Research for roadmap planning

One thing every product manager I’ve worked with has in common is not enough time. Not enough time to think about future experiences. Not enough time to work out what a new and improved version of the flow they’re working on might look like. Not enough time to think more than 10 steps down the road. They’re swamped with the myriad challenges and issues that pop up day to day on the squad, to keep things on track sprint to sprint and so on. Before they realize it it’s time for another quarterly planning session and it’s a scramble to build out the roadmap.

We saw this as an opportunity for research to lean in. Rather than have research be just reactionary — how is this feature working or how to improve the current experience just a bit — we wanted research to run far ahead of product. Look further down the road and explore bigger opportunities. As part of our weekly check-ins with PMs, we started asking about quarterly planning and beyond. What were things that if you had time to think about, you’d like to explore? What answers would help you most moving into the next quarter?

We began to tackle these existential questions. Research studies were developed to go deeper into these questions. The purpose was so that we could enter planning with good signal into what users might want. This is a big and important shift. Instead of committing to a feature in a quarter and then conducting the research to validate that idea in the quarter, we would do exploratory research ahead of quarterly planning so that we felt good about the features we wanted to plan for.

Final thoughts

Building a robust user research practice makes a huge difference in product orgs. Integrating research into the fold, making it a part of the process rather than separate can lead to huge success.

In starting out, it’s important to build relationships and demonstrate real business impact. We made sure research ran quickly and in parallel with ongoing work so it did not become a blocker. We worked with product managers and engineers to understand their concerns and struggles and looked for ways we could help. As we built trust and demonstrated results, we worked proactively to include research as part of the planning process to the point where we could run ahead of the squads, and ultimately inform roadmap planning.

Pillar 4: Establish a design-thinking mindset

Pillar 4: Establish a design-thinking mindset

Design thinking is a framework for identifying opportunities, exploring solutions, and testing them.

The benefit of a well-formed, effective design team is in how it transforms the whole organization, empowering everyone to think more critically and creatively in identifying problems, figuring out what to tackle, and the solutions they work towards.

This is design thinking, and while it has “design” in the name, it’s not just for designers. It offers a repeatable method for identifying opportunities, develop new solutions, and to validate those ideas, all relatively quickly. When this methodology is adopted by a whole squad, it superpowers their alignment and cooperation, and helps them work more effectively, autonomously.

Design thinking was popularized by the design agency, IDEO:

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”

— Tim Brown, Executive Chair of IDEO

Its approach has been adapted into the Design Sprint, outlined in the book Sprint by Jake Knapp of Google Ventures. This is the way a lot of organizations first interact with the methodology.

I’ve taught design thinking at several organizations now, and it is often quite transformative. I’ve led design sprints at multiple organizations. At Liberty Mutual we were committed as a company to instilling this approach within our product org and developed a program that immersed whole squads in a month-long effort, called Digital Garages that taught the participants the methods and principles, and had them working on a core product problem, interviewing users, and building & testing prototypes.

Scenes from a digital garage

A number of things happen. First, team cohesion grows. Designers, engineers, PMs are working together and building bonds. And since no one is stuck exclusively in their domain expertise (designers in Figma, engineers coding, PMs in JIRA… sorry), everyone is working together and equally contributing.

Design sprint cadence

This also gives the larger team a greater appreciation of the skills and approach designers bring to the work. They start to realize that design isn’t “make it look pretty” but rather, a user-centered approach to solving business problems. After I’ve taught teams about design thinking, I see the efforts of designers to be more valued.

One last key benefit of design thinking is that it sets the team up for success going forward. I’ve facilitated a number of design sprints over the years. And while we make meaningful progress on whatever challenge we focused on for the sprint, the team learns this framework and leverages those skills and exercises in their work going forward. Where a team might get stuck on “what to tackle next?” before they were introduced to design thinking, the team will set up an effective brainstorming session* to focus on a real user need.

* unstructured brainstorming sessions are mostly useless and essentially action that isn’t actually productive. A design thinking ideation session is very different.

Teams have the tools to better define the problems and challenges before them, to break them down into key parts, and tackle them effectively, all without wasting time debating about what to do or how to do it.

In conclusion

I’ve found that investing in these four areas will turn a collection of well intentioned designers into an effective team that can transform a product org and help power innovation throughout the company. It’s simple enough, to outline, but takes a lot of hard work from everyone involved to achieve. And it does take time. But once you make headway on these pillars, the transformation begins to accelerate.

What do you think? Have you seen other foundational pillars for building a team that I didn’t address? Or do you have questions about the how to structure this? I’d love to hear from you.

---

Check out the other pillars:

• Intro: The four pillars for building a successful design team

• Pillar 1: Strengthen design team culture

• Pillar 2: Drive design integration

• Pillar 3: Elevate design execution

Pillar 3: Elevate design execution

Pillar 3: Elevate design execution

Raise the bar for overall quality of what reaches users. Establish and meet a higher standard of excellence.

In companies with less mature design teams, focus is on expediency and less so on quality. Or more accurately, quality design is not defined. Get the work done quickly, hope it looks good, share visceral reactions but little in the way of constructive critique. As a result there is no way to truly execute consistently good design.

To elevate design execution, you must first define what “good” is. This is a step that is often missed in establishing an effective design team. Everyone has their own sense of what good design looks like (including non-designers). But this isn’t openly discussed and documented. When building a new team, this is something we spend some focus on: What is good?

This usually starts with an honest evaluation of the current state of things. Often one of the first things my team will do is complete a heuristic evaluation of the site or app (or both). It’s important to look at things holistically, screen to screen, review from beginning to end the complete user flow. Capture every inconsistency, every friction point, every potential area where the pushed live components don’t live up to the level of experience we want for our users.

The reality is that teams rarely look at the whole journey. They work on pieces of it with tight deadlines. Taking the holistic view is a chance for everyone to get a true understanding of what the experience is like. It also strips away the “we had to just launch it and move on…” excuse that often results in less than ideal experiences going live. Users don’t care what your constraints are.

And with heuristic evaluations completed, you will likely have a list of things to fix. And this is important because it signals to the rest of the product org a seriousness about craft. And it will also point to business impact (“fix this issue on checkout to improve conversion by X%”).

Design principles are an important part of defining good design. They help inform how one might design something, as there are often many different ways to solve a problem. Perhaps more important than having an agreed upon principles, is the act of creating them. This is an exercise that should involve all of the design team. The debates, discussions that will take place will challenge everyone and help crystallize for everyone what is important and should be the essence of the product’s experience.

Our team’s design principles

At Drizly we established a set of design principles. These informed how we would design solutions. For those who don’t know, Drizly was an alcohol purchase and delivery app that paired customers with local liquor stores. Orders had a minimum order amount. Design principle #5: “It should be enjoyable” helped inform the best way to address this. Initially we treated orders that were under the minimum as an error state. You order size is has not reached the minimum. We would redesign it to treat it in a positive light. We redesigned it as a progress bar, urging the user on and celebrating when the minimum was achieved. Both approaches are valid. But one is more inline with our design principles.

Over time, a shared definition of “good design” develops amongst the design team. It is important for this to happen organically. I certainly coach up the team and share what I see is good and what is lacking. But it’s important for the notion of “good design” is internalized.

This leads me to an important point: in the early stages of a design team, it’s more important to focus on process — how we make good design decisions — rather than any single design decision. If we build the foundation of a good design process, owned and championed by each designer, then we will more consistently make good design decisions.

To effectively elevate design execution, it’s critical that an agreed upon understanding of good design is developed by the whole team. If all design decisions have to run through the head of design — me for instance — then that leader becomes a choke point. You overly rely on the individual to make decisions and shut down growth and development for the design team. And it’s not scalable. And so in building design teams, I endeavor to coach the team on how to make good design decisions. This leads to more stable and consistent design execution.

---

Check out the other pillars:

• Intro: The four pillars for building a successful design team

• Pillar 1: Strengthen design team culture

• Pillar 2: Drive design integration

• Pillar 4: Establish a design thinking mindset

Pillar 2: Drive design integration

Pillar 2: Drive design integration

Increase design’s reach throughout an organization. Develop processes that force closer collaboration with product and engineering.

Often in companies design is set up outside of the working product org. A product manager will request a designer to design a specific thing, with requirements, and then reviews it, takes the completed design back to the agile squad. End of the designer’s contribution. And often the ask from the PM is solution-oriented and specific, rather than a discussion about the problem and consideration for how to solve that problem. This is a terrible way to involve design and leads to a lesser result all around.

I believe strongly in getting design as close to the squads doing the work as possible. They should be a part of the team if possible, dedicated certainly. In most organizations there aren’t enough designers to be assigned to a single squad (more designers are always needed!). But as much as possible, designers should align to specific squads, ideally those squads focused on a related/similar part of the user journey. This allows the designer to go deeper on a portion of the experience, think more on the same set of problems and thus generate a holistic view of the solution.

When designers work with the same squads, they get to know the people better and build relationships and shared vision. The first thing I coach to my UX team members is to develop a relationship with the PM. Get to know the things they’re thinking about — what are the problems they think about, what are the opportunities they’d like to explore if they had more time. Work with them to flesh these things out. This allows the designer to confidently focus on the things that matter. And to be sure, they should also building relationships with engineers and the rest of the team.

Designers should attend regular team ceremonies — standups, grooming sessions, retros. When they are viewed as part of the team, they are more closely involved and that builds cohesion. Collectively the team starts to think through problems and they leverage the combined perspectives and skills of each individual. Designer thinks through problems with the input of an engineering mind. Engineers better understand the thinking behind a particular design and work to maintain the spirit of that intention. The team ultimately pursues more thought-out solutions.

One small example of this that has always meant a lot to me: a few years ago a team was working on an ambitious project to redesign/replatform the entire site. One of my designers came to me one day, dejected. He informed me that the product pages we had planned to launch that day was going to be delayed. Apparently the engineer had noticed in QA that there were some CSS-related bugs in the display of the pages. Odd line breaks and font changes. Spacing was off. He brought this to the attention of the designer and the two worked throughout the day to solve the bugs. They got a lot of these fixed, but they needed another day or two to fix everything.

What this meant: a developer had a deadline, and pages that worked, but they didn’t look as good as they could look, and so developer and designer worked together. This is about raising the level of execution, the level of what “good” means. This was possible because the two worked closely together normally. That type of relationship is what you want to foster.

I believe there is an effective way to integrate design workstreams into agile frameworks. My teams have practiced what I call “UX Kanban” wherein the design work is tackled in kanban fashion — which is to say, the top priority is worked on, and then the next priority is taken up when the first task is completed. This regardless of whether the agile squad is operating in sprints or kanban themselves.

The design work is tracked in JIRA, or however the squad tracks stories. It’s important to use the same board and methodology here. It offers one simple place to see all work — backlogs, in progress and status, and completed work. If an entire squad has a single source of truth for work, why introduce a different source for just design work?

I find UX Kanban offers three main advantages:

• Transparency: Squads and PMs can see the status of everything. What’s being worked on, what the blockers are, and how things are tracking. This is critical to every agile squad.

• More UX “autonomy” to tackle work: Designers know what the biggest priorities are and the order they need to be worked on. When this is not in place, I’ve often seen PMs either struggle to come up with the next task or they fill the time up with less-meaningful tasks. This keeps the right work moving.

• Reduced time between design and development: A benefit related to transparency. Also when the work is reviewed and discussed in progress as happens with JIRA, there’s greater shared understanding. This reduces hand-off time.

It’s important that design work does not get trapped in a black box. PMs and engineers and whomever should be able to see the work in real time, as requested. Status should always be communicated. Now with that it’s important for non-designers to be comfortable with seeing work that is in progress and not finished. Equally, designers need to be comfortable sharing work that’s still in progress.

It’s also important that the design work is conducted outside of the sprint, which is to say, not bound by a two week cadence (or whatever sprint length the team adopts). Design work doesn’t break down into discreet steps the way engineering work typically does. When you try to write out tasks for each step of a design process, things get messy and unwieldy quickly.

The designers will still have “in sprint” work, and this is crucial. Once engineers pick up the work completed by the designer, the designer should be available, supporting in any way they can. On call to provide context and explanation, to provide ad hoc QA, to make any necessary changes to the components. This work doesn’t get tracked in JIRA, but should absolutely be viewed as necessary work by designers.

One last point: I instruct my designers to write their JIRA tickets. They should be responsible. It helps them think more akin to the way the entire squad is thinking. It also gives them more ownership of the work itself. I’m not as concerned about the stories being written in the same format as engineering stories. They should still provide any critical context and be generally informative.

Getting design properly calibrated and working hand-in-glove with product and engineering is hard work and requires trust and accommodation by all of those involved. But once integrated, the team will really start making a huge impact on the work to be done.

---

Check out the other pillars:

• Intro: The four pillars for building a successful design team

• Pillar 1: Strengthen design team culture

• Pillar 3: Elevate design execution

• Pillar 4: Establish a design thinking mindset

Pillar 1: Strengthen design team culture

Strengthen design team culture

Mold individual designers into a cohesive team. Establish a design process that is repeatable and scalable.

It’s important to focus first on team culture. How does the team interact with each other? What are the norms that everyone must follow? What about team ceremonies? Investing early in team culture is critical. Without it, very little else you do to build the team will matter.

Culture is important for how people treat each other, how they communicate and how they show up. It’s often overlooked for seemingly more pressing concerns (design execution, urgent deadlines, whatever). Here’s the thing though: culture will form no matter what. Norms are constantly being established. So one can focus on it and nudge culture in different directions, or it can grow wildly and hope that it serves your needs.

There’s a study I read 8 years ago that has had a profound impact on my leadership style. Google conducted a massive study to determine what factors most contribute to a successful team. They looked at every possible factor — experience, past success, training and background, length of time together. What Google found is the biggest determinant of team success was talk time.

If each member of a team spoke in group meetings roughly the same amount of time, that was the biggest predictor of team success compared to any other factor. This finding has always stuck with me and I think about it constantly. When I’m in meetings with my team, I notice who’s participating and who’s not. How can I create an environment where people feel safe to share and ask questions? How does my role as team director encourage — or shut down — conversation?

You can read about the study in this New York Time piece.

Often a design team is understaffed compared to the organization. Rarely can a design team dedicate a designer to a single squad, let alone multiple designers. But designers work best when they can collaborate with other designers, share ideas and feedback. It’s important to build into your team opportunities to collaborate and share work, through design reviews, working sessions, etc.

Typically, I’ve established several recurring meeting types to aid with team cohesion:

• UX Team Standup — Occurs once Monday morning. Team shares what they’re working on and any potential obstacles. Announcements and updates also shared. The rest of the week we will usually have Slack standups where people post each morning their update.

• UX Design Review — It’s important to provide regular opportunities for individuals to share work and get feedback. So instead of a single 1 hour (or longer) block occurring once a week, I’ve opted for 20–30 minute standing review sessions that occur 3 times a week. If people have work to share, they bring it. If they don’t the meeting is canceled.

• UX Workshop — This is dedicated time, once per week, where a design team member can request help on a particular problem. The team gathers for a workshop-type session where designers can collaborate. The person requesting the time has to organize the activities. If no one requests the time, the session is canceled.

typical design team calendar

---

Check out the other pillars:

• Intro: The four pillars for building a successful design team

• Pillar 2: Drive design integration

• Pillar 3: Elevate design execution

• Pillar 4: Establish a design thinking mindset

The four pillars for building a successful design team

The four pillars for building a successful design team

I was recently having a conversation with a company about design teams. Specifically how to build and scale them. This is a topic I’m passionate about. I’ve had the opportunity to do this several times at different organizations and have had success. Building design orgs can transform how a company builds product, goes to market, and relates to their users. And a really good design team has the ability to unite Product, Engineering, Data Science, Marketing, and a host of other departments to a common purpose and alignment.

A design team assembled well, is greater than the sum of its parts*. They support each other, encourage, and learn from each other. They grow their talents and capabilities. They also form a stronger, nuanced, and more comprehensive POV on the design aesthetic and user experience for the products they design. And in turn they can take that POV and more clearly articulate it to others — product, engineering, executive leadership.

* I should note that when I refer to the talent on a design team, I mean the full spectrum of roles: designer, researcher, content strategist, UX, design ops, everyone.

In building teams, I focus on 4 pillars that form the foundation of a strong, vibrant design team. They are:

• Strengthen design team culture

• Drive design integration

• Elevate design execution

• Establish a design thinking mindset.

Done correctly, this allows a design team to scale quickly and make a meaningful impact on the company.

---

Check out the pillars:

• Pillar 1: Strengthen design team culture

• Pillar 2: Drive design integration

• Pillar 3: Elevate design execution

• Pillar 4: Establish a design thinking mindset
  

Better things than chatbots

In the beginning, we had to learn it’s language to interact with it.

Computers required users to adapt to them in order to make it do something. Eventually we developed the graphical user interface to hide the programming-speak and but this is still mostly an illusion as we’re still constrained to think like a computer and structure our interactions in a way that makes sense to a computer (tasks need to be done sequentially and in order, meaning and intent don’t factor into it, etc.). But we are fast approaching an inflection point where this dynamic is reversed and the computer will respond to human natural-language input. We’ll be able to speak naturally and be understood by technology.

This post is about AI.

As AI becomes ubiquitous, interfaces everywhere are being redesigned to center on chat. Conversation design/UI is being rolled out everywhere. Companies are asking themselves, “Can we use AI to make this a better experience for users?”* In my role as design leader I regularly have internal discussions about deploying chatbots as a new feature enhancement, at Drizly (RIP) and Liberty Mutual. 

* actually, the questions are more accurately: “let’s use AI to improve the experience…” rarely is it “will AI improve this experience?” but I digress.

AI is going to be transformative. And it is coming for every sector. Consider customer service:

“Gartner predicts that by 2025, 80% of customer service and support organizations will be applying generative AI technology in some form to improve agent productivity and customer experience (CX).”

— 2023 Gartner study

I think it’s fair to ask however: “Will users find a customer service experience powered by AI better?” More succinctly: “Do users want to talk to a chatbot?”

Generally, users don’t want to talk to chatbots. Today. Chatbots will get better over time and the friction and sour feelings they create today will minimize (though probably not disappear). Will chatbots in the future pass the Turing test? I have no idea (and I appreciate it when companies don’t try, such as Slack).

Whatever the answer, I think chatbots are the least interesting application of AI from a user experience perspective.

Better UX through AI

Yes, AI can make a chatbot interesting. Go play with ChatGPT  for a bit. It’s fun and with some practice (i.e. learning to think like the computer) you can get it to spit out some really creative and interesting content. But that’s the end of the user experience, isn’t it?

I think far more compelling application of AI will be when it truly adapts to humans, anticipating and solving user needs. In this dynamic, there’s no need for the user to tell the computer what they want (in whatever language) because the computer is already working to address the need.

• Imagine AI rescheduling a doctor’s appointment because of a conflict in your schedule that has come up?

• Imagine booking travel to a new city and AI building an itinerary of activities and restaurants based on you that consults your schedule without being asked?

• I recently shared this post on generative UI where AI transform’s an app’s interface to suit the specific needs of a user based on their behavior and interests. AI to transform every interface so it’s adapted to you sounds pretty compelling.

• At Drizly we discussed an AI feature that would take a results page of various wines that would select specific bottles and generate a brief description, all based on the user’s taste preference, finding relevancy through the noise (unfortunately we never got around to building it).

• Seven years ago I wrote about the Starbucks app anticipating my morning order and placing it without me having to tell it to (I didn’t mention AI, but this theme holds - technology working for us and not the other way around).

IN CONCLUSION

Each of these AI examples are all relatively possible today, and I think offer a far more compelling user experience than a chatbot. With AI, let’s focus on user outcomes and design interactions that will provide rewarding experiences for real people.

We work for our apps. That's backwards.

Discover & share this Tom Cruise GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

We design apps wrong. They’re supposed to help us, right? Make our lives easier, complete tasks for us, simplify things. But that’s not quite how they operate. They require us — users — to help them — our apps — complete the tasks we ask them to do.

Morning ritual

Consider your morning commute. Do you drive? Walk? Bike? Whatever mode of transportation, the routine is likely fairly consistent. You leave your home at roughly the same time each morning. You follow the same path each morning. You arrive at work at pretty much the same time each morning.

My morning commute includes a walk through parts of Boston, ending up in Back Bay. And every morning, five days a week, I stop at Starbucks before getting to work. I stop at the same Starbucks, at roughly the same time, and order the same drink. On my walk I place a mobile order via the Starbucks app so my drink is waiting for me.

These are the steps I take to place my order:

1. Open the Starbucks app.

2. Press the floating action button.

3. Press the “Order” button.

4. Select my saved drink choice.

5. Press the store selector.

6. Choose a different saved Starbucks location.

7. Press the “Review Order” button.

8. Press the Continue button.

9. Press the “Order” button.

I documented these steps and screens in a Medium Series here.

9 steps. I must complete 9 steps for the Starbucks app to order me the same drink I order every day, from the same store, at the same time. Seems like I’m doing a lot of work to help the app help me.

We work for our apps. That’s backwards. They should work for us.

A better experience

What should happen? A thoughtfully designed app, meant to truly help users, would recognize behaviors and adapt to support them. As I approach the Starbucks from which I order every morning, the app should prompt me. It should proactively ask me if I want to get my usual. Something like this:

“Ken, I noticed you are approaching your regular Starbucks. Should I place your drink order so it’s ready for you?”

Wouldn’t that be a way better experience? The app helping the user, automating repetitive behavior, instead of requiring the user to tell it what they want in exact detail as if you haven’t done so 1,000 times before.

Make it happen

So how do we make that real? I suspect the app would need to know 4 things. And once all criteria are met, the app could prompt you magically.

It would need to know:

Location. The app would need to know where you are so that it can identify when you’re close to a Starbucks. Luckily all smartphones come with GPS.

Drink order. The app allows users to identify a favorite drink. Even better, it keeps a record of every drink you’ve ordered. It can figure this out without even needing to be told.

Preferred Starbucks location. Like your drink order, the app allows you to select a favorite store for convenience. And again, the app already records the location of every order you place. It can already discern your behavior.

Time of day. If you regularly order a drink at a particular time, it needs to recognize that. And again, there’s a record of every order you’ve ever placed.

Hooray! What the app needs to know — it already knows!

This proactive approach can greatly simplify the ordering process. What takes 9 steps today can be reduced to just one:

1. Would you like me to order your drink — Yes or No?

Much simpler.

Let’s all do better

I don’t mean to single out Starbucks. They make a pretty good app. Their mobile ordering feature saves me about 10 minutes on my commute, having the drink ready for me versus having to wait in line, pay, and then wait for my drink. As I’ve said, I use the app every day.

But we can do better in how we design apps. Let’s craft them in such a way that they truly support and aid the user, not be just merely dumb apps that need to be manipulated/managed by the user.

Agencies sell their clients the wrong thing

I have a lot of experience working for agencies. Over 10 years’ worth, in fact. I have a lot of thoughts about the business — the people, the clients, the work, etc. Something I’ve thought a lot about recently is what they sell to their clients.

Agencies don’t sell a product, typically, but rather hours. Sure there is often a website, a campaign, a mobile app that is produced and handed over, governed by a contract that specifies what deliverables will be created. But this is a poor substitution of what the client is ultimately looking for, and the agency is hoping to deliver.

"I was surprised at how little value we provided clients"

“I was surprised at how little value we provided clients”

A while back, I grabbed drinks with an old friend and former boss who had gone client side after a long and successful career working and leading agencies. He had been in his new job for over a year. I too had gone client side recently and we were catching up and talking about the good, the bad, the same, the different of working in-house.

“When you’re in-house, what you do needs to demonstrate value. It has to be measurable.” This was what my friend said to me.

“I was surprised at how little valued we provided clients.”

His point was that for all the hard work we as consultants do — and we do work hard — the result for the client doesn’t provide for them the maximum value they need.

The problem isn’t talent. Some of the smartest people I’ve met work at agencies. And they can design and build just about anything you can imagine. The problem, I believe, is in what the agency and client company agree to do.

Rather, the issue is how agencies price and sell their services. The conversation about the value of a good design is a hard one. It asks client companies to compare two things (a well designed site and a poorly designed site) and appreciate the approximate values of each. That’s actually a hard comparison to make. How do you value good design? Can you easily quantify the improvement to a business of the “better” design weighed against the added time and money to build it? Especially when at the end of the day what you’re talking about are two sites that are (theoretically) functionally similar.

There’s a whole post to be written about properly valuing good design (and properly executing it). Suffice it to say, it’s hard to properly contextualize for a client the method and approach that allows one to craft truly tailored digital solutions.

How does this apply to agencies selling their services? We try to make the foreign concept relatable. We substitute what we’re trying to sell — a unique business solution to specific business problem — into something much easier to understand: a bucket of hours.

Client Company A comes to Agency X looking for a mobile app. Perhaps discussion is had on whether a mobile app is the right solution for Company A, but rarely that happens, and at the end of it all, Company A is still going to insist on building a mobile app. So Agency X, relying on their experience in building mobile apps in the past, puts together an estimate. This estimate assumes the specific roles needed to design and build and test the app, assumes the total number of hours everyone will need, multiplies that hour total by some arrived-at rate, and you have your project cost.

From there the estimate is debated. Internally account people argue Company A will be willing to spend that or won’t, and the number is massaged. Then Company A considers that estimate and pushes back and the number is massaged again.

To ensure that bucket of hours is being properly spent, specific deliverables are agreed to. Think of them as mileposts along the journey of the project. User journeys (number of journeys specified ahead of time) that Company A will approve. Wireframes (total max number of wireframes specified ahead of time) detailing the site that Company A will approve. Delivered code for the mobile app that will meet specific agreed-to functional capabilities.

The contract becomes the thing that both Company A and Agency X use for leverage. Company A uses it to ensure they’re getting what was agreed to ahead of time. Agency X uses it to ensure they’re not on the hook for work that wasn’t agreed to and therefore unpaid.

What’s missing in all of that is actually discovering and building what Company A really needs to solve the specific business problem/challenge. There’s no ability to course-correct/change approach if in diving into the work data/user research shows a different solution/strategy is needed.

That is not a failure of imagination or expertise, but the reality of solving problems. Company A’s initial diagnosis of their business challenge is rarely correct. The proposed solution — before any work is done — by Agency X rarely hits the necessary mark. It is only in doing the work, testing hypotheses, learning, experimenting, that the proper solution to a problem is revealed. But that exploration is not available to client and agency in a typical working arrangement.

This is how you get to the “so little value” provided to a company.

So what’s the solution? That’s a hard question to answer. More focus on how to solve a problem as opposed to a pre-determined solution is necessary. Agencies need to sell the flexibility of solving the problem. It’s in a company’s best interest for the solution to evolve as the work is undertaken so that an illusive and moving target can be hit. Most important, trust needs to be built between client company and agency so that both sides don’t fear being taken advantage of.

New agencies are starting to reject the old model detailed above and positioning themselves differently. They’re focused on selling design thinking — the method of discovering and addressing the problem, rather than selling a bucket of hours and a specific solution.

They look to partner with the client company, working side by side in doing the hard work of determining what is needed. Rather than sell big buckets of hours — projects that take months/years — they offer shorter engagements, usually a week or several at a time. This is a much more palatable entry way to a project, and allows both sides the flexibility to shift as learned insights suggest. Both sides continually learn, better understand the problem. Most valuable to the client company — they learn the ways of design thinking and are in better position to address other challenges that arise within their business.

This is a better value proposition for all parties. Ultimately everyone involved wants to build the better and right thing. Ensuring your selling — or buying — a process that allows for learning and course-correcting the solution is the best path to achieving that outcome.

UX Designer: an origin story

11 years ago I got my first job in UX. I was a relatively recent college grad with an English degree. The job was as an Information Architect at a small digital agency in Chicago called Tanagram Partners (pour one out for Tanagram; alas they are no longer around).

This was not my first real job. I had an account management/sales job for a large B2B tech retailer. I didn’t see that as a career. As a liberal arts major, I didn’t really have a specific career. I was still casting about for what I really wanted to do.

All I knew is that I did not want to do sales.

I didn’t know much (or anything) about UX. I had interviewed for a Project Management position with the agency and was runner up for the role. But I had apparently made a good impression on the owner, Joe. He brought me back in the following week and ran me through some exercise and thought experiments.

I evidently said something right.

I got a job offer. It was certainly unlikely. I didn’t fully know what an Information Architect did. But I began to study. A lot of my friends hadn’t heard of UX either. Keying on the last word in my title, one thought it very unwise to have someone with zero experience or training designing buildings.

Back then, it was possible to get into UX without any prior experience. It really was the wild west. Now when I hire for design teams, I review resumes of candidates with masters degrees in Human Factors and such, not just undergrad work (I still don’t think this level of education is a requirement, but that’s a topic for another post).

I had a (very) steep learning curve. I remember a few weeks on the job asking a developer why the page he was building was filled with latin text. But I kept at it, and I learned.

As I mentioned, I had an English degree. I graduated from a creative writing program. I had an artistic mindset (hopefully without the pretension suggested by that statement). At the same time, I came from a more mathematical-minded family. My dad is an electrical engineer with a masters from Northeastern. My mom is an accountant and tax preparer. My sister is an aerospace engineer.

All of this is to suggest that while my passion may be for creative pursuits, in my DNA I have a strong leaning towards the analytical. In UX, I found a career that supported both mindsets. I did fall in love with UX. It was only a short time on the job before I felt as though I had found my calling. And I do love UX. I’ve always been a problem-solver. I can’t leave things unexplained. And so with UX, I get to serve that desire. I solve problems for a living. And I can do that creatively. Awesome!

I worked at several agencies over the years since Tanagram. I’ve had the opportunity to work on some big and crazy projects. I’ve helped design and build a number of ecommerce sites for big-name brands. I’ve build a score of mobile apps across various industries. The opportunity to work on so many different and complex projects is another aspect of why I love UX.

Changing landscape

Back in my early UX days, companies outside of agencies didn’t really have UX designers. All of that was outsourced. And usually we spoke with the IT side of the house. If you followed up the chain of command, you’d usually arrive at the CIO (if it was a big enough company).

Some time in the intervening years, that shifted. We started working with the marketing side of the business. And then with the actual business people. This progression of whom we work with suggests the interesting evolution of how UX has served companies.

When working with IT, we were helping to build the infrastructure. The digital platform that was becoming necessary for any and all businesses. As we worked with marketing and advertising departments, we were helping to build the system of promoting the business and the products and services they sell. And now we’re working with the business to help actually shape the way the company makes money.

What’s next

UX designers are being asked to do more than make something usable. The basics of that are pretty well understood (and generally applied; with a lot of room for improvement). Applying design thinking — developing useful solutions to customer needs — to a business’s approach is the current trend. Companies understand that differentiating on customer experience is how to capture market share.

It’s a very different type of problem I was often asked to solve early on in my career. Back then I had to figure out where to put all of the pieces. Make it logical and hopefully intuitive. Now I’m tackling core business challenges.

I’m a long way from that sales job and not knowing what lorem ipsum is.

Don't be a tech company

An observation: startups quickly forget their reason for existing and replace it with a different reason: be a cool tech company.

And this is likely why so many fail.

Let me explain. All companies likely start with a true and meaningful purpose. They have a problem they want to solve. Something they observe that is broken, or doesn’t exist and strive to fix it. Quickly we move to solutioning - and that’s when an app or website is built. And then that app or website is added to. And then improved. And then the Android (or iOS) version is launched. And all discussion is about making the app better, more fun, sticky.

The company is now a tech company. It’s product is an app that does something or another. We’ll test our app and make it better. And wait till we get to a complete redesign; that’ll be something.

I was thinking about this while listening to an episode of the StartUp podcast that looked at Startups after they shut down. The episode included an interview with Jason, from Bento. Bento was a food startup that provided quality meals on demand, ordered via an app. That business didn’t work out, though the company added a catering service which proved workable.

Asked what he had learned about his business, Jason states that his original business idea - on-demand delivery had “a zero percent chance of success.” It was unworkable. But Jason went further:

Had I started with the catering business I could have made that work, but that wasn’t a business I was interested in running.”

 

Solutioning is more fun than problem solving

I’ve worked with a number of brands. We’ve built a lot of digital products. Websites, online services, apps. Ostensibly these have all been for the improvement of a company’s customers. Or to attract new customers. And those companies spent a LOT of money on that work.

Some of those products worked. Some did not. Some were successful to a point. We did do user research in most of those cases, to a point. But the client - and my team - fell into the trap of loving our solution, what we were designing and building. We were beholden to our desire to build something cool and exciting.

And so we designed screens we thought were necessary. And then replaced them with other screens we designed when we felt they were better, or covered a business rule we felt was necessary.

We did this earnestly and with the best of intentions. But our focus always shifted to what interfaces we needed, what we could add that we thought would help. The purpose - beyond the screen - was always in the vaguely in the periphery.

 

My great startup idea

(umm, that's sarcasm)

My point is not to criticize others. The pull of designing the screen over other things is strong. I know, I succumb to it often.

I’ve had an idea for a startup for a while, and have doodled on it over time. I share it here to illustrate my point, and the realization that while I day dream about it, I haven’t taken steps to make it real.

My observation/problem I want to solve: people hate to order food by phone. As a society, we don’t want to talk on the phone. And when ordering food, there’s a lot of pain and frustration in the ordering experience - bad connections, being put on hold, attempting to customize a specific order, etc.

Some restaurants enable online ordering. Usually this is done by 3rd party companies. And they’re often 1:1 relationships; an app for a restaurant. The ordering experience is lackluster. Passable might be an appropriate description.

My idea: create a platform that any restaurant can sign up for online. Users download a single app that is an enjoyable experience and are able to order delivery or takeout for any place.

I’m not claiming I’m the first to come up with this idea. Obviously there’s a bunch out there - Seamless, Grubhub, BeyondMenu, DoorDash, etc. While a lot of food apps attempt to solve for the delivery part of the experience - getting food to the user - I’m not interested in that part. The specific problem I want to solve is the ordering. Better experiences are out there.

(Whether my idea could be turned into a workable business model is unknown)

Here’s a wireframe I created for my app. I’ve worked on this and other screens for a while. But what occurs to me is my focus has been on these screens. I’m trying to design the app. I’ve taken no real steps to validate my hypothesis. Is there a problem with ordering food by phone? Do users want a different approach that is easier/enjoyable?

I’m designing the screens. I want to be a tech company.

 

Don’t be a tech company

As a general rule, the technology should be secondary. Building a startup (or anything) should mean focusing on the problem and always trying to solve that. The technology should be a tool, a piece, but not the point. Focus on the industry/problem you’re trying to solve, and not on the screen/app/digital thing that helps service that problem. That’s what your company should be.

Not a tech company.

No UI is a good thing

Pocket Pond is an iPad and iPhone game that is exactly what it’s name implies: a pond — with fish and lily pads — that lives on your Apple device.

I came across this app recently while waiting for a doctor to insert an IV into my 22 month old daughter. Lucy is fine, a little scare and a long day, but ultimately all better. The nurses loaned us an iPad to entertain her and Pocket Pond was loaded on it.

The game involves users “touching” the water surface. It disturbs the fish and they scatter. There’s a pleasant sound of water splashing as users interact with the app. Lucy loved it. It occupied and entertained her while we waited hours.

It is a very simple game. But what I found interesting about it was the app had almost no UI. The entire screen was filled up by the pond and that’s what you interacted with.

I’m a UX designer. I’ve designed a number of apps, websites, large-screen displays. We are always focused on creating the UI. How do people interact with it, control it, understand what’s possible. To our detriment as designers, the UI is immediately what we focus on. Pocket Pond has none of that. It just is. It’s skeuomorphic design is exactly the point.

Petite démo de Pocket Pond HD pour iPad

Wherever you touch the app, the water is appropriately disturbed. That is the interface. And it supports multi-touch so touching with just a finger produces a different result than touching with all five or your palm. It “feels” real.

Important to the experience is the sound. The sound is both what one would expect, and soothing. The sound helps create the immersive experience. Playing the game without sound provides a lesser, duller experience.

 

So what’s the point?

The game is certainly simple in what it wants of users (see the part where my young daughter was highly entertained). But that simplicity allows for something interesting to occur.

My daughter experienced real joy with the app, and unlike every other app on my phone, she could play it without unintentionally ending the experience or going down a path that locks out the game (e.g. opening a menu, selecting an alternative option screen, etc.).

And I actually found the game refreshing and oddly entertaining. Immersion can be a powerful experience. There is real opportunity in building apps in this way, or at least incorporating this experience into a larger platform.

I think three things overlap and work together to create this experience:

 

No UI

The lack of UI is a benefit. I don’t need to understand how to use the app because the experience as presented is it’s whole purpose. Just interact with it. You can’t create an error. How do you create an error with a pond?

And this leads to…

 

Immersive

Without the UI to get in the way, the user is that much closer to the “pond” experience. Sound, as noted above, is also extremely important. They work together to bring the user into that world. It is surprisingly powerful.

 

Fun for it’s own sake

The app has little to no purpose other than to replicate a pond. Users find joy in that (or don’t). There’s no effort to make the user do something, to progress by completing tasks.

 

Conclusion

There is a notion that mobile users are task-oriented. They want to open an app, complete a goal, and move on. At the same time all of us are spending increasingly more time on our phones. Might there be an opportunity to build more engaging apps that eschew UI and focus on immersion? Pocket Pond aspires to be little more than the simple game of splashing water and scattering fish. But this approach seems to be rich with experiences that could be more rewarding. And experience in and of itself is a worthwhile end goal.

I would certainly enjoy more apps like this.

How do we make decisions?

Over the weekend I saw this tweet from Andrew Wilkinson:

Does this exist: An app that runs you through a checklist to help make a decision (a hire, a strategic move) then logs it to review later?

— Andrew Wilkinson (@awilkinson) May 20, 2017

I love this idea. It connected to me in an unexpected way. I've been spending a lot of cycles thinking about decision-making. Over the past few years as a UX lead - first at Sapient and now at DraftKings - I've helped shape team structure and process. I'd grown into this responsibility as I progressed in my career. But no time was spent training me on how to build process. Sure, I have experiences - been in good situations where the team delivered exceptionally and bad situations where the projects was a shit-show from top to bottom - but that's not a study of process.

Also, to some extent I distrust experience as a way of making decisions. This is for two reasons. First, I haven't had all the experiences there are to have. In terms of experience I'm missing pieces. So how can I build a process based on only what I've seen? Second, I've seen others make bad design decisions based on their experiences. Choices I would not agree with based on my direct experiences. So if I see others making bad decisions and they don't know better, why would I think I'm not doing the same thing.

So I'm thinking about decision-making as a repeatable process where, if followed, I can be as sure as possible that I'm generally going about it the right way. Which is why Andrew's tweet struck me as interesting. Is there a way that decision-making can be defined clearly enough to ensure a good (or more likely good) outcome?

I think so. Though I don't know what that looks like at the moment. Responses to Andrew's tweet suggested several apps/sites out there that offer help, though I found the approaches they take lacking. In some form or another, they treated making a decision as a simple math equation. Input relevant facts, weight them, the app spits out an answer. That doesn't feel right. That doesn't feel like how decisions are made. They can't be reduced to simple either/or statements. I think evaluating and contemplation are necessary parts.

I'm going to think some more about this idea. I think it's interesting, and valuable. I need to work through what this service might look like.

UI & UX: The Toaster Oven Problem

A toaster oven is a good idea in theory. One kitchen appliance to make toast and cook things. It’s a space saver.

But a toaster oven doesn’t make toast as well as a true toaster. It takes longer to toast and the bread usually toasts unevenly. And the oven part… well you can’t really cook things in it. It’s pretty small. And not nearly as powerful as actual ovens. It basically can warm things up, though this takes longer than another kitchen appliance: a microwave.

A toaster oven isn’t the best tool for making toast. Nor is it the best tool for baking. It doesn’t do any one thing particularly well. But it’s a space saver.

Which brings me to UI and UX. UI — short for User Interface design — focuses on the visual design of a screen. It is the digital “thing” that a user will interact with. UX — short for User Experience design — focuses on the experience in total for a user. It is about how to make completing a task easier, more intuitive for a user. These are not the same areas of focus.

This is how Golden Krishna, author of The Best Interface is No Interface, recently described this difference on the Intercom podcast:

“UX slash [sic] UI roles… they aren’t the same thing. When you’re a UI designer you’re there to compose a great screen and when you’re a UX designer you’re there to understand and solve problems. When you conflate the two you make it so people try to solve problems with screens.”

Krishna’s exactly right. UI and UX look to solve different problems using different approaches. UI is singularly attentive to a single space (the screen) and so must confine its solutions to that arena. UX is obsessed with the user and so may consider the screen, but also think beyond, wherever the research and insights take them (environment, flow, objectives, etc). How one approaches a problem will dictate the solution. Or to use an analogy — when you’re holding a hammer, everything starts to look like a nail.

Can a single designer inhabit both roles? As one who’s interviewed a lot of designers — UI, UX, and UI/UX — I am dubious. More and more I see designers marketing themselves as being both — the holistic UI/UX designer. And there’s a certain logic to it. A UI designer necessarily must consider the UX of the screen when working. It seems on the surface a harmless stretch to suggest one has UX ability as well. Certainly you look more appealing on paper and also open yourself up to more potential opportunities.

If you tell me you're a "UI/UX Designer" I'ma stop you right there... #UX

— Ken Sigel (@ken_sigel) May 2, 2017

In interviewing such candidates, I find the a few perfunctory questions about process and how the designer addressed a particular project usually reveals immediately what side of the fence they truly belong. And what I find usually is they have passible ability in one area, better than average in the other. Never have I found a candidate to be exceptional in one area, and ok in the other.

A truly great UI designer states unequivocally that they specialize in User Interface design. He/she leads with their greatest strength. The exceptional UX designer does the same. It is the mediocre designer that claims mastery of both fields.

The toaster oven problem.

Companies deserve criticism for this issue as well. Job boards are filled with postings for UI/UX designers. Generally, these illustrate the company’s misunderstanding of the two roles. But hey, 1 salary for two roles! Ultimately both roles receive short shrift for the sake of expediency.

Now, it is certainly true that, while rare, there are a few exceptionally talented individuals who can serve both masters: UI and UX. But I have not seen a company yet willing to pay what that unique combination of talent is truly worth. Companies devalue the worth of designers in this manner.

Let’s recognize that UI and UX are different things. They are not skills that exist on the same spectrum. Rather, they intersect. These roles should be properly maintained by two separate designers.

And now for something completely different

Well, I’m making a (kind of big) change.

After 10+ years in the agency world, I’m moving to the product side of things. Starting next week I’m going to lead UX at DraftKings.

I’m really, really excited about this opportunity. I’m also pretty nervous about it too.

FIRST… GOODBYE TO A GREAT PLACE

For the past four years, I’ve called SapientNitro my (work) home. It has been a great company to work for and I’ve had the opportunity to work with many big name brands on challenging and consequential projects. I’ve learned a lot about design. Hell, I even owe being back in Boston to Sapient. I was living in Chicago at the time I met with their recruiter. My wife and I wanted to move back; Sapient made it happen.

Most of all though, I’m going to miss the friends I’ve made, both current and past coworkers. The people at Sapient are a passionate, talented group of people who are just really good, fun people to hang with. I’m going to miss seeing them every day.

A CHANCE TO BUILD PRODUCT

The biggest thing about this change is getting to focus on a single product. Learn what users like, what they don’t, always focused on improving. DraftKings is already a widely used and really successful app. The prospect of working on this with other really talented people, striving to improve, evolve it, is incredible.

A few years ago I had a chance to “build product” on an internal project at Sapient. I wrote about some of my experiences and learnings here. We did a lot of things wrong on that project. But it was a demarcation point for me, as it got me thinking constantly about product design and process. First, I had loved working on a single product and working to make it engaging. Second, I began to appreciate how much process and and methodology impact the outcome, over pure talent and hard work. Or to put it differently, how you empower and direct talent and hard work are huge factors for success. Now I get to focus on these things full time.

BOARDING A ROCKET IN FLIGHT

DraftKings has been around for just 4 years. They already have millions of daily users. I’m joining a team that has done an amazing job building a product that a lot of people want — and are passionate about — in an incredibly short amount of time.

I’m really excited about joining this rockstar team. And while everyone appreciates the success they’ve achieved, they also want to improve, to learn, to get better. That inspires me. To find a group of people committed to always be improving. I am going to learn a lot from them.

A SCARY PROPOSITION

DraftKings is hugely successful. I better not fuck that up.

I confess that I am nervous about this move. It is doing something different from what I have been doing. It comes with a lot of responsibility and a lot of challenges. What if my ideas or approaches are wrong?

I am joining a successful and talented team (see above) and I trust that together we can figure out the right moves and make good decisions. And also learn from the wrong ones. Still though… butterflies.

BUILDING A TOP-FLIGHT DESIGN TEAM

One of my tasks will be to build and lead the UX team. There’s already a great foundation. This is an awesome responsibility. I’ve had experience building and training the team at Sapient, but this is going to another level. It’s a huge ask. I’m excited; nervous (again).

So if you’re focused on UX in Boston and want to work on an important product, reach out. Let’s build connections and get to know each other.

So now I move to DraftKings. I can’t wait. I am invigorated by the challenge and opportunity. I don’t know what’s in store for me on this journey, but I’m sure it will be an incredible ride.

---

This post originally appeared on Medium here.

Cult of personality (testing)

Question for creative directors and other design leads: do you use personality tests as part of your hiring process?

On a recent “Seeking Wisdom” podcast* about how to hire talent, David Cancel stated that he has candidates (and employees) take a personality test when joining his company, Drift. Specifically, he mentioned a free online site called 16Personalities.com.

*He starts talking about personality tests at the 17:00 minute mark.

When I heard this, I first hot take: “I get it, but it sounds a little creepy.” No one wants to be defined by the results of some test psychologists (or not) made up. I’m more than the results of some multiple choice survey.

But I continued to think about it. As a creative director and team lead, I recognize implicitly that I can’t manage everyone exactly the same. People respond to different management styles and interactions. I view it as my job to learn what style works best for each individual and adapt my approach accordingly.

I think back to the teams I’ve lead over the past few years. I’ve had both extremely extroverted designers and others that were quite shy. Some do well in a group setting where ideas are being explored and others I could get more out of with 1:1 discussions about the work. I would always encourage discussion from those that would sit quietly (and sometimes get the more outspoken members to dial it back a little). What I’ve learned is that the work is greatest when the team collectively contributes. So I have tailored what I say and do to each person working on my team.

*for a great long read on team dynamics and better production, check out this NYT Magazine piece about Google’s research into how to build the perfect team.

And this is Cancel’s point. To be an effective manager, you have to recognize that each designer, developer, etc. is different; manage appropriately.

So I took the 16Personalities.com test. This was my first time taking such a test.

My result is ENFJ-A

16Personalities.com labels me as a protagonist personality.

“Protagonists are natural-born leaders, full of passion and charisma.”

I confess, I feel like sharing that is a bit of a humble brag. But the takeaway is that I felt the description was true about me (though I don’t think of myself as extroverted as the result suggests… ok THAT was a humblebrag).

The result was for me indicative of my personality (or so I think). And if that’s the case, it can possibly point the way to other testers. And information like this is helpful in managing people.

my test results

I don’t think a manager should consider the result of a personality test as ironclad. New information and insights about a person and their behavior will always be forthcoming and a good leader needs to recognize that and continue to evolve their approach. I don’t know that I like the idea of using the test as deciding factor in hiring. But I do think it can help the manager better manage people.

So back to my original question: anyone out there using personality tests in hiring?

At my company — a large, global agency, I don’t think the lawyers that be would allow me to incorporate this tool (to be fair, I’ve not asked). I suspect anyone I brought this to would stop at my own initial thought. But I think using such a tool in the proper way, and properly weighted (which is to say, not definitive), it could be a valuable tool.

What does everyone else think?