Hi ! I am Hari Subramonyam and today I am going tell you about how collaborative software
teams apply human-ai guidelines in their practice.
This work is in collaboration with Jane Im, Colleen Seifert, and Eytan Adar from the University
of Michigan.
Over the last twenty year, we have gotten really good at incorporating human centered
design into software engineering workflows.
We have created new roles and expertise and developed tools and processes to drive software
design based on human needs.
User experience designers who are experts at understanding human behavior, usability,
and design work with end users to identify their goals and challenges .
They then create software design solutions and hand off those specifications to engineers
who are trained in software programming and can build systems based on requirements.
In such workflows, the user interface acts as a natural seam for designers and engineers
to coordinate.
Given their differing expertise, the practice of information hiding, and abstraction allows
them to work efficiently.
That is designers don’t share low level details such as notes from user observation,
or prototype alternative.
Similarly, engineers don’t need to share technical details about how they will implement
the design.
There exists a separation of concerns between design and engineering practices.
But this approach is problematic for human-centered AI design.
In this work, we investigate how might AI and UX teams integrate concerns across disciplinary
boundaries to align human and AI needs.
In a first study we collect and analyze human ai guidelines to identify collaboration requirements
Using the results from our analysis, we interview software practitioners about their current
practices.
Companies like Microsoft, Google, and Apple are putting out design guidelines and best
practices for human-centered AI.
We collected around 280 design guidelines and conducted an affinity diagramming exercise
to identify key components and tasks in designing ai experiences.
We found that the guidelines cover both UX and AI design.
They make recommendations for centering people in the design of AI’s training data, model
behavior and implementation, as well as in designing the user interface and interactions.
All these layers need to align with how people think about tasks, their expectations about
AI, and how they wish to interact with AI components.
Using this model as a guide, we conducted semi-structured interviews with 21 industry
practitioners from 14 different organizations.
Our participants included software engineers, ux designers, product managers, data scientists,
and research scientists.
We started with people in our network working on AI products and used snowball sampling
to recruit participants across different roles.
Each interview lasted approximately 60 minutes.
For the analysis, we used inductive coding, and memoing followed by discussion of finding.
I will now talk about two key findings from this study.
The first finding is that design-engineering boundaries pose specific challenges to the
cross-disciplinary needs of AIX.
First, the abstraction boundary between designers and engineers introduces knowledge blindness.
That is, engineers experience end-user blindness when developing AI capabilities.
M1 a UX manager reports people would go off in just weird directions, get obsessed with
trying to identify guns, or something that wasn't really that important to what we were
doing
Similarly, designers don’t get to understand essential details about AI that is necessary
for Human-AI design.
According to R2 a Research Scientist, You need to understand the failure cases, understand
confidence and how you deal with confidence scores, and thresholds.
You need to be able to understand the grain of the technology
Because the boundary enables designers and engineers to work independently, they commit
to or concretize their design even before aligning AI and UX.
This form of premature specification leads to frustration during coordination.
Because the boundary enables designers and engineers to work independently, they commit
to or concretize their design even before aligning AI and UX.
This form of premature specification leads to frustration during coordination.
they would hand that [design document] off to the engineer and say, ‘Implement this.’
It felt particularly extraneous when it got very granular, and it was not the best medium
for describing the desired behavior.
This is not a good reflection of how the actual software engineering is going to happen.
And I was like, ‘Stop trying to do my job for me.
Further boundaries restrict access to collaboration and co-design.
U6 commented on their challenge to getting involved in data annotation it seemed very
odd to me that as designers we were not invited to the annotation session.
So, we had to invite ourselves to just talk to domain experts... for engineers, their
approach is more like ‘the machine is going to figure it out.’
We could be talking about health or elephants in the circus, and it is all
the same to them .
We discovered that teams that were successful in operationalizing the guidelines practiced
deliberate leaky abstractions at the boundaries which allowed them to collaborate better.
While, In traditional software practice leaky abstractions are a considered a bad thing.
In HAI design, rather than strict abstractions and information hiding, teams shared low level
details about design and engineering with each other and even with potential end users.
Leaky abstractions allow teams to overcome knowledge blindness
As M2 comments: . UX teams can actually bring a little hope to those folks and give people
a target, and really paint a picture through design visualization, whether that’s making
a movie or just making a series of mocks, or building an experiential prototype…
Sometimes, it’s the light at the end of the tunnel.
Through leaky abstractions designer and engineers were able to collaborate in designing both
the AI and UX According to U3:
Then I get the model output from the data scientist and work with them to understand
the model labels and explanations.
The data scientist wrote down all the equations and explained it to me very clearly.
They showed me how the weights were set, and we discussed things we needed to know from
users
Third, Leaky abstractions also provided transparency in evaluating HAI designs.
We would list out the rules so the domain experts could look at it.
We started to give them more accessible tools like sharing a spreadsheet where they could
edit some input and we could import that into the system.
Across all interviews, our participants reported numerous boundary representations that embodied
abstraction leaks to support collaboration.
We refer you to the paper for complete details about how these leaky artifacts allow designers
and engineers to bridge their disciplinary boundaries.
These abstraction leaks provided teams an alternative to AI first design workflows.
In the early design stages, designers and engineers produce fuzzy or partial design
specifications . By sharing those initial design artifacts
teams could collaboratively assess, negotiate, and revise their design choices.
For instance, by sharing emerging AI behavior specifications, designers can evaluate assumptions
and fit for end-users, update their own design representations, and provide feedback for
AI design.
During this stage, avoiding commitment to specifications makes the design pliable and
invites collaboration and inputs.
As the design progresses, more and more aspects of AI and UX components become concrete, and
consequently, the need for leakiness at the boundary reduces.
In the final stages, teams arrive at designs solutions that are aligned across AI, UX,
and humans.