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.
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...
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).
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.
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:
- That people are autonomous, capable of determining personal goals and acting with self-determination
- 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:
- Only proceed with informed consent. This means that participants have access to and comprehend all information about the experiment, then volunteer to participate.
- 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.
- 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:
- Respect people as individuals
- Provide more benefit than harm
- Examine any affected population
And in practice
- Utilize informed consent
- Evaluate the benefits of the research
- 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.
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:
- Respect people as individuals
- Provide more benefit than harm
- 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 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!