AI impact at different Levels

This is a collection of rough thoughts regarding how AI will impact different levels of designers.

We're going to talk about the impact on design teams at each level. I'm also looking at this as two major categories of change. First, the impact on the individual designer. Then, the impact to the design process. I'll have more on the design process at a later date, but as far as this goes, as far as impact on the levels, we are talking about the impact on the process from a technical standpoint; what are the steps in the process, how are they handled technically, what files get produced, and so on.

So, let's break down individual and process impact of AI at each level...

1. Entry level is getting squeezed by task automation
2. Mid level is facing raising expectations
3. Leadership level needs to shape the conversation
4. Some tips

Entry Level

Entry Level folks have a few key responsibilities.

1. Learning the real-life process of designing, delivering. A significant part of the entry is also the responsibility to learn the process of designing in a professional environment and in doing so, connecting with collaborators from other professions. For instance, learning to work with a product manager or engineer
2. There's also a lot of work that is doing first drafts, then refining slowly or someone else steps in to tune it up
3. Taking instructions and being a team player. This means an entry level person succeeds is where they are fast at the Production work, but they also bring with it thoughtfulness, empathy, collaboration, and self awareness.

A lot of AI impact will be felt at the entry level because of the proportion of their work that is production-driven. That's the story: AI is replacing young grads. A NYT article from August 10th says entry level hiring in software engineering has fallen precipitously. Here's a staggering quotation:

Among college graduates ages 22 to 27, computer science and computer engineering majors are facing some of the highest unemployment rates, 6.1 percent and 7.5 percent respectively, according to a report from the Federal Reserve Bank of New York. That is more than double the unemployment rate among recent biology and art history graduates, which is just 3 percent.

OK, can we take a minute to hear it for the Art History grads?

The article goes on to describe that students who just graduated are particularly hard hit because in many case colleges are just now starting to teach AI coding tools, which are the most sought after skills.

Going back to design, the story's not going to be much different and it sounds bleak. It's a generational shift and there is a window of people, young people who are in the wrong place at the wrong time. These are folks who had early high school days shut down by the pandemic and they've absorbed a lot of volatility and change. Graduating into a job market that is imploding onto itself is something I wouldn't wish on anyone--and I'm saying that as someone who graduated right into the post-9/11 economy.

However, there is no obstacle for anyone at any level to deliver the other kind of value that comes with collaboration, thoughtfulness, and empathy.

The importance of these skills, so so important, typicaly called soft skills, this is glimmer of light in the ability to differentiate yourself on soft skills, critical thinking, and collaboration. At the end of the day, I'm also excited to see folks at this level, but it's going to be rough in the near term. Starting from scratch is like medicine--tastes like shit, but it's good for you in the long run.

Mid-level

At this level, you have learned the process and you have some production skills down pat. You are starting to gain some clout with other stakeholders and collaborators.

You are also expected to have a relatively strong sense of self-awareness and collaboration with others. Folks at this level can be trusted to manage others, such as running a meeting.

Your team will look to you to be highly experimental. You will be at the forefront of testing, evaluating, and adopting new tools to accelerate the workflow.

You need to get to know new tools as early as yesterday. The day to adopt AI-driven tooling, and quickly, has past.

Your position in the middle of the team actually gives you the most leverage. Since you can see the process from end to end, you need to assess that process and move into the realm of automation.

If you define an understanding of how to improve the process, and you bring others along with you for the need to do so, you will have a huge impact downward to the Junior folks, laterally to your fellow designers, and upward to Leadership.

You're being be tasked with ingenuity in two directions

1. Designing for experiences that include AI
2. Using AI to accelerate the design process

For designing experiences that include AI, the first step is to learn more about how AI works and how the outputs that come from interfacing with AI can impact your users.

Then, map out a product experience and think think about how something like an Agent or an automation with built in prompting can be used to streamline the product experience.

There is an emerging field in this regard known as Applied AI, which I'll talk about more in the future.

For accelerating the design process, as a product designer, you already have a lot of the skills to identify where AI is and isn't useful. Map out the workflow for your and all the systems in it. Service Blueprints are a great way to do this. Assess each part of the process and try to break it down to its individual components. Now, consider re-composing the process but with the AI tools that can help that process.

Being the designer of the design process is key, and mid-level or journeyman designers, you're in the best place to do that.

Also, as noted for Entry Level colleagues, you can really level up by investing in your own soft skills. Can you communicate the value of what you're doing with people outside your profession? Can you facilitate workshops and conversations that contributue to the process? Can you run meetings, guide others, and elevate other people's engagement in the process? These are, again, the thngs that AI is not going to do for us, and an area where we need to concentrate our level of expertise.

Leadership

This is probably the level that will have the greaterst and most outsized impact on the profession.

Leaders bear the responsibility (but not the ony contriburto) for shaping the culture and values of an organization. Eveyone contributes, but leadership carries the responsibility.

So... now your profession and the people who report to you are facing an existential disruption. Which way are you going to go? In short, there are two paths to choose based on newfound capacity.

Are you going to increase capacity so significantly, and unlock the potential of your team to do more and make a profoundly greater impact? Are you going to overtake other roles in the company with that increased capacity?

Are your going to maintain your capacity but reduce the headcount?

Can you empower your team to refine their workflows, to find efficiencies and enhance their process?

The answer has to be yes.

Tips

At the entry level, two things

1. It's a freakishly good time for entrepreneurial experimentation. Come up with 3-5 projects and start hacking away. Adopt the process of mapping out a workflow, then designing it, then vibe coding it. Then, find a way to test/validate it. How can you do it as quickly as possible? Where does the process break down or create errors?
   • You could use a prompt like a Job To Be Done for something in your life, or something that would help someone you know.
2. Find that way to present yourself elevating communication skills, collaboration, and critical thinking. These things are sometimes best communicated by media other than graphic design or UX design deliverables, so explore writing, content creation of other kinds.
3. Learn everything you can about AI. I have heard some chatter that entry level people who can demonstrate true fluency with native AI tools will be in increasing demand. Try every tool in every part of your design process. But more importantly, go further than just the tools. Really learn to speak the language. If you are concerned about the ethics of its use or the environmental impact, learn everything you can about that from reputable sources.

I also want to acknowledge... this is a tough time for the Entry Level folks in product, design, and software engineering. No one has gone through what you're going through before, so whatever you choose to do, if you really give it focus, is probably the right idea.

For mid-level, journeyman designers

Do what the entry level is doing, then expand into two key areas...

1. Really own the process. Shape the process based on what you learn, and what you learn from others. Frame up the process and explain why it works, why one tool is more important than the others. And explore the use of more sophisticated and powerful tooling going beyond something like quick design mockups or quick prompts--start messing around with custom GPTs, Agents, and more powerful automations.
2. Bring others along with you. Your ability to facilitate work with others will be more important now than ever. All of your stakeholders and fellow designers are looking for anything and anyone who knows what they're talking about, any form of knowledge that they can use to establish a shared set of facts.
3. First off, get familiar with what AI is capable of. spoiler: More than just chat. It's not a bad time to take a class, if that's how you learn best. MIT pro | Stanford

For Leadership

1. Help the team prioritize what elements of their work and process can be improved by adopting new tools
2. Set the standard for critique; provide guidance to those who lead critique that it's being run properly, that the process ultimately improves the work
3. Model a practice of advocacy for your team; Set the stage for the team to hype each other up; set up public forums to showcase their work. Guide your team on how to present their work and explain their process in ways that people outside your function can understand.
4. Revisit the job leveling for your org; define what is expected at each title; get feedback from trusted members of the team and other leaders; communicate out that leveling ladder
5. Define the change and make sure the team addresses it as a team, not cast to the wind to figure it out on their own
6. Coach and mentor the team one on one to reaffirm their strengths and work on weaknesses, this can help guide their ability to focus on those soft skills and develop accordingly

Careers Getting Murdered as AI Takes on Tasks

AI is significantly impacting product development job roles, but will do so differently at different organizations.

Ok, so… you’re a product designer… you heard that AI is coming for all our jobs. But is it coming for your job, your co-worker’s job, and your other co-worker’s job the same way?

AI tech will impact many roles previously safe from automation or offshoring.

To understand this moment, take a look at what experts are saying about AI’s impact on a lot of different jobs. Here’s an article from Forbes published in April of this year. The title? These Jobs Will Fall First As AI Takes Over The Workplace

The article goes on to describe ways that jobs that will be impacted or eliminated by AI tech.

The first wave is jobs that perform repeated tasks: data entry, scheduling, and first tier customer service; tools are replacing these roles

The next wave is jobs that are repetitive but have some technical consideration. Bookkeeping, financial modeling, and basic data analysis; Banks are building out these capabilities.

And the list goes on.

AI will impact tasks that are applied across many roles.

Another way to look at it is to break down jobs into different tasks.

The team at Visual Capitalist created a chart of skills like writing, active learning, critical thinking, etc. And each skill has two numbers: how long it takes with AI and how long it takes without AI.

The visualization sorts the tasks by fastest to slowest after the application of Generative AI.

I wanted to see which had the biggest impact, which has the biggest change from without Gen AI to with Gen AI. At first glance, this is where the biggest impact would be on whether a given job is phased out over time: does the necessary skill get recalibrated in a significant way? And if so, how much?

There's no screaming obvious answer in this data. But the top skills? I'm getting a big Software Engineering vibe, with Programming being 2.9x faster with generative AI tools. But the lines are blurry: on the lower end, "Judgement and Decision Making" is now 1.8x faster(?) and would obviously cover a range of roles.

Broadly speaking, these tasks have broad and deep alignment with all three product development roles: design, product management, and engineering.

But what does that mean for the people involved?

Seeing how AI delivers impact on specific tasks, it's important to see what happens when we link all those tasks together.

AI's impact will be acute in cross-functional environments where there is high dependence on process.

For Product orgs, the way forward with AI looks different depending where you start as a team... but do all roads lead... to MURDER??

If you are a Designer in an organization where PM and Engineering want to move fast and break things, then they can now leverage AI-driven processes and tooling to get pretty far synthesizing user research, drafting prototypes, refining UI, and spec'ing out code without you. The Designer role just got killed! Oh nooooooo!

If you are a Designer where PM is lagging, but collaboration with Engineering is strong, then you can take your user research, frame it into JTBD, even model the potential business impact, then create your own designs with an AI-accelerated workflow, break it down into Jira tickets, and work directly with Engineering on prioritization. The Product Manager role just got killed! Aaaaaaa!

If you are a Designer where PM is strong, but Engineering is lagging, then you and the PM can get pretty far honing in on customer research, accelerating your synthesis, rapidly developing prototyping options with Figma Make and Lovable, then, once you get things working, reach out to an Engineering team to help with scaling and hardening... the Software Engineering role just got killed! Hey, somebody call the cops!

We know that in each of these scenarios there are huge gaps, but the reality is, this is playing out as we speak. It's not just reshaping or eliminating careers, but having a grueling effect on people involved. For that, we can take a more qualitative look. Stories are starting to surface of how this takes shape.

The impact of AI on process-driven roles will also be highly emotional.

https://www.reddit.com/r/UXDesign/comments/1mj94kf/struggling_to_see_a_path_forward_with_ai/

A UX designer with 7 years experience is having a significant and negative emotional experience to the design work that their PM completed with AI tools.

I replied to them on Reddit, but in summary, this is going to be a journey fraught with emotional challenges and those emotions can get in the way of our concentration, our ability to be flexible, and our ability to perform at our best overall. I advise that UX designer to break the problem down, including identifying and separating out the emotions that are felt. Then addressing the problem through collaboration with the PM.

AI is impacting hard skills which can be quantified, but still lacks on impacting soft skills.

High-performing, high-quality teams are bound together by respect, collaboration, ingenuity, and the psychological safety needed for growth. These 'soft skills' let a team level up their output together. That's when 1+1=3.

Leadership must seize the opportunity to move the whole team forward

This path ahead is paved by a few factors:
- the competency or maturity of the functional role before AI
- the relationships built around the others on the team
- the soft skills and abilities of those in each role to adapt, collaborate, assess, and learn

So if all roles are strong... and all roles take on accelerated workflows and tooling... and if the people on the team are supported through this insane time of transition... then you're not killing off roles, your leveling up capacity. This is the REAL goal. This is the future we WANT.

Who knows, with all this newfound capacity, some of these products we build might actually be good!

So what do I do?

Well, we’re off to a great start. 

Here are three suggestions to move forward

For individuals: experiment and get good. Yes, it’s worth signing up for your own subscription for GPT pro or Claude pro or Lovable or Figma pro. Experiment with having GPT open in one screen and just ask it questions along the way. New to vibe coding? Tell it what you want to do and how you should start. New to GPT? Ask it how to make the best prompts. It's sort of smart and dumb at the same time. Experimenting is the best way to level up.

Most importantly, once you get your bearints, see how tools can fit together. See what happens when you create something in Figma Make, then spin it up in Lovable. See what happens when you build an automation in Zapier that runs a prompt in ChatGPT. There's a lot of potential and, at least at the moment, the bar is pretty low in most organizations.

For teams: learn together. If you’re learning on your own, Regularly share what you learn. Break off a project and mess around. See if it’s something you can do quickly and clean up if you screw up. 

For leaders: set the standard. This is where the real power is to scale within an organization. Join your team in experimenting and learning. Have the team identify what projects might be good for trying new methods, and if it fits, back them up. You can help set the metrics for the success of these experiments, the KPIs you're trying to hit. Help frame the team's ideas for what it means to get higher quality results.

Talk with other leaders about setting a culture that will elevate the disciplines you will invest in. Know what kind of org you are and will be. —find those ways to emphasize soft skills, set an expectation that you gotta be good at that 

Most importantly, like any individual, you gotta learn. You need to lead by example.

Those are some tips! I'd love to hear what you're up to, what's working, and what isn't.

Feedback: the POINT method

As we are disrupted by AI, this practice assures the team has high-value insight into their performance and processes. The Critique practice is where the team hones their ability to identify and apply feedback. I think of it as the atomic unit of the Design process and it can help elevate the function and performance of the practice.

The POINT method

I have seen how bad it can get. Design teams can be hard on each other, and picking apart work becomes a sport. Stakeholders can come into a session with little context and decry the work in progress as useless. Designers creating the work can see conversations spiral off topic.

To avoid going off the rails, I have found that feedback is best structured using the following framework:

• Permission "Can I give some feedback?"
• Objective 'What is the objective we're trying to achieve?"
• Inquiry "Does this work achieve the objective, why or why not?"
• Next Steps "What are some ways to improve the work?"
• Timeline "When will we see those improvements?"

This provides multiple benefits. First, it is flexible enough to apply to those in the role of giving or receiving feedback. Second, it can be applied differently for providing professional feedback regarding a given work product vs providing personal feedback on someone's skills and attributes. Finally, it's easy enough to follow that stakeholders who participate in feedback sessions less frequently can adopt the method when called upon.

I will typically introduce this method and coach the team through it when I begin as a leader. I also provide a reminder at the beginning of each session. For instance, for remote critique, I can easily include it on a board in Figma, Miro, or whatever platform we're using. In person, I have posted it next to work being viewed, or left handouts around the room.

Giving Feedback

Design teams, and to some extend broader Product teams, have multiple opportunities to surface feedback. As a leader of critique, I invite members of the team to pitch their work in a certain way, then ask for feedback and discuss the implementation of that feedback.

The focus is on the work and not on the person doing the work.

Permission: "Can I give you some feedback" Setting up the conversation is key. In a critique session, it is inferred but it is best to say it aloud.

Objective: "What is the work trying to achieve here?" Stating the user objective and business objective is key as a reminder to those in the session.

Inquiry: "Does it achieve the objective? Why or why not?" Whether the work achieves the objective or not, inspecting the reasons behind that assessment help us understand where there are potentials for improvement.

Next Steps: "Here are some changes to consider." If the person providing the feedback has ideas, then they can be provided. After the session is over, the person doing the work is responsible for making the changes or for assessing why the changes don't work.

Timeline: "When do you think we'll see those changes?" This is the part of the POINT process that truly adapts it to the work environment. We need to set timelines and see results within each day, week, sprint, month, and quarter. That's just the reality of doing business. Typically, I advise my team to try all changes, then show evidence why one didn't work. There is some concern that this wastes time and in some high-speed organizations, that concern can be legitimate. However with new design tooling, we're unlocking a new dimension of speed to value, so it is more feasible to try multiple ideas or rounds of improvement when historically it would be time prohibitive. With this in mind, I ask the team to make their best estimate while also encouraging the team to give each other some grace while we adapt to new tooling and processes.

Receiving Feedback

This framework also applies to receiving feedback when the role is reversed. Briefly, that looks like this:

Permission "Can I get some feedback?" Let others know you're ready.

Objective "Here is the objective the work should achieve." Stating your assumptions helps set and clarify expectations.

Inquiry "Why do you think this works to meet the objective? Why not?" Sometimes you need to pull it out of them.

Next Steps "Here's what I hear are the next steps here." Repeating back the next steps reflects your understanding and demonstrates that you are practicing active listening.

Timeline "Here's when you can expect to see a new version." Taking accountability for enacting change and sticking to the timeline is a great way to build trust within a team.

Personal Feedback

At times, as a leader, you have to provide coaching to members of the team and providing objective feedback is a critical part of that effort. The POINT method can offer some support to the leader or the person being coached.

As a leader, you could leverage the POINT method to provide feedback when a direct report faces typical challenges like an office conflict or a meeting outcome that bothered them.

Permission "Can I give you some feedback?" Establish the expectation for the conversation.

Objective 'What is the objective you we're trying to achieve in that scenario?" Get their perspective on the circumstances.

Inquiry "Does you achieve the objective, why or why not?" Determine their role in the situation.

Next Steps "What are some things you might do differently?" Discuss options at hand for addressing the issue or opportunities to develop a skill that would address the conflict.

Timeline "When will you have an opportunity to see those improvements?" Identify upcoming points in the schedule when they can put new practices to work. For instance, if the conflict was in a recurring meeting, then the next session will be an opportunity to put new skills into practice.

Diverse Feedback Sources

When a critique is run well, it's easier for outside people to join and be productive. Business stakeholders, subject matter experts, and customers can provide vital input and validation during a design process, however they can struggle to articulate the feedback in a way that is conducive to improving the work. It's not their fault. It's important to recognize that different organizational cultures, different industries, different job functions all have different communications styles and vernaculars.

Designers sometime lose sight of this. Design education is setup for regular, near-constant feedback. As a result, Designers sometimes get frustrated with other stakeholders inability to articulate their feedback and as a result fail to build the necessary bridges for incurring the proper input. The POINT method tries to provide a simplified framework that people outside the design practice.

Permission "Can I give some feedback?" As a leader or facilitator, assure the stakeholder that the feedback session gives them this permission and that the team is ready for their feedback. Say it out loud.

Objective 'What is the objective we're trying to achieve?" Articulate the objective. The stakeholder may see the objective differently or, what is typically common, is that the stakeholder has the same objective but it is articulated differently within their job role.

Inquiry "Does this work achieve the objective, why or why not?" Here is where some stakeholders struggle. Sometimes, it's self-limited belief that they don't feel qualified to render an opinion. Reassure them that their perspective is valuable. Clarify that this isn't a matter of opinion, it's a matter of giving yours best assessment of how well the work gets the job done. Stakeholders also play a HUGE role here in identifying risks that the designers may not be aware of.

Next Steps "What are some ways to improve the work?" Some stakeholders jump right to this step. Their minds work quickly, and they have already processes the last 3 steps, made some functional assumptions and push forward with their feedback. Don't push back, help guide them. Honor this method and talk them back through why they came to that conclusion.

Timeline "When will we see those improvements?" Stakeholders may or may not have insight into how long it takes work to get done. Clarify for the team when the next opportunity will come to share the work with this stakeholder.

Getting it done

I have put the method to work in all the above situations and found a few benefits. In Critique sessions with teams, it helps align the methodology and the expectations between team members. It helps clarify my own thinking, so I can bring others along by offering feedback. It helps establish clear communication in coaching situations when providing support. And it opens the door a little wider to outside support from stakeholders, which helps enrich the Design practice overall.

Feedback methodologies will be increasingly important as Design and Product teams infuse AI-enabled tooling and practices into Agile design and development methods. But human cognition and emotions still remains a little hard to pin down. AI can't tell you what your coworker things about the work at hand, but an efficient feedback practice is a valuable human-in-the-loop tool that unlocks a more effective final product.

How I Run 1:1s With My Design Team

As a design leader, I see 1:1s as one of the most important tools I have for supporting growth, building trust, and making space for honest conversations.

The frameworks below are devoid of subject matter, individual nuances, or changes based on job level within the IC or Manager roles. Those are applied quickly as I get to know people. Most importantly, these are framed for instrospection and support, which are going to be critical to teams adapting design methodologies to leverage AI-driven tooling and processes. Managing the people in an age of dynamic change will require rigorous transparency to assure their growth.

So, every 1:1 starts the same way:

“What’s on your mind?”

I picked this up over the years as a way to signals to the team that this time is for them to check in and surface what matters, not for me to lecture. I try to create a conversation that’s focused and frank while still being supportive.

1:1s With Individual Contributors

Focus: Growth, coaching, connection

With ICs, the goal is to support their development, not just as designers and collaborators, and open the door to explore leadership.

Once we open with “What’s on your mind?”, I listen closely. If they bring up a challenge, something they’re stuck on, a tough dynamic, or something that just feels off, we’ll explore it together:

• “What have you already tried?”
• “What would a good outcome look like?”
• “What kind of support would be helpful from me?”

If the conversation turns toward wins, I look for ways to stretch them like leading critique instead of participating, mentoring a peer instead of commenting, or sharing work with a broader audience. These moves help ICs build confidence and influence within their role.

About once a quarter, I’ll zoom out and dig into broader scope of career development:

• “What kind of work do you want more of?”
• “What’s a skill you’re trying to build?”
• “What do you want to be known for in a year?”

We’ll turn those answers into tangible next steps that they can own with support from me where needed.

At the end of each 1:1, I ask one more question:

“What’s something I could be doing better to support you?”

As a manager, it is critical to model this kind of invitation for input. I expect my team to take feedback and I set the bar by inviting it myself. It's also critically important to monitoring my successes and weaknesses as a manager.

1:1s With Managers

Here's how I would support the same framework for Managers.

Focus: Leadership, team health, operational support

The opening is the same, "What's on your mind?" I expect managers to come with issues in hand. Some weeks it’s about a struggling team member. Other weeks it’s delivery risk, team morale, hiring, or areas of personal development like confidence in their own handling of a team issue.

I’ll ask questions to help them reflect and act:

• “Is this a person issue, a process issue, or a pattern?”
• “Where are you tempted to step in? Where might you step back?”
• “What would it look like to lead this change yourself?”

If they’re struggling to get value from their own 1:1s with their reports, we’ll talk about structure of those sessions, then dig in to ways to establish trust and provide coaching. I want them to know they have my support in managing tough conversations.

And just like with ICs, I ask for feedback at the end:

“What should I be doing differently to support you as a manager?”

Similarly, I'm modeling the behavior I want to see and establishing the expectations that feedback can always be given and received.

Why It Works

With ICs, I focus on their skill growth. With managers, I focus on helping them lead better. In both cases, I’m there to listen, coach, and adapt. And I always ask for feedback, because I’m still learning, too. 1:1s establish a feedback loop that is one of the most powerful levers we have to grow our people, our practice, and ourselves. Done right, it's a meeting we're looking forward to when the time comes!

Collaboration tips for a remote work world

Here are a few things that I have picked up that help keep the design process moving when you can't be in the same room putting post-its on a whiteboard together.

Set expectations with an agenda. Before you send out a meeting invite for any Design Thinking session, draft an agenda that FULLY explains the process, the expectations for the session. One of the expectations? It's OK to make mistakes, to go off on odd ideas, to explore new spaces—say it up front.

Assign a facilitator and a scribe in advance. When someone is running the meeting, that's a job into itself. It si difficult for them to also be a facilitator and an be effective contributor. This can be tricky, but it makes for a much better meeting. Same with the scribe—assign someone to take notes and

Over-communicate in both channel and timeframe. The meeting invitation is a communication channel for the agenda, the expectations, and the process. So is email. So is slack. So is the meeting itself. Embrace the strengths and weaknesses of remote work by reiterating the schedule for the session and the value of the session in different channels so your participants can capture that information on their own time.

Break up the activity of the agenda between group collaboration and individual work. Research has shown that creative brainstorming or divergent thinking is best done alone. But research has also shown (featured in one of our readings this week) that 5 people can end a meeting with 5 different interpretations of a problem. Build on these findings early in the Design Thinking process.

• Have participants write their understanding of the problem in advance of the meeting
• Come together as a group to share these problem statements and come to alignment with a How Might We statement
• Then, for the initial act of divergent brainstorming, have everyone go off camera and mute for 15 minutes, draft their own ideas
• Come back together to share ideas (break into groups of 5 or less if needed)

Alternating between collaborative and solo work will be more productive and can be done very effectively through remote tools, rather than having everyone move from collaborative spaces to solo spaces.

Help ward off the vulnerability of collaboration with warm ups and humor: When participating in divergent thinking, most people feel vulnerable. sketching, brainstorming, divergent thinking—these aren't always everyone's strong suit and it can be uncomfortable. This sense of vulnerability can, for some, be worse remotely where there is a sense of being 'alone' augmenting the working environment. I usually kick off with a warm up exercise to get everyone going like discussing a favorite local restaurant and what makes it great. When sharing remotely, I sometimes use sound effects (applause, fanfare, 'ooos and ahhhs') to help add some levity to the circumstances.

Use Collaborative Documents as Creative "Spaces" in ways that you can't in real life. While BU recommends MS Whiteboard, I can't speak to this tool personally as I have never used it. I can, however speak to Miro, Mural, and Figjam as options for team collaboration. Some of these have features that you can't take advantage of if you were doing the session face to face. For instance, when using Miro, you can make a list of ideas in a separate text document, then copy and paste that list into your Miro document and the text will automatically be instantly converted to sticky notes that you can use in your collaboration exercises. All these platforms also let you attach links to your notes, so you can include contextual references and documents. All of that would be hard IRL

… and these are not remote-specific, but they will help you conduct your sessions smoothly (depending on your company culture)

An important rule: No job titles. for the duration of any collaboration session, divergent or convergent thinking, I have seen benefits in abolishing job titles and hierarchy for the duration of the session. Good leaders are usually amenable to me saying something like "Tom, I know you're the boss, but not for the next 90 minutes. You can go back to being the boss after lunch."

Take a minute to praise 'outsiders' in your cross-functional participants. If you have the good fortune of bringing someone into a session that you don't usually get to work with, then call it out; thank them in front of everyone. For instance, at one firm where I worked, it was very difficult to get customer service representatives to participate in these sessions due to some organizational constraints. If I did get one or more of them involved, I always called it out and thanked them for their time and their expertise.

Set up incentives for productive behavior and disincentives for unproductive behavior. Have you ever used a "swear jar" where anyone who swears has to put $1 in the jar? I am facilitating a session in a few weeks and I am considering a "No jar" for anyone who says No to an idea during the convergent session has to venmo me $5 (which I will donate to a charity of the team's choosing at the end of the session)

Building a Design System Without a Team

Update: I changed the title of this post from "Design Systems for Small Teams" to "Building a Design System Without a Team."  This is a more accurate description of the content of this post and addresses the key issues: building a design system when it is impossible to dedicate full-time resources. 

When a new design system is announced, I'm right in there with everyone else, digging into the public documentation website, examining the versatility of their responsive assets, clicking through to examples, and, of course, visualizing my own team's ability to do the same. But the shine wears off quickly and it gradually seems impossible.

Looking at design systems from AirBnB, Google, IBM... Eventually, there's a wake-up call: You're not in the FAANG. The design systems you're looking at online are built by dedicated teams, specialists hired to do that work. They develop specific skills and processes, whether they are full time members of the team or agencies with highly capable teams of their own. 

If you are on a small product team, it is unlikely that you are in a situation fitting the above description. You're more likely to be generalists and stretched thin. 

If you maintain the expectation that you will be able to deliver what those big teams deliver, at the same cadence, and in the same manner, you're going to have a long string of bad days. 

How am I going to pull this off with 20% of one designer's time and sporadic development commitment? We can't be this detailed or specific or thorough. We can't dedicate a team to the design system. We don't have engineers dedicated to the design system. We can't even fully dedicate a designer to the design system. We don't have a 'design ops' person, let alone a team. 

Your Responsibility

I'm speaking here to design leaders. That may include senior IC's. That may include management-only types. But If you're someone who takes on the design system project and helps define the process and infrastructure for creating and maintaining that system, then I'm talking to you.  

For the sake of this discussion, a design system lives in four places:

Design Assets: The library of assets that designers use in their work in accordance with the design. Sketch symbols, Figma components, etc. These tools are specifically for the design team. 

Codebase: The front-end code base, that lives actively in production that executes the design ecosystem, reflects the design tools. This is specifically for the engineering team. Naturally, in organizations where designers also code, there can be relationships drawn for collaboration & contribution, again depending on the team's dynamics.

System site: A realization of the design ecosystem in the format of a publicly accessible site. This tends to include visual examples and code snippets for each component. This also reveals the taxonomy and hierarchy of components, along with the intentions and limitations around their use. There are ways to split the responsibility for this between the design and engineering teams, depending on the team's dynamics. 

The design ecosystem: devoid of medium, this is the set of rules and guidelines made visible that define the brand, product, and resulting experience. The design team owns this, in tight collaboration with stakeholders like content strategy, marketing, leadership, etc, if your company has each of those. 

A functioning, living, breathing design system will be realized through the creation and maintenance of these four things. 

So, what first?

While you may not be able to commit a full-sized team to the effort, the system will need an owner, an individual contributor on the team who can be the steward of the system for the long run. This does not mean they need to be the final arbiter of what goes in the system, although that can help a lot. On my team, it was our intrepid designer Mai who took the reins. 

Out of the four concentration areas, you need to start somewhere. I advocated for starting with design tools, namely a pattern library for the design team to use while creating new designs.  

It may sound selfish, but if you have any hope of propagating any design standards through the organization, you have to start with the design team and assure that work in flight is designed to spec with consistent execution.

Build out a shared library of patterns for the team. Make sure everyone is using the same grid, type, form fields, buttons. As projects com into the team, apply the new assets. Look at every project as an opportunity to bring more of the digital experience into alignment.

Keep your side of the street clean. 

Gain allies

Seeing the design team get in order and deliver consistent, high-quality work has a positive downstream effect as work is delivered. 

Development team members, realizing that the work from the design team is consistent, will soon realize that they save time component-izing their work, too. The challenge is getting both teams to accept the immediate reality that components in the code base will just trickle in, project by project, Jira ticket by Jira ticket. At this point, there's a bit of a leap of faith; building components in the hopes that components will make a system.  

It's not unreasonable for members of any team to second-guess the need for a design system. It is reasonable, predictable, and manageable. 

Project by project, the components stack up, and the proof is in the engineering team's estimates; as components take hold, front end estimates shrink due to efficiencies built in re-use.

My team saw the best results focusing on projects that included form fields: the components are a little complex so the savings associated with reuse is significant.

Gradual Reach

Two more tools can be powerful in extending this lightweight approach to building out the design system. 

A kanban board with tickets created for each component to be made. First column on the left is a great inventory of all components that have not yet been built as part of any project. Final column on the right is components released to production. A few columns in between for design stages, accepted for for development, etc. We've used this simple set up as a complement to what's in the codebase.

A tool like Zeroheight helps a lot for building out a first iteration for your system site. Those geniuses have set up a way to point their site at your Figma, Sketch, or XD pattern library file and--BAM!--it spits out a site of the design system. Not bad! It makes another great tool, in conjunction with the kanban board, for engaging an engineering team on the intended output of the design system.

Once there is some momentum in place, then it sets the stage to begin conversations over the design ecosystem. How can this system be extended to other design materials, content strategy, and brand assets? In some ways, it feels remedial to revisit the system from these other angles, but it is part of the process of extending the reach of the system.

Leveling up the product experience this way takes time, but it gets there. It's cheap, it's scrappy, and it's doable when there's no team to commit to the work. 

So, don't be intimidated by what IBM, Google, Adobe and other big companies are doing. The most important thing to do is to make progress in standardizing the experience of your product, period. On a small team, it doesn't have to happen overnight. 

So, what's your process?

The process depends on the context of the project. Here's the process I favor for an in-house product design effort:

Phase 1, Discovery: Get to know the people who are likely to use the product, the scenario when they encounter the product, and what objective they're trying to achieve and clarify what problems are standing in their way. Conclusion: a prioritized understanding of the problem that needs to be solved.

Phase 2, Design Strategy: Formulate a hypothesis for how to achieve their objectives, and in trying to solve it, go nuts--generate a ton of ideas and solidify a strategy for the content of the experience. Then prototype a chosen solution in a way that looks and feels real(ish). Validate the hypothesis by having real people use the prototype. Conclusion: a clear strategy and direction for a design solution.

Phase 3, Execution: Bring the validated solution to life by elevating the visual and interaction design while refining the content. Once released, observe, measure, and learn how people use it. Conclusion: the design is in market and the team learns from the success or failure of the effort.

In an optimal project setting, I could be able to have some involvement into every stage in this process, whether conducting the work or supporting the team by removing roadblocks they encounter.

Partners

Working as a designer, and leading a design team, is collaborative work. Each step of this design process requires engagement from other partners and stakeholders along the way. It is a team sport.

Within Phase 1, Discovery, there is usually a fair amount of overlap with product managers and researchers. Customers and internal business stakeholders are key to the process as well. In Phase 2, Design Strategy, input from content strategy, while validation from stakeholders and customers is again critical. Product management can help refine key metrics and technical partners can inform opportunities. In Phase 3, Execution, I will lean heavily on visual design and development to execute and business intelligence to assess the performance of the product.

Built for flexibility

Ultimately, this workflow acts as a utility belt. In each phase of work there are a variety of tools to choose from, depending on the context of the project.

The Discovery phase relies on talking to people who represent the users of this product: competitive analysis, content audits, interviews, usability tests, task analysis, even surveys as a last resort. The output of this phase is to synthesize the findings of the research into a tangible concept for everyone on the team to understand; personas, scenarios, content guidelines, problem statements.

In the Design Strategy phase, we have a variety of tools to work with. A well-defined hypothesis can bring direction to a team's work. Activities like sketching sessions, card sorting, affinity mapping, among others can help drive new ideas to address the hypothesis. Prototyping those ideas at a low fidelity is the sure fire way to gut check the strategy and quickly refine critical interactions, content, and overall strategy.

In the Execution phase, the options focus towards precision. Visual designs, fine-tuned interaction prototypes, front-end development, style guide and content refinement all come into play. And once the product hits the market, its success needs to be measured to verify that it delivers on the promise of the original hypothesis. This measurement and observation is the connection that fuels the cycle, feeding he team's ongoing insight and understanding of the customer.

Any of these methods, workshops, deliverables, or techniques can fit into an existing Agile working framework with a little focus and collaboration across the team.

Having different tools for different scenarios helps keep my work sharp, delivering the most value to the business in the most efficient way possible.

Dealing with the real world

In reality, not every project will have the opportunity to engage all these stakeholders all the time.

It is common, but not ideal, for a designer to arrive in a project in Phase 3: "We know what we want, just make it happen." And you might see a team slice off any plans to learn from the product in market. The problem here is that the designer might know how to do what you want, but they aren't going to be as effective if they don't understand why you want it.

It's a little better if a designer can enter the process at Phase 2: "We figured out the situation, design a solution." Sometimes, some of the steps, like validating an idea before executing it, get left out. The issue here is that a designer might be defining a strategic solution without a full understanding of the context surrounding the problem.

Ideally, a designer is an active participant in Phase 1: talking to people who will ultimately be affected by the output of the design effort imbues a personal responsibility to deliver an effective and valuable solution. Involving a designer at this step reduces the risk of misdirected effort.

Even if starting a project already in a execution phase, I think it's still possible to do good work. Entering a project late in the game can give a designer the opportunity to prove their mettle to other stakeholders and partners, leading to better opportunity on the next project to demonstrate the value of good design.

Designing with AI (some day)

A few years ago, when we first got an Alexa-bot, I wanted to do a little test. My daughters were about 9 and 5 at the time, and I wanted to see how they reacted to it. I showed them how to give the cylinder its basic commands, playing their favorite music and telling us what the weather would be for the day. They picked it up right away, although the 5-year-old's higher voice didn't always catch the robot's ear. But, more importantly, I noticed something that I always found very telling, even if I can't put my finger on what it means...

I made sure to refer to Alexa in a generic way, "it." My daughters immediately, called it "her." It's not a leap, probably just anthropomorphizing based on the default voice, however I was struck by how easily and quickly it happened. They didn't have any hesitation in referring to this black plastic cylinder in the same fashion as a human being.

Who's there?

This has long left me curious about the potential for our interactions with AI. IVRs have long been commonplace and chat bots are facilitating an increasingly more robust interaction between companies and their customers. Every call that starts with "You have reached the [company] automated system" or IKEA's "Anna," the prototypically Swedish personality of their chat bot. Something I think I took for granted was the notion that interacting with a robot could be incredibly helpful and efficient, but I took for granted the idea that I would know I was doing it. Then this appeared...

https://www.youtube.com/watch?v=D5VN56jQMWM

Last May, Google's CEO demonstrated how Duplex AI takes a command from a person "make me a haircut appointment on Tuesday morning anytime between 10 and 12," and then calls a hair salon and sets up the appointment by using a lifelike voice and interacting with a person. The crowd goes wild.

I wasn't a fan.

What I saw was a non-consensual interaction with an artificial intelligence system. It was, at the least, rude. For example, when someone speaks on the phone, isn't is customary for them to identify themself? If you take a call from someone and they don't identify themselves, aren't you suspicious? And if the woman running the hair salon were to ask, "to whom am I speaking?" how would the Googlebot answer?

We didn't get to find out in that clip, and these are knowable and addressable problems, but it made me uneasy that without this customary courtesy in place, the engineers in attendance still considered it a triumph.

This is not to take away from the truly remarkable technical achievement this phone call represents, but it reaffirms the stance I have had on AI for a long time:

I am not worried about the emergence of AI, I am worried about the implementation of AI in a systemic technical culture that moves fast, and with a certain ethical carelessness.

Unclear anxiety

Among designers, I have been apart of conversations that are a bit anxious about the future of AI from multiple directions.

• So are we designing conversations with robots?
• Will a robot take my design job?

I can confess: I have has some of this same anxiety once in a while and a lot of it comes from a lack of knowledge. Reading about AI is somewhere between a deep dive into a technical black hole and an over-cologned sales pitch about the value it will deliver.

Getting some clarity

I had the pleasure of attending a workshop at the ServiceNow office examining the still-to-be defined future of AI's impact on the design industry. The workshop was primarily run by Cody Frew a Sr. Manager of User Experience Design for ServiceNow’s Platform Tools, and Laura Coburn, a Sr. UX/UI Designer for ServiceNow’s Vulnerability Management Product.

It was a pretty interesting session! They covered a little history on AI, where it came from, where it is today, and where it's headed.

In a light summary, we looked at the history of AI's emergence which is full of ups and downs. Then understanding AI as three things...

• Artificial intelligence, the interactions that act like people
• Machine learning, the ability for machines to identify patterns in ways people can understand
• Deep learning, the ability for machines to develop insight into situations, think: robots that win at chess or go

(It turns out, there is a fourth layer, neural networks, but that's a conversation for another day.)

Then the conversation shifted some of the ways that AI is already percolating into the design community and processes. For instance, AirBnB's sketch-to-code uses computer vision to translate sketches from a whiteboard into components in their design library. Netflix uses some really complicated and really fascinating algorithm tech to generate all those placeholder images that they then test a zillion times over to entice you to click on them. To some extent, Netflix designers would shift roles. Instead of mocking up title cards, they would allot more time to evaluating and tuning the results of the algorithm's output while, in a new way, partnering with the tech, to introduce new visual concepts back into the scope of the algorithm. When machine learning merges with high-speed automation and human creativity, the role of the designer can shift.

So where else will there be automation? And where will the automation affect people's jobs?

The workshop guided us through a skills assessment, rating ourselves on a scale of 1-5 in various different design skill areas, each with specific tasks or areas of knowledge. We filled in a diagram, 1 a the center, 5 on the perimeter, creating a spider graph (or RADAR graph or whatever you want to call it).

My assessment, in all its self-biased, self-reported glory.

Once our self-assessments were ready, the speakers passed out some delightfully retro transparencies to lay over the skills assessment. The transparency represented how each area of knowledge is split into specific capabilities, and how each skill capability presumably stacks up in a world where AI has permeated the tools and skills of designers.

With the future-state transparency in place. So shiny!

In short, the future state of design is mostly focused on wrangling people through workshops, research. That felt good for me. Interaction design, prototyping, and writing would go through some realignment, which I found interesting.

There was a fair amount of conversation about the reduced need for pixel-perfect specs and front end web dev, identifying that the bots will take this over in spades, but that the skillset will shift towards information visualization, something that is still nuanced. There were some visual designers and front end developers in the room that didn't seem happy about that.

Does it change the process?

This workshop left me to evaluate how the design process would change with the introduction of AI. Naturally, there's an impact, but where? Here are some hypothetical high-level areas where the design process could be affected by AI in the near future.

Design research: Participant recruitment could be made more efficient by using AI to identify candidates for participation in research. ML would identify behaviors across products through the deep analysis of retargeting tracking and other data. Once consenting participants are identified, they could opt in to having their smartphone collect ambient data, communicate with other enabled devices, forming anonymized webs of tracked behavior data. Behavior models could be augmented to create norms of probably interaction based on user decisions in situations across different media, previously untracked.

In addition to participant engagement, existing customer contact could be mined at new levels. For instance, natural language processing could cull through recordings of customer service calls, revealing trends and attitudinal metrics. Currently, customer service reps have a few seconds to give each call a single disposition code, however some data always fall through the cracks since a call can cover multiple topics. Calls could be more accurately re-dispositioned, rated in tone, and more accurately tied to business outcomes.

Problem definition and visualization: Based on trends found when modeling user behavior data a system that could identify user personas and their interactions and ultimately identify where obstacles may be causing problems for those personas. Drafting a user journey could be automated or accelerated by a smart visualization tool that is able to layer multiple channels of interactions into a set diagramatic visualization language A sketched whiteboard of a user journey or other workflow could be translated using computer vision and digitized into a workflow diagram (sort of like Lucidcharts on steroids)

Prototyping: Sketched UI designs could be realized against a fixed development framework, like Google Material. This means a designer could work with stakeholders to rapidly sketch options for their product challenges, while turning them into developed prototypes. Additional gestures or visual shorthand would be introduced to program interactions into the prototype. Once the prototype is in place, it could be 'dry fit' against the behavior models culled through ML, showing the likelihood that a user completes a task as designed.

Ethics: Many discussing the introduction of AI into the design and technology fields raise ethical concerns, but few are proposing solutions. I see two key areas for improvement.

First, with an advanced understanding of criminal and unethical behavior data, create an algorithm or other programmatic method that can be used to automatically QA a product for potential abuse and systematic biases of the humans and algorithms involved. Use AI to protect against the risk emerging in AI.

Second, reaffirm human understanding within the design process, to reality-check design work each step of the way. Designers (and all members of the product development disciplines) will need to incorporate a new question into their acceptance criteria and do so further upstream, repeating the question throughout their process: How can someone use this product for harm? Our collective ingenuity often outsmarts the systems we put into place, but our vigilance can overcome it.

We'll see

There are many more areas that have potential to be augmented and accelerated by AI. More importantly, just writing the description above, I was immediately stricken by how potentially invasive it could be, allowing private entities like corporations access to incredible amounts of data, with the ability to tie that data together in ways never before imagined. At a minimum, when developing products using AI, we simply must inform people that we will be using this technology, that we will be combing their data in new ways and connecting it to other data. Informed consent will be critical as experimentation will become increasingly consequential. Checking and rechecking our work against negative unintended outcomes will become just as important as conceptualizing a new product idea.

It is also important to understand that these abilities will not be evenly distributed in the world. Some companies, people, governments, or communities will have access to remarkable power of artificial intelligence. I am not confident that all of those early innovators will be sensible in implementing this technology. Hopefully, we can support each other in building out our own understanding as a community.

My kids, who didn't hesitate to anthropomorphize a robotic cylinder, are the first generational wave of pioneers in this new frontier that we will be building for them. Hopefully they are the first recipients of a understanding, and not the first wave of victims of our hubris.

Ethics in Design

You have seen it

When I started in the design field, I had trouble finding a job that was a good match for both my entry level skill set and my hunger to do exciting design work. At that point, getting steady work took precedent and I took a job with a company that brought with it some ethical baggage. Am I sure I want to do this? What about what I had heard in the news about this company?

At the end of the day, I simply needed work and while it wasn't exciting and the company raised eyebrows with some, I figured I would get from it what I needed: experience and a paycheck. I compromised.

Later in my career, I was freelancing at a senior level and had the immense privilege of choosing between different clients. I looked at each and asked "if I do my job, what happens?" This lead me to working with a company whose work significantly reduced carbon emissions in the environment--something extremely important to me. I didn't have to compromise in taking the job.

Later, while working at a company that had an altruistic mission, I was faced with some product experience decisions that could increase some risks in the sales process of the company's most profitable product. I negotiated working scenarios where we had to strike a balance between a sales-focused experience vs a customer-focused experience. In other words, do we speed someone through a transaction as quickly as possible, or do we hold their hand through the process, explaining and re-explaining every step of the way even at the risk of them abandoning the transaction.

I remember arguing that a product might be creating risky situations and feeling as though I was the only one. I was going up against the rest of my product team, our bosses, company leadership. I had to make peace in the moment--how was I going to move forward in a way that I could live with but still execute something that the company could benefit.

There were times when I compromised, and times when I didn't.

As a society, we're still figuring out the potential reach of digital technology, and these lessons are emerging in each meeting, critique, and office debate.

As a designer working on that technology, your ethical standards will be challenged at some point. It may happen before you even start the job, as you consider whether to do work at a company. It may happen when debating the strategy for a new feature, determining whether you're executing on what is important. It may happen when working in the details of a design, determining if your work will influence people's behavior in a way that is helpful or harmful. It will happen.

So what do we do?

First off, it makes sense to know where you stand. Know what is important to you. Ask yourself the question, "if I do my job, what happens?" and make sure the outcome is something you can be proud of. If that doesn't work, make sure it's something you can live with. And if you can't do that, look for something else.

But what about when we're doing work, discussing product strategy with our team, or evaluating screen-by-screen experiences?

This is where we could use some guidance.

Looking to others

Other professional fields have dealt with this. Not surprisingly, the fields where there is an immediate risk of harm are where the ethical standards have become the most apparent. The Hippocratic Oath is an example of a set of values for doctors. The oath originates in ancient times, however the modern version of the oath was developed in 1964 by Louis Lasagna, Academic Dean of the School of Medicine at Tufts University:

I swear to fulfill, to the best of my ability and judgment, this covenant:
I will respect the hard-won scientific gains of those physicians in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.
I will apply, for the benefit of the sick, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.
I will remember that there is art to medicine as well as science, and that warmth, sympathy, and understanding may outweigh the surgeon's knife or the chemist's drug.
I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a patient's recovery.
I will respect the privacy of my patients, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of life and death. If it is given me to save a life, all thanks. But it may also be within my power to take a life; this awesome responsibility must be faced with great humbleness and awareness of my own frailty. Above all, I must not play at God.
I will remember that I do not treat a fever chart, a cancerous growth, but a sick human being, whose illness may affect the person's family and economic stability. My responsibility includes these related problems, if I am to care adequately for the sick.
I will prevent disease whenever I can, for prevention is preferable to cure.
I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.
If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of healing those who seek my help.

"The Hippocratic Oath Today" NOVA, PBS

The oath is remarkable in its brevity, breadth and depth: education, treatment, bedside manner, humility, privacy--it's all in there. One of the oath's strengths is its emphasis on the relationship between the doctor and the patient. However, there is no mention of how to run the business of medicine, where so many challenges lie in today's society and economy. The is no mention of pharmaceutical company influence, pharmaceutical pricing, insurance markets, or the impact of for-profit corporations on patient care.

As designers, it is also difficult to relate to the relationship that a doctor has to the patient: who are we in this construct? The doctor? And who is the patient? A client company? The customer?

But how bad can it get? Amazingly bad.

Some answers may be found when branching out out from medicine itself to medical research, where another advisory document acts as a guide for ethical standards. First, a little history:

Starting in 1932, a group of African-American men were placed into an experiment conducted by the US Public Health Service and Tuskeegee University, a historically black college in Alabama. The goal of the study was to research the untreated effects of syphilis until the time of a person's death, however this goal was not revealed to the men participating in the study. Out of the 600 men, 399 had syphilis at the time, while 201 did not. The men were given free medical care and other benefits for participating. They were told they were being treated for 'bad blood," a colloquial term used to refer to any manner of ailments, though they did not receive the correct care for syphilis.

The men were told that the study would last only six months, but they were ultimately observed for 40 years, living with the disease without their knowledge, and dealing with the consequences. The experiment was designed in a way that it could not be considered complete until all participants had died and been autopsied.

Even when confronted with accusations of unethical practices throughout the 1960s and 70s, the Centers for Disease Control, which had taken over the study, insisted on continuing the work for the sake of research. The CDC's efforts were supported by prestigious organizations such as the National Medical Association (representing African-American physicians) and the American Medical Association.

Ultimately, an investigator for the US Public Health Service in San Francisco,  Peter Buxton, took the story to the press. Ted Kennedy called for hearings and in 1972, forty years after it had began, the study was finally terminated. Only after a lawsuit from the NAACP was a compensatory settlement was issued to the remaining survivors and their families.

It is considered the paradigm of unethical experimentation in American history.

An ethical response

In July of 1974, in the wake of the scandal, the National Research Act was signed into law, creating the National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research. The commission was formed to analyze research practices involving human test subjects, assess the risks of these practices, provide professional ethical guidance, and deliver a definition of informed consent for each research setting, especially for vulnerable populations. Their findings and guidance were provided in, The Belmont Report, a 10-page guide to conducting research on human beings.

OK, this is where it gets interesting for designers again.

The report starts with defining medical practice vs medical research. Practice is work done solely to improve an individual's wellbeing. Just because someone deviates from conventional practices doesn't mean they're doing research, even if they call that work "experimental." The definition of research quoted in the report gets interesting....

...the term "research' designates an activity designed to test an hypothesis, permit conclusions to be drawn, and thereby to develop or contribute to generalizable knowledge (expressed, for example, in theories, principles, and statements of relationships). Research is usually described in a formal protocol that sets forth an objective and a set of procedures designed to reach that objective.

The Belmont Report, Boundaries Between Practice and Research

Most of our work as designers of digital products and experiences bears a striking resemblance to research in this case. We are doing work to hypothesize, test, and learn.

To drive ethically effective research, the Report advises three core ethical principles:

Principle 1: Respect for persons

The respect for persons comes in two parts:

1. That people are autonomous, capable of determining personal goals and acting with self-determination
2. That people who cannot act autonomously deserve protection

In our field as product designers, respecting the autonomy of individuals is of paramount importance. The autonomy of individuals can often be overlooked or de-prioritized in favor of the collective interests of a business as expressed through their own internal metrics for success.

Principle 2: Beneficience

Beneficience is defined as an act of charity, mercy and kindness as an extension of a professional practice (I had to look it up, too). As such, the report calls for all research efforts to do no harm while maximizing possible benefits. Ultimately, this strengthens the commitment to the individual involved, obligating any researcher to knowingly assess the risks that will be posed to a test participant.

Principle 3: Justice

The Report poses the question clearly: "Who ought to receive the benefits of research and bear its burdens?" Historically, the burden of medical research subjects fell to those who simply couldn't say 'no,' whether they were hospitalized, imprisoned, partially or fully incapacitated. This can not stand. Screening test subjects requires constant scrutiny to mitigate biases and assure that vulnerable segments of the population are not being targeted.

Advised application of these principles

The report also advises the application of ethical principles to research as follows, paraphrasing here:

1. Only proceed with informed consent. This means that participants have access to and comprehend all information about the experiment, then volunteer to participate.
2. Take measures to assure that the research is justifiable. Assess the probability and magnitude of risks, to the best of your ability, against the possible benefits of the research outcome.
3. The selection of research subjects should be consistently evaluated for fairness in mitigating bias and eliminating the odds of taking advantage of vulnerable populations.

Taking it on

I found the Belmont Report fascinating. I wanted to distill it down into principles that can be woven into parts of the design process. Having experienced ethical dilemmas concerning the impact of my job, the role of a product, or the unintended consequences of a feature at various parts of my career, I wanted to explore how an ethical framework could be applied through the design process.

I also wanted to take a moment to consider that the label of 'research' applies to more than one facet of the design process, and the application of these ethical principles would vary accordingly.

In interpreting the Belmont Report's principles for use in a product design context, I settled on these three:

1. Respect people as individuals
2. Provide more benefit than harm
3. Examine any affected population

And in practice

1. Utilize informed consent
2. Evaluate the benefits of the research
3. Select participants fairly

These principles sound great in a blog post, but do we need to take this into account for product design?

So what about us?

As designers of digital products, we're loathe to think that anything we would do would approach the harm of the Tuskeegee experiment. But we should be wary of letting hubris set in.

It is well-documented that experimentation with Facebook's feed may have influenced the emotional state of approximately 689,000 users, without their knowledge, consent, and without total scope of the potential impact.

Metrics used to define success of an app or site tend to lean towards engagement behaviors, such as daily active use, time on site. Engineers and designers have found that getting the user addicted to the experience of the product is a surefire way to boost their internal metrics. Even the inventor of the infinite scroll, Aza Raskin, admits he didn't consider the far-reaching outcome of that feature.

But, he said, many designers were driven to create addictive app features by the business models of the big companies that employed them.
"In order to get the next round of funding, in order to get your stock price up, the amount of time that people spend on your app has to go up," he said.
"So, when you put that much pressure on that one number, you're going to start trying to invent new ways of getting people to stay hooked."

Aza Raskin, interviewed by The BBC

But here's the hard truth: there will be no peace. There will be no perfect state of balance between ethics, design, and commercialization. This is a challenge of progress, not perfection. So how do we make progress towards products that engage but do not substantially risk harm?

Finding a way forward

I have been working with user experience design in an Agile environment for nearly 15 years. In that time I have seen an increasing commitment to product design in a manner structured around the scientific method, especially developing a hypothesis for testing.

A sampling of the 160,000,000 results for query: design is a hypothesis

The principles of ethical research stated in the Belmont Report can be carried into product design work in two key areas: design discovery research and the product design process.

Do design research

There is a relatively clear parallel between the process of research described in the Belmont Report and the practices of design research in the discovery phase of a given project.

Design discovery research is predicated on reaching the right audiences, honoring the complexities of their life experience, and proposing beneficial solutions.

The ethical crisis facing product teams emerges when considering whether this research is happening at all. Many teams move forward without discovery research, instead using the experimentation and validation of the product as their research framework, whether it's called that or not.

Having no familiarity with the human beings on the receiving end of a product, viewing them purely as consumers and their use of the product as their only value is a fundamental departure from both the Belmont principles and basic user-centered design practices.

This absence of understanding has also become so common as to the point of normality, not only in the big companies highlighted above, but in the countless smaller companies fielding product teams that are under-served, under-resourced and under-powered. The research process is overlooked or undermined on a regular basis on these teams.

I would also argue that viewing your customer or audience in purely quantifiable means additionally diminishes the role of their humanity, further narrowing and biasing any perspective on them as a person.

Putting out ethical fires

When taking a course of action to improve the ethical outlook of your team, the first step is recognizing them and, most importantly, addressing them while they are in progress. Lu Han, Product Designer for Spotify makes an excellent point:

"One way to recognize when a trade-off is being made is to pay attention to the language being used."

Designing for Tomorrow - A Discussion on Ethical Design, Lu Han

She goes on in her article to highlight phrases like "just put it in the T&C" that are warning signs of potential ethical risks. The sad part? The phrases she identifies have been VERY COMMON.

Opportunities for built-in ethics

The time has come for us to realize that ethics is simply not too much to ask.

Consider this: in response to the Tuskeegee scandal, the Belmont Report did not advise spot-treating ethical violations as they happen, but instead recommended firmly-rooted principles for creating ethical standards.

To ingrain ethical standards into the practice of design, there are two larger points of integration, design principles and Agile development.

Design principles

In the technology sphere, design principles are fundamental ideas used by design teams to inform a standard of practice. These typically revolve around visual characteristics...

Made up principles for a design team:

• Unified: provides a cohesive experience that clearly communicates the brand to the user
• Simple: never distracts the user with anything unnecessary
• Useful: provides necessary functionality
• Delightful: sparks joy for users, turning ordinary tasks into a delight

I just made these up... but they sound so familiar somehow, right?

The idea being that the team, when working, would critique their work against these principles and determine if it is on par with their standards. But you can see how superficial these principles can be, focusing on lightweight form and function, and avoiding deeper product considerations.

This presents a key opportunity for inserting ethical standards as design principles, and integrating them into the design team's day to day considerations for all their work.

That would be nice. But design principles have an Achilles heel. Two of them actually.

First, the principles are aimed at the designers. But the designers aren't the only ones making the decisions that can have a negative impact the product and on the customer. Product managers, software engineers, QA engineers, salespeople, customer service representatives, the General Counsel, the CFO, the CMO, the CEO... lots of people are making decisions that have an impact on a give team's product and the people who use it. It's just unfair and unrealistic for designers to be the only guardians of good in this equation.

Secondly, when the design team is crunched for time, under-resourced, and on deadline, sometimes principles get overlooked entirely. I don't like to say it will happen, but it can happen.

Solving these problems means that ethical commitments to design have to happen on multiple levels, ideally with commitment from leadership.

Design critique towards ethical principles

As work is in progress, design feedback is a critical refinement tool. Feedback should already avoid reactionary and directive feedback, favoring a more productive critique structure:

If your objective is to achieve _____, then doing _____ does/doesn't meet that objective because ______.

... and explore introducing an additional step in the process to highlight ethical risks.

If your objective is to achieve _____, then doing _____ could create an ethical risk when ______.

The Belmont principles of respecting individuals, beneficience, and justice would provide fundamental guidance in these scenarios.

• ...this doesn't take into account the customer's intensions...
• ...this has a consequence of XYZ, whether intended or unintended...
• ...this will create a disproportionately problematic situation for XYZ vulnerable population...

.... and so on.

Frame the critique to consider both the quality of the work and the outcome of its execution, whether that outcome is intended or not.

And this scrutiny extends to all processes and materials within the design process.

Additional ethical enhancements to agile methods

Beyond situationally addressing ethical issues or as they come up, and carrying principles as a design team, there remain opportunities to apply ethical principles into the product design process by interfacing with the tools and ceremonies employed by other members of a typical product team working in an agile environment.

Setting ethical objectives

The objectives for a project can take different forms depending on the operations of the team, including team-level OKRs, problem statements, or as narrow as a hypothesis for an individual project. Have these objectives been considered against ethical standards?

Ethical prototyping

As a design hypothesis is refined and designs are developed and refined through critique, the work can enter a prototyping cycle for evaluation, testing, and rapid validation. The prototype itself can leverage a design library that has been refined to be accessible for broader populations, while testing script and participants can be formed under ethical research standards. Additionally, as a team, when the prototype experience comes together, ask yourself: could this have unintended but serious consequences? At a minimum, write them down and discuss trade-offs. Even better, consider alternatives that mitigae that impact.

Ethical sprint grooming

In working with my development teams, I treat sprint grooming (previewing and evaluating upcoming user stories) as a design critique with a technical audience. I have used the opportunity to bring them into the project; sharing research findings, gaining additional buy-in, and presenting prototypes as design work that will be produced.

In many cases, there are trade-offs at this point, cutting features in favor of speed to market. With a new focus on maintaining ethical standards, this dialogue opens up an opportunity to examine these trade-offs from a new angle, evaluating their impact and unintended consequences.

Depending on the trade-off, there might be a showdown at this point, and that is an opportunity to clarify and refine. Don't fear the conflict, open to the opportunity.

Ethical acceptance criteria

Acceptance criteria is a critical collaboration area for successful collaboration between development and design, and it is often overlooked as strict technical requirements. Recently, on my team, we instituted visual design

But here's an idea that we can explore: augmenting the product design process by introducing the Belmont principles as a rubric for quality could protect against ethical risks.

I can tell you, I don't know what this would look like. But it's worth a shot. Try starting with some ethical Gherkin language.... GIVEN a user knows they are trying this feature...

Ever forward

I do not think this will improve overnight. Or even in a week. Or a month. And i don't think it will even become a movement. It's only a matter of reaching forward, reaching higher, one project at a time, one company at a time, one designer at a time, one team at a time. I would challenge you and your team to start small, but aim high.

Introduce these principles to your team:

1. Respect people as individuals
2. Provide more benefit than harm
3. Examine any affected population

Start with a critique session. Then another critique. Then another. Push your work and your team's work with higher standards.

Or, start by kicking off a project with a question for stakeholders: are there any unintended consequences that we should keep in mind that may affect a certain population in a negative way?

Try evaluating objectives against longer-term outcomes, looking for potential unintended consequences. For each intended objective outcome, ask "then what?" and "then what?" and "then what?"

But most importantly, don't give up.

When I started my career, and I was in a position whee I needed to compromise my beliefs in order to get and hold a job, I hated hearing people in the profession encourage me to "stick to my guns" and never compromise my beliefs. I thought that was so arrogant, because the pressure I felt to get and hold a job was massive.

So I want to be clear, I don't expect sainthood from professionals, but I do expect quality. And the scope of quality is growing to include an ethical and principled perspective.

Please feel free to reach out to me with your thoughts. This is, and always will be, a work in progress.

###

NOTE: I first heard about the Belmont Report from awesome service designer Sarah Fathallah, in her recent interview in Communication Arts.

Correction: I misstated that the Tuskeekee study participants had been unknowingly infected with syphilis as part of the study. The post has been updated to reflect that 399 of the participants had syphilis, and clarified the nature of the care that was administered during the study. Many thanks to reader Kit Oliynyk for assistance in these corrections.

Engaging the Sales Team for Design Research

 When designing in enterprise and b2b environments, it's tempting to believe that the customers are easy to get to for the purposes of research, feedback, and product development. I mean, our sales and customer support teams talk to them all day!But that's not the case, not by a long shot. Connecting with business customers is an under-appreciated challenge unto itself, even on the best of days. For starters, your customers are business customers. They understand that their time is valuable--because they're being paid to be there! Time is money! And the time and money spent doing their job don't have a vested interested in helping you do your job.On top of that, you probably have people at your company who go by the name of Account Management, Customer Success, or just Sales (which I will collectively refer to as 'sales reps'), and they probably think talking to customers is their exclusive domain. You have to take a minute to appreciate their perspective.Your sales rep probably hasn't worked in the product development process before, so they don't have a reason to believe it would be useful to them or to the customer. If your sales rep thinks bringing you into the mix can jeopardize their relationship with their customers, then it's a no-go.The last thing your sales rep or your customers needs is some nerd from corporate talking tech and design or defending defective design work, wasting everyone's time. Sales reps need a reason to believe this misstep won't happen.I’ve been down this road at a company that works in financial services (talk about a 'time is money' mentality--it's called interest). Our B2B customers were home improvement contractors, who range from small, independent and sometimes un-tech-sophisticated contractors to mid-size contractors who have sometimes-sophisticated operations and even in-house dev teams.For us, engaging the sales team to help with product development took about 18 months, which is not quick. But in that time, we went from from "Why should I let you talk to my accounts?" to "hey, can you talk to one of my accounts? They have some feedback." That was a tectonic shift in perspective and a long, non-linear journey that often felt like two steps forward, one step back.The nuts and bolts of who to talk to when, what meetings and conversations to have, etc, tends to vary from organization to organization. In the meantime, here are a few lessons learned from my experience, grain of salt optional:

Get insight from sales reps themselves

To start, I interviewed a lot of our sales reps as proxy users. Many of our sales reps used to be the kinds of contractors they now service and they were themselves SMEs in the field. I got their attention with pre-release prototypes. From this, I was able to get general (admittedly biased) market discovery. Perhaps more importantly, I showed them that I valued their opinion and experience.

Establish a feedback loop

Early on, my team was always chasing after the sales team, trying to get to customers, and getting nowhere. Then, we learned that the sales team had to write up weekly reports about their portfolio and include any “market color” that they found along the way, which included a ton of valuable input for our product team--even feature-specific suggestions from customers. Our product team had no idea these reports were even happening. Once we got on the distribution list, we were drinking from the firehose. The reports provided good starting points for digging into problems or developing new features, and reaching out to those individual reps.

Close the feedback loop

This is really hard.One of the most frustrating things was demoing a prototype of a new feature, our sales team totally buying into it, and that feature either taking a really long time to get to market or never getting to market. This was a major knock on our credibility and strained the relationship.You have to understand that sales happens in real-time. There are no sprint cycles, or product releases, just relationships that ebb and flow based on current performance and opportunities. As a result, a sales team can be a pretty what-have-you-done-for-me-lately organization.On the other hand, when you do get their feedback, you document that you understand it, you demo an update, and you come back to them with the date it will be in market in a timeline that benefits your customers, you'll be like a conquering hero. "Someone finally listened!" was simultaneously flattering and depressing.

Find the squeaky wheel

One of your sales reps has a customer who is always making suggestions. You need to use your feedback loop to find who that is. That customer will be more likely to find value in spending time with someone from your product team, participating in research, and being heard. Conversely, it’s worth acknowledging for your sales team most of your B2B customers will think time spent with the product team is value they are giving to you.

Commit to being the face of the product

Sales is a face-to-face business. On top of that, many of our sales reps were on call virtually 24/7, taking calls from customers at all hours. When I presented some prototypes of upcoming features at one of our regional sales meetings, I ended with a slide that was only my name, my cell phone number, and my email address. I told them that they can contact me at any time. They never did call, but they sat up and noticed. It connected with them at the time because I was speaking their language and meeting their level of commitment helping them and our customers.As hard as it can be to cross this chasm to get to your customers, you gotta do it. You have to get out there. The sales reps that have close relationships with your customers can be one of your most powerful allies in achieving your goal of greater customer insight. It's a key way to get true feedback from enterprise customers. And it's also critical to helping your internal team understand they they are not the customer. Connecting with your sales team will help you in both the short and long term by gaining valuable insights and growing your relationship with the folks that talk to your customers day in and day out.

A Sample Design Collaboration Cadence

In order to maintain a decent level of collaboration within a design team, while maintaining a productive pace, and keeping transparent about upcoming roadblocks and needs for solutions, and finding opportunities to support each others in our design practice.... I ended up with a cadence of quick and straightforward cadence of check-ins and working sessions.This assumes that the members of the design team are not embedded solely with individual development teams, but are shared as a committed resource. Individual designers will be dedicated to team-specific meetings like stand-ups, groomings, etc, as necessary, depending on your organizational structure.

• Weekly, 30 min: Team meeting
  • The design team as a whole meets to check in on any news or updates that stem from higher organizational issues and raise any concerns for their own work.
• Bi-Weekly, 30 min: 1:1s for personal development
  • Could be weekly if needed, of course
  • Opportunity for mentorship and management, pursuing opportunities for growth. As a manager, I'm asking these questions:
    • What is going well? 
    • What could be going better?
    • What do you want me to do more?
    • What do you want me to do less?
• Bi-weekly: Team critique sesh
  • Designers take the initiative to set the stage for collaboration on their work through critique or other exercises
• Monthly: 1/2 day: Team boost sharing skills or presentations
  • Opportunity for designers to share more deeply and broadly with the team, showcasing skills, providing training to others, presentations etc.

A Design Practice

Over the course of my career, a framework has started to come into view for a establishing or augmenting a design practice. The framework has three key ingredients:

• Craft: What do you do?
• Infrastructure: What do you use to do it?
• Personal Growth: What are you getting out of it?

Attention to these three areas provides a foundation that is both flexible enough to work in organizations of different sizes and workflows, but clear enough to stay relevant under different methodologies.

Craft

"What do you do exactly?"This is the collection of executional tools we have at our disposal. This includes typical UX activities like card sorts, personas, prototypes, and critique, among others.

• Specific executional methods: typically the work that goes into design deliverables; personas, prototypes, card sorts, sketches, etc. There are dozens of options, appropriate at different stages in of a given design project.
• Participatory workshops: tactical, focused exercises such as kickoff meetings, research interviews, sketching sessions, etc.
• Processes: Executional activities and their resulting output is bundled into a process such as a Design Sprints or Lean UX sprint schedules, which provide a linear path for interactive discovery, design, and validation.
• A commitment to quality: throughout the above practices--and in many ways because of the above practices--there is a sustained commitment to quality. A thorough and focused practice keeps a designer performing at their best.

Infrastructure

"What do you use to do it?"This is typically what we would refer to as design tools; the software, team structure. But this concept goes further to include conceptual infrastructure like design principles that provide thematic support to all the aforementioned methods.

• Organizational infrastructure: team organization through clearly-defined team structure and roles--there's a lot more to this, of course.
• Technical infrastructure: software such as design and prototyping tools, file sharing, communication platforms, all of which facilitate the delivery of good work; also, reusable technical assets associated with style guides, templates, patterns.
• Facilitation infrastructure: provided through the use of meeting agendas and other materials that are re-used in workshops or other sessions--key for healthy engagement with stakeholders
• Thematic infrastructure: tenets such as principles, values, and methodology; tools that guide the team through tough decisions and elevate the team's thinking around solving challenges. Principles are the outcomes we seek in the work we create. Values are describe how we want to work. Methodology is the school of thought that ties together the methods at use on a project.

Personal growth

Everyone on the team is advised to approach every project as an opportunity for personal growth. I have found, historically, that not very many people look at their work this way, as an opportunity for growth. But those who do benefit both personally and professionally."What are you getting out of it?"

• Preferably, this starts with an introspective self-assessment to understand an individual's strengths and weaknesses and understand the need for addressing these opportunities
• Each project should be evaluated as a growth opportunity
• What opportunity do you have to improve your "on-screen" skills, the nuts and bolts of the design process?
• What opportunity can you find to improve your "off-screen" skills, your ability to work with stakeholders through facilitation, active listening, salesmanship, critique?
• Not every project has to be a growth opportunity, but we keep revisiting this as a means of maintaining that trajectory

Putting it in motion

High-quality design methodology, both in process and execution will always be critical to any high-functioning team. An efficient infrastructure liberates the team members from the burden of re-building and wrangling repeatable assets, cuts down on variability and error within the product experience, and removes the cognitive burden associated with smaller design decisions from the team while the work is in flight. But none of this is worth doing if it is not a vehicle for one's personal growth. We spend more of our waking day working than anything else and it should ultimately be a nourishing and rewarding experience.So I'll leave you with a hypothetical example of how a team would carry this through when starting a project.Let's say you start a project with a kickoff meeting (method). In this practice, the team would have a pre-set agenda for a kickoff meeting (infrastructure). The agenda had been tuned over time to assure that three criteria were met:

• Define the problem space and objectives
• Select design methods
• Make a commitment to complete the work

In the kickoff, the team works together to get a sense of what they need to do for the project. They refine and agree on a problem statement (method) and an objective that they aim to meet (method).Next, the team assesses what methods they want to use to reach that objective. Is field research the best way to get the qualitative data we need? Is there existing data from our analytics platform? Is Should we do a sketching session with the team to develop a direction for a prototype? Should we use the Design Sprint methodology for this problem?Finally, there is some assessment of the path forward, an estimation of how long it will take and, based on the needs of the project and the strengths and weaknesses of the people on the team (personal growth), a determination of who should do the work. So, if it's a mobile app project and a associate designer is looking to expand their repertoire with mobile, they could take the project on with a commitment from a senior designer to advise and mentor along the way, helping them ensure that the aligns with the team's values and the work is in line with the team's design principles (infrastructure).Naturally, once the team adopted this perspective, all their dreams were fulfilled!