The town square fallacy: why social platforms built for everyone lead to bad experiences.

February 3, 2025

You don’t encounter a lot of Nazis on Pinterest. You have to go to X for that.

Strolling through the comments on a typical Pinterest post you’ll see questions about where you found such and such an item, positive responses about how sweet something is, and other such warm feedback. The comments in response to a viral X post is less uplifting. I probably can’t share here what’s often typed out.

It’s clear that users behave a certain way on Pinterest and a completely different way on Twitter X. What product decisions were made that led to such divergent user behavior? Or perhaps this is a corollary to Godwin’s law where if you gather enough people online in one place, the Nazis show up?

Pinterest has 522 million monthly active users (MAU) and X has 650 million [include links to sourcing on MAU]. Both platforms share a lot of core functionality: Both platforms are designed to post and share content (Pinterest is primarily image-based while X is primarily text-based). Users can browse, search, like, comment, share. Both platforms rely on ad revenue for monetization and so want you to spend as much time on their site as possible.

Pinterest states their mission is “to bring everyone the inspiration to create a life they love.” Their platform is designed to allow people to “search, save and shop the best ideas in the world for all of life’s moments.” They have a specific audience that they target and that audience shares a common purpose.

X (and Twitter before the name change) has famously stated that they want to be the digital town square for the world. The first sentence of the official X Rules states: “X’s purpose is to serve the public conversation.” This is a broader audience and a much broader purpose.

So this is the challenge I see platforms face: the broader their intended audience, the more toxic they tend to become. Platforms succeed when they are designed for specific audiences who share a common purpose.

Design for community

The Stanford Encyclopedia of Philosophy defines social norms as:

…the rules of a group of people that mark out what is appropriate, allowed, required, or forbidden for various members in different situations. […] Once a person adopts a norm, it functions both as a rule that guides behavior and as a standard against which behavior is evaluated.

When there’s a sense of community, which arises from aligned purpose, norms evolve and they become self-enforcing. I believe this is the force at work with Pinterest and absent from X. Platforms that try to attract everyone, that fail to provide a unifying purpose are places where community norms struggle to form and take hold. As such assholeish behavior crops up and there’s no norm to quell it. X becomes a hellscape without healthy social norms. Pinterest is a sunny place because social norms take root. I’m willing to wager that there are Nazis and other assholes on Pinterest, but social norms keep them from behaving thusly on the platform. They play by the rules on Pinterest. They act brutishly on X.

Design as Governance

So how does a platform design for community? It starts with the realization that design is governance:

“When we create designs, we’re basically defining what is possible or at least highly encouraged within the context of our products. We’re also defining what is discouraged.”

It’s easier to do this when you have a clear understanding of desired behavior, as well as an audience that shares a common goal or unifying interest. Too wide open and it’s near impossible to craft the guardrails that will shape those norms.

There is an axiom that states “to design for everyone is to design for no one.” If your product aims to please everyone, it becomes so generic that it appeals to no specific audience. This hurts the formation of community, and thus social norms for your platform.

The design choices we make influence the behaviors of its users. It’s easier to do this when we have a clear audience and set of behaviors we want to encourage. Conversely, if we design for the broadest set of users and purposes, that influence wanes. Chaos ensues.

LinkedIn vs. Facebook

Consider LinkedIn and Facebook. LinkedIn has about 1.15 billion users worldwide. Facebook has a little over 3 billion. Yes FB is a lot bigger, but both are massive in size and user base. Both are global in their reach.

According to their official Professional Community Policies, LinkedIn wants to “reflect the best version of professional life. This is a community where we treat each other with respect and help each other succeed.” That is a specific purpose for a specific audience. The posts you find on LinkedIn — and the comments they generate — comport with this view. For the most part, people present a version of themselves that is more professional. You do not find the vitriol and toxic behavior found on other platforms.

Similar to X, Meta (Facebook’s parent company) wants to be the digital public square. They want the broadest possible audience and be the place where everyone is talking. Their community guidelines state: “Meta wants people to be able to talk openly about the issues that matter to them, whether through written comments, photos, music, or artistic mediums, even if some may disagree or find them objectionable.” The Facebook experience certainly lacks the professional one you find on LinkedIn.

The toxic behavior found frequently on Facebook does not show up on LinkedIn. In fact, I’ve seen LinkedIn users chastised for posting even the positive types of posts you find on Facebook; when those posts aren’t of a professional nature and topic. Social norms exerting themselves.

Content Moderation and free speech

I should add that all four of the social media platforms discussed in this post have similar guidelines in terms of what types of content is and is not allowed. No nudity, no harassing or threatening messages, no calls for violence. By the strictest reading of each platform’s guidelines, the same content should be allowed on all of the sites, and the same content forbidden should not be allowed on all of the sites. The wildly different experiences across the platforms is not the result of different content policies.

And this isn’t about free speech and the first amendment, which is so often invoked when discussing behavior on social media platforms. The First Amendment prohibits the government from choosing what speech is acceptable. All of these are private businesses; each decides for themselves what they will and won’t allow on their platform. Our “free speech” on any platform is at the discretion of that company’s governing body. Their platform, their rules.

Design as a community catalyst

The platforms we build are more than just digital spaces — they’re social architectures that shape human interaction. Pinterest and LinkedIn demonstrate that specificity isn’t a constraint, but a powerful design strategy. By creating platforms with clear intentions and well-defined audience purposes, these companies have proven that meaningful online communities aren’t accidents — they’re intentional designs.

The lesson for product designers and technologists is clear: every design choice is a governance choice. When we create social media platforms, we are not just building interfaces; we’re establishing social ecosystems. The guardrails we put in place, the behaviors we encourage or discourage, and the specific audience we target fundamentally determine the quality of human interaction that will emerge.

As we continue to build the next generation of social media platforms, we must eschew the idea of a universal audience. True connection doesn’t happen when we try to include everyone — it happens when we create spaces where specific communities can thrive, where shared purposes create natural, self-reinforcing social norms.

Designers: your primary value is not representing the user

January 27, 2025

Photo by Jonathan Cosens Photography on Unsplash

Tim Brown of IDEO didn’t get it wrong when he detailed where Design Thinking sits (and by inference, the role of design). We all just misunderstood the framing.

Just about every product company out there organizes itself in some version of the 3 legged stool model: Product, Engineering, and Design. Three disciplines that come together equally (emphasis added) to make decisions about what to build and how to build it. Design thinking is meant to sit at the center.

Desirability represents Design: Is this something users will like?
Viability represents Product: Can this be turned into a sustainable business model?
Feasibility represents Engineering: Is this something we can build practically?

By inference, design is meant to represent the voice of the customer. “We speak for the user.” (please, designers, I’m begging you — never say that). That is the shorthand we’ve fallen into. If that’s our value prop, we have the weakest of the three. Or at the very least, the value prop a company can set aside or minimize.

Engineers have to be able to build the thing. No one else can do it. By virtue of having the unique skill set, they cannot be ignored or sidelined.

Product managers frame everything in the context of business impact. They run the numbers. They are always making the case for something on the merits to the business.

Designers understand the user. That is important, certainly. But it is also the weakest case for the proverbial seat at the table. It is advisory. It is not strategic. Additionally, designers aren’t the exclusive owners of insight into user desire and behavior. PMs and engineers also have some understanding of what the user wants. After all, they too are focused on building a product to suit an audience.

The real value prop of design

It is perhaps a bit insulting to argue that non-designers have no understanding of the user. It’s simply not true. They may not have the rigorous approach to understanding that designers (should) apply. But there is some understanding. And that’s a good thing. User insight should not be solely owned by designers. Understanding the user is information that should be communal, shared across the company.

I don’t think Tim Brown was suggesting only designers know this information. And the focus of that diagram is the center — in the middle of those 3 forces. Design thinking. And this, more than understanding customers, is the strength that design brings to an organization.

In presentations I give on the role of product design, I have a slide that includes the IDEO diagram and describes our role as the process of identifying and solving user needs for the benefit of business.

We identify problems and solve them to deliver business results. We lead the way on tackling the right problems to return value to the company. That is the true value prop of design.

The management consulting firm McKinsey & Co. has developed the McKinsey Design Index (MDI) which tracks the performance of design-led companies. They have concluded that these companies greatly outperform their competitors, regardless of industry. It is a serious differentiator.

We found a strong correlation between high MDI [McKinsey Design Index] scores and superior business performance. Top-quartile MDI scorers increased their revenues and total returns to shareholders (TRS) substantially faster than their industry counterparts did over a five-year period — 32 percentage points higher revenue growth and 56 percentage points higher TRS growth for the period as a whole.” — The Business Value of Design, McKinsey & Co.

Design delivers business results

I’ve deployed my design teams to numerous situations that on the surface didn’t require what is normally thought of as design work:

Customer service call center that was looking to reduce average time issue resolution.
Foundational backend work on a critical lead generation tool (all dev work, no front-end).
HR team looking to modernize their processes and improve eNPS
Finance team looking to develop new workflows to better handle increased workload.

My teams were helpful because they have critical skills that matter to the business. They know how to identify and define a problem, they know how to develop solutions to solve that problem, and they know how to align individuals and teams to tackle those problems.

These are the core skills of designers everywhere and the real impact they bring to companies. So much more powerful than saying: “we speak for the user.”

Design is the last thing you should focus on when starting a design system

January 21, 2025

I confess that I don’t care all that much about the corner radius on buttons, but this was the third discussion that week on the subject. Me and a team of talented, passionate product designers were sitting in a conference room, discussing some of the most basic components needed for the design system we had just begun designing. We were trying to build consensus around the initial batch of components. And we couldn’t get past the corner radius on buttons.

This was how the enterprise design system for Liberty Mutual began. It was an inauspicious start. It would take a lot of restarts and revisions and bringing in outside experts to give talks and trainings before we got to a point where we had a first version of the design system live, deployed, and used by most (but not all) engineering teams across the digital org. Our big mistake, the one I’ve seen committed at several organizations, is that we were focused on the wrong thing. We focused on the design of the thing when we should have been focused on process.

Why design systems

It should be apparent to every product team out there why they should build and maintain a design system. The benefits are clear: design consistency, development efficiency, scalability, accessibility compliance, and elimination (mostly) of design debt. The investment in building and adopting a design system are quickly recouped and supercharge the team’s ability to move quickly and effectively. But the initial effort can be daunting, and a team can quickly find the effort stalled. The team can find itself going round and round on things with little to no progress. It’s understandable when the team finds itself here that the organization decides to postpone the work. Hold off until the team has more time to tackle the work, start fresh.

The effort has most likely stalled out because you’re focused on the wrong thing: design. It’s counterintuitive but the design part of a design system is less important than the establishment of a design system and its adoption. Mature designs can come later. Getting a first version live is your goal.

With that in mind, here are three rules to keep in mind when starting a design system.

Engineering buy-in and advocacy is critical

A design system is the marriage of design and code. That’s it in the simplest of definitions. In that room at Liberty Mutual discussing button corner radius we had no developers. We had told them we’d get a first pass of base components and get back to them. We had effectively sidelined them. Similarly, when I was at DraftKings and we were starting our design system, we had begun it as a side project amongst the design team. We’d put something together and then show engineering and get buy-in. We didn’t get very far.

A design system without code is a style guide. And while that has value, it doesn’t bring you any of the benefits of a design system. Start with your engineering team. The benefits of a design system are as much for the engineering team if not more than the design team.

Additionally, you need them to build the components and then use them. Identify those within the engineering org that will support the effort, and advocate for it. They’ll be more successful than designers convincing other engineering teams to adopt the design system.

Perfect is the enemy of good

Once you’ve gotten engineering support and you’re getting to the hard work of designing components, remember one thing: the actual design doesn’t matter.

Well, maybe that’s an exaggeration, but it is absolutely true that you should not let perfect be the enemy of good. The faster you get a design system live and adopted, the better off you will be. Holding it up for additional rounds of exploration and revision of the design is not worth it.

I did not care for the first version of the design system we built at Drizly. It lacked polish and was somewhat overwrought. It led some clunky interactions across the mobile and web platforms. We struggled sometimes to make the different components work together from a design perspective. But getting it live was more important for us than making it exceptional. And that was the right focus.

Over time we would strip the designs down and ultimately elevate the design. We would try new styles and deploy them quickly. We were able to tinker and experiment more effectively once the design system was live. If we had done this in the opposite order — perfect the design before going live — I don’t think we would have succeeded.

And this is an important thing to keep in mind as you’re working through the designs: your DS is a living thing. It will go through iterations, small and large. The design you launch with is not where you’ll end up (another benefit of design systems!). Having it live and in the hands of the product teams throughout your organization will greatly improve your ability and cycle time of experimentation.

Lastly, I’ll add that with new design systems, design teams sometimes struggle working with the components. They don’t fully work for all the scenarios. That’s normal. It takes time to understand how best to assemble the pieces, perhaps the need to sand down some edges and figure out new ways to put them together. This design exploration — with real DS components is an important step.

Process over pixels

Above all, focus on process. How will requests for new components be handled? What criteria will be used to determine if the request will be satisfied with a one off component, or the adoption of a new component? What is the method for making changes to new components? How will you monitor adoption? Who will be responsible for designing and building new components? What sort of governance will you put in place and how comprehensive is it?

At Liberty Mutual we really started making headway when we began mapping out the rules of the design system. We hired a product manager (design ops) to focus solely on the design system and the processes around it. We also hired an exceptional principal designer to head of design and work with the various design teams to help them understand the DS and think systematically in component development. We were investing our time and energy in the processes that mattered for design systems to thrive.

Think about your processes and governance. Here’s a great post by Brad Frost on the subject. This, more than beautifully designed components will power your design system adoption.

In conclusion

Start with process, not pixels. Build strong engineering partnerships before you perfect your components. Focus on adoption before achieving design excellence. And most importantly, remember that a design system is a living thing that will evolve far beyond its first iteration. The time you invest in governance, processes, and cross-team collaboration will pay far greater dividends than hours spent debating design details. Because ultimately, the most beautiful design system is the one that actually gets used.

One thing designers can do to become more effective at work

January 13, 2025

A few years ago a designer came to our 1:1 upset. “What’s wrong?” I asked him.

“You know the product pages I told you we’d be launching today? Well they’re not quite ready. They’ve been delayed and it will be a few more days until they’re ready.”

We were replatforming our entire website and working against a tight deadline This was in the middle of the project and the pressure was high. So I enquired what was causing the delay.

“Chris [the engineering manager] was running last minute QA and he noticed some things were off — odd line breaks and font changes, CSS stuff. All minor things. He reached out to me and we’ve been working through it together, but there’s a lot of little things to work through and it’s taking a little longer than expected.”

My designer was genuinely bummed about the delay. However, I was quite pleased about this. This behavior is exactly what I was hoping to see develop. And it took a while, but we got there.

What was important to me hearing this story is that the engineer had looked at the page and while it met the definition of done and had been ready to go, he noticed it was not quite right (design QA/sign-off was not a part of our definition of done). He took it upon himself to reach out to the designer and work through the problem together. He wanted to make sure that what went live met the highest of standards. Engineer and designer sharing a commitment to delivering the highest quality product to our users. Working together.

I’ve had several conversations recently with product and engineering orgs where a common complaint I hear is how the design team have different objectives from the product and engineering teams. It’s a type of comment I’ve heard often throughout my career. The general comment goes something like:

“Designers are focused on the user while product managers are focused on the business.”

It’s usually put delicately and to suggest that designers have noble purpose, but also this purpose can sometimes get in the way of the responsibilities of the team. This perspective is at odds with the above example of designer and engineer perfecting the product pages.

I reject the framing that designers don’t care about business goals. Designers’ goals and PMs’ (and engineers’) objectives are not so diametrically opposed. Every designer I’ve worked with wants the company to make money and succeed. There’s a whole talk I give on this subject — about how designers use the wrong language in voicing their goals and objectives at work. I should probably write a post about that one day. But I want to get back to the designer and engineer anecdote I started with.

That collaboration doesn’t happen by accident. There’s something this designer did, something I’ve seen a lot of really good designers do, that helped bring them to that point. They reached out and built a relationship.

This designer, in joining that squad, reached out to each member one on one and set up a coffee chat. He wanted to get to know each of the people he’d be working with better. He didn’t set it up to learn more about the work and team’s focus, or how it operates. He set it up to get to know the person.

I can think back on the designers I’ve worked with and the ones that stand out did this sort of thing. They were naturally empathetic and curious. Those traits certainly transfer nicely to product design. But the unintended — or intended — consequences of reaching out in such a personal and genuine way is that it builds closer working relationships with those around you. When one does that, they understand better how their team member thinks and feels and goes about their day. And each team member learns the same thing back. That’s how an engineer comes to consider important the things a designer they’ve befriended considers important.

That’s my advice to designers out there: send out coffee invites. Get to know the engineers and PMs on your squads. Learn about them as people — what their interests are, what’s going on in their lives. It will lead to deeper connections and from that, a better working relationship.

The one thing Chick-fil-A does better than its competitors

January 6, 2025

My kids really, really like Chick-fil-A. They’d get it for every meal if we let them. And we probably let them more than we should. As a result of their insistence, and that they’ve been on holiday break for the past (almost) two weeks, I’ve been ordering Chick-fil-A a lot lately. I think they have the best mobile food ordering app out there.

The app is well designed. Screens are clean and well organized. Whether ordering a meal combo or just one item, you’re able to customize as much or as little as you like and it’s structured in such a way that one can build a complex order without mistakes. It balances infusing the brand and style into the experience while prioritizing usability.

These are the reasons why the app is good. It is not why it’s great.

What makes the Chick-fil-A mobile app great is how well it leverages technology to solve real needs for its customers AND address business imperatives for the restaurant.

The app uses GPS to determine when to start building the order, ensuring that it is fresh and ready when you arrive. The Chick-fil-A near us is two towns away. Depending on traffic the drive can take 20 minutes, 40 minutes, or longer. There’s really no way to accurately gauge the time to the restaurant. This presents a challenge for ordering it ahead of time, or it would. I place our order via the app at home and then hop in the car. When(ever) we get there, the food is ready and fresh, usually just being bagged as we pull up to the window.

The order will be fulfilled when the user approaches

By tying the start of order fulfillment to the customer’s location (we’ll leave the understandable privacy discussion of whether you should share your location with a business for another post), Chick-fil-A ensures that they limit wait times and avoid warm food cooling unnecessarily. Because the restaurant is fast food, they know they can assemble an order quickly (they do it when you order in the store or at the drive through). It provides a real benefit to the user (convenience and freshness) and eliminates waste for the restaurant (e.g. food not being picked up, customer complaints about cold food, etc.). Brand value is reinforced because the user consistently receives fresh, hot food. That’s a win for everyone.

I’ve not seen a lot of food ordering apps that leverage GPS in this way. A lot of apps offer live order tracking where you’re updated as the order is being made/assembled. Think Starbucks app telling you your drink is being made or UberEats letting you know where your delivery driver is. Updates are sent to the customer while the process continues unadjusted, whether notifications are read or not. Information flows one way, after a step is completed. The Chick-fil-A mobile app flips that dynamic. GPS is used to trigger actions.

This may appear a simple adjustment, but again, not a lot of companies are doing it this way. I wonder how Chick-fil-A was able to think differently on this, and I imagine they must have used service design as an approach in ideating and developing the app. Service design is where the team considers not just the digital solution but how employees are involved in the process to design a better flow. “Service design improves the experiences of both the user and employee by designing, aligning, and optimizing an organization’s operations to better support customer journeys,” Sarah Gibbons, in NN/g’s Service Design 101 explainer.

The Chick-fil-A mobile app required more than just digital design. It required making changes to how the restaurant received and fulfilled orders. Employees needed new training. Intake processes need to be adjusted. It requires more work to build this solution, but when done right it produces a more holistic and satisfying experience.

I did some digging and the app was built using design thinking and service design methods. It was developed by an outside agency, Bottle Rocket, who wrote this about their approach:

Utilizing design thinking, our team crafted an innovative mobile ordering application, Chick-fil-A One, that took full advantage of Chick-fil-A’s best-in-class capacity. We created a GPS-enabled mobile order-ahead solution. Restaurants would be notified of an order when customers were in-route to the store — ensuring no meal was ever cold and long wait times could be avoided.

A key part of this solution is being able to look at the available technology and deploy it in different and original ways. We all have GPS-enabled smartphones in our pockets. How might that fact be leveraged to provide a better user experience?

Allow me a brief tangent: 10 years ago I was overseeing our agency’s summer intern project where the cohort was recommending to Dunkin Donuts that they should build group ordering as a feature in the app. Users would be able to invite others to add their order to one single consolidated order online (something more common today). They had done a lot of user research and had a strong case for it. In preparing for the pitch, we had learned that Dunkin had actually offered group ordering in the app years before and it failed. That first implementation consisted of a button that would open a PDF the user could print and then fill out with pen or pencil and take to the store. Group order was (is) a good idea. The first version failed because the technology didn’t support the solution; user needs were not really being met. At that time the ability to collaborate in real time across multiple mobile phones did not exist. We were able to make the case that the evolution of technology made a once-failed idea now relevant.

Chick-fil-A has the best mobile food ordering app on the market because it leverages technology in a meaningful way, providing real value to both customer and business. It’s innovation relies not just on designing a better digital application, but in also updating the way in which employees operate. This is a more thoughtful, holistic approach.

How design teams can demonstrate impact to a doubting product org

October 30, 2024

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.

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.

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.

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.

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

September 13, 2024

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

August 12, 2024

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

August 10, 2024

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

July 11, 2024

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.

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

June 25, 2024

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.

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.

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:

Pillar 3: Elevate design execution

June 25, 2024

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.

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:

Pillar 2: Drive design integration

June 25, 2024

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:

Pillar 1: Strengthen design team culture

June 25, 2024

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.

Check out the other pillars:

The four pillars for building a successful design team

June 25, 2024

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:

Better things than chatbots

April 24, 2024

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.

September 13, 2017

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:

Open the Starbucks app.
Press the floating action button.
Press the “Order” button.
Select my saved drink choice.
Press the store selector.
Choose a different saved Starbucks location.
Press the “Review Order” button.
Press the Continue button.
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:

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

August 15, 2017

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

August 3, 2017

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

June 28, 2017

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.

Blog

Design for community

Design as Governance

LinkedIn vs. Facebook

Content Moderation and free speech

Design as a community catalyst

The real value prop of design

Design delivers business results

Why design systems

Engineering buy-in and advocacy is critical

Perfect is the enemy of good

Process over pixels

In conclusion

1. Stop calling… please

Let design lead the way

Some unknowable answers are knowable

Design demonstrates impact

Project Aristotle

Tending your team’s culture garden

Equality in distribution of conversational turn-taking

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

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

#3: AI should be invisible, not human.

#4: Be curious.

The obstacles

Building User Research at Drizly

Iterative learning

Answering seemingly unanswerable questions

Building research momentum

Research for roadmap planning

Final thoughts

Pillar 4: Establish a design-thinking mindset

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

In conclusion

Pillar 3: Elevate design execution

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

Pillar 2: Drive design integration

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

Strengthen design team culture

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

The four pillars for building a successful design team

This post is about AI.

Better UX through AI

Morning ritual

A better experience

Make it happen

Let’s all do better

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

Changing landscape

What’s next

Solutioning is more fun than problem solving

My great startup idea

Don’t be a tech company