►
From YouTube: Settings UX - Verify
Description
As part of the overarching initiative to improve the GitLab Settings experience, we will collect existing user feedback and proposals in order to drive user experience and SUS score improvements for settings. This is a conversation with Verify:Testing & Runner
More on https://gitlab.com/groups/gitlab-org/-/epics/3535
A
This
computer
say
recording
all
right
cool,
so
I'm
not
sure
if
you're
up
to
date
with
the
settings,
ux
initiative-
and
I
think
I
mentioned
this
before
I
hope
so
briefly-.
B
Yeah
I
read
through
it
well
well,
yeah.
A
So
up
until
recently,
or
what
we
have
now
is
that
settings
doesn't
really
belong
to
any
stage
work
that
might
change,
but
so
far
we
have
settings
problems
that
no
one
owns
and
because
of
that,
no
one
prioritizes.
A
That
was
the
main
reason
why
nadia
started
collecting
ux
issues
related
to
to
ux
issues
related
to
settings,
and
I
went
ahead
and
created
this
epic
and
I'm
having
conversations
with
designers
from
I'll
try
to
go
over
all
stage
groups,
but
just
to
have
a
conversation.
Try
to
understand
how
is
settings
in
your
stage
group?
Where
are
the
current
issues
that
you
have
or
challenges
in
the
past
or
future
plans
so
that
we
can
try
to
align
first
off,
have
a
baseline.
A
B
No,
that's
that's
totally
fair
and
I
think
that
that's
the
same
reading
that
I
have
in
this
situation.
But
settings
are
super
important,
but
no
one
owns
because
no
one
owns
settings
then
all
the
issues
that
we
have
with
them
are
always.
You
know.
I
don't
think
they
are
ignored,
but
I
think
they
are
just
not
a
knowledge
in
a
way
that
they
can
be
addressed,
because,
like
many
of
the
issues
that
we
have
have
to
do
a
lot
with
the
structure
of
the
settings,
I'm
finding
things
discoverability.
B
You
know
like
the
navigability
of
the
settings
itself.
You
know
it's
not
ideal
yeah.
I
mean
a
particular
group
so
like
for
testing
no
one's
an
interesting
one
because,
like
we
don't
have
a
lot
of
things
going
on
on
settings.
B
We
have
a
couple
of
things
that
happen
that
need
to
be
set
up
on
settings,
especially
when
you
wanna
kind
of
create
when
you
want
to
create
coverage,
badges,
there's
something
that
you
gotta
go
and
do
in.
B
I
think
that's
about
it
perhaps
there's
something
else,
but
for
runner,
it's
quite
interesting,
because
runner
actually
like
everything
that
is
runner
bubbles
up
through
the
settings.
That's
the
only
thing
that
we
have
right
now
on
runner
when
it
comes
to
the
ux,
and
we
actually
have
been
doing
a
couple
of
things
there.
You
know
so
like
we,
we
have
two
things
coming
up:
they
are.
There
are,
mr
cookies
that
are
getting
merged
soon.
B
I
think
the
other
one
is
oh
yeah,
adding
the
instructions
for
installing
a
runner
inside
the
settings
is
instead
of
leaving
the
the
ui
and
going
to
the
documentation,
and
just
basically,
you
know
getting
lost
there
so
like
we're,
gonna
provide
better
like
a
better
flow
for
people
to
understand
how
to
install
a
runner,
but
just
in
general,
like
our
ux,
particularly
when
it
comes
to
the
runner
settings,
it's
pretty
bad.
I
have
a
couple
of
proposals
on
how
to
improve
that.
B
We
are
going
to
do
a
lot
of
those
things
we
have
plans
for
that.
However,
one
kind
of
interesting
idea
that
we
have
been
bouncing
around
is
that,
at
the
end
of
the
day,
we
might
like
completely
unbundle
unbundle
the
runner
settings
and
just
keep
like
very
light
things
there
and
then
kind
of
like
promote
runners
to
be
a
more
first-class
citizen
right
because
they
are
right.
B
Now
like
like
you
want
to
see
your
runners,
you
need
to
go
to
your
settings
and
then
you
see
a
list
of
your
available
runners
that
the
ones
activated
for
that
project
or,
like
the
show
runners
that
are
available
for
that
project.
You
see
them
under
the
settings
of
course
that
hurts
the
discoverability
of
certain
concepts
of
runner
like
things
like
you
know
like
disabling
runners,
for
projects-
or
you
know,
passing
runners,
so
they
don't
accept
new
jobs
protecting
runners,
so
they
only
trigger
pipelines
from
protected
branches,
running
attack
jobs.
B
That's
another
thing:
locking
locking
runners
to
one
particular
project.
All
those
things
are
super
important
in
runner
and
they
all
happen
in
settings
and
they
are
very
hidden.
A
B
Know,
which
I
mean
it's
it's
it's
okay.
We
will
eventually
figure
it
out,
but
it's
not
ideal.
So
one
thing
that
we
have
been
thinking
is:
okay,
let's
basically
break
apart
the
important
things
and
then
put
those
things
under
ci
cd,
perhaps
in
a
completely
new
top
under
ci
cd,
a
new
page,
and
then
you.
B
Thinking
is
like
maybe
we
we
end
up
combining
jobs
and
runners,
because
at
the
end
of
the
day
they
are
related,
your
runners
are
the
ones
that
are
fixing
the
jobs
right.
So,
like
there's
like
this
opportunity
of
combining
those
two
things,
I
mean
I'm
exploring
those
options
either
way.
The
problem
is
that,
because
we
throw
everything
on
runner
settings,
then
there's
like
this
mess.
You
know,
like
we
don't
know.
B
What's
the
setting
and
what's
not
a
setting,
you
know
like
so
even
the
heuristics
of
what's
setting,
I
don't
think
they're
clearly
defined,
and
so
that's
one
problem
that
I
see
and
it
happens
across
many
things.
You
know
like
it's,
it's
here:
management
or
settings,
you
know,
but
it's
not
it's.
Definitely
it's
definitely
operating
us
both
and
that's
that's
not
good.
You
know,
and
I
I
see
that
in
other
you
know.
Other
things
like
pages
also
has
a
little
a
little
bit
of
that.
B
You
know
you're
going
to
configure
your
pages
there,
but
sometimes
it
gives
you
the
feeling
that
you
might
want
to
configure
your
pages
somewhere
else.
You
know,
like
I
don't
know,
that's
that's
a
thing.
So,
overall,
I
feel
that
it's
super
important
to
yeah
address
these.
I
don't.
I
can
tell
you
like
from
my
experience
with
runner,
that
what
like,
like
it's
going
to
happen,
is
that
we
are
going
to
make
our
runner
settings
more
light
and
then
we're
going
to
move
things
out
of
that
and
create
a
new
area
for
those
things.
B
My
problem,
though,
is
that
during
that
thought
process
we
we
have
also
thought
about
like
hey
what,
if
we
keep
these
settings
outside
of
the
settings,
I
don't
know
if
that
makes
sense.
You
know,
because
many
of
those
things
are
kind
of
quite
important.
You
know
like
when
you
are
like
dealing
with
your
runners.
They
are
more
like
management
features,
not
so
much
like
a
setting
you
know
and
when
I
think
settings
I
I'm
thinking
about
like.
B
A
set
of
default
values
that
are
used
to
operate
that
feature,
you
know,
but
sometimes
many
of
these
things
are
go
beyond
that.
Sometimes
this
is
things
that
you're
actively
changing.
You
know
like
passing.
A
a
runner
is
definitely
something
that
you
might
do
a
lot,
because
you
might
be
like
giving
maintenance
to
that
runner
and
you
want
to
basically
like
update
it
or
something
then
like
you,
you
go
to
settings
and
then
you
pause
the
runner,
and
you
know
that
that's
all
right.
B
It
doesn't
feel
right
to
me
that
you
have
to
go
to
settings.
I
think
that
we're
just
completing
too
many
things
there.
So
that's
one
thing
I
think
the
other
thing
is.
I
think
you
mentioned
that
on
the
issue,
just
like
the
hierarchy
in
general
seems
so
weird.
You
know
like
cicd
kind
of
like
gets
everything
that
is
cicd,
but
I
mean
that
that's
a
third
one,
but,
like
general.
A
B
Instance,
you
know
that
one
has
like
merch
requests,
merge,
requests
approvals
and
it
almost
gives
you
the
the
feeling
that
that
should
go
under
repository.
I
don't
know
why,
like
I,
I
feel
that
it
shouldn't
be
there
in
general,
and
I
think
these
are
all
decisions
that
were
are
made
way
in
the
past,
like
they
precede
us
and
then
they
just
like
live
there
and
we
gotta
deal
with
them.
You
know
because
that's
how
they
are
so
yeah.
I
don't
know
it's
interesting.
It's
definitely
definitely
not
ideal
right
now.
There's
many
issues.
A
So
when
you
talk
about
decoupling
settings
from
the
the
the
usual
configuration
to
bundle
it
with
the
with
the
runners,
I'm
curious
to
hear
if
you
have
already
validated
some
of
these
workflows
or
if
you
have
any
insights
or
you
know
just
yeah.
A
Also
share
and
help
us
to
influence
how
we're
going
to
make
updates
to
the
information
architecture
of
settings.
B
Yeah
we
did
a
problem
validation
from
frictionless
runners,
like
that's,
like
a
huge
initiative
that
we
have
about
like
making
runners
easier
for
people
yeah.
We
we
saw
a
lot
of.
I
might
have
those
on
dovetail.
I
might
I
think
I
can
share
those
with
you
later.
B
They
they
get
more
confused
with
the
fact
that
things
live
in
settings
and
with
the
fact
that
they
like
and
with
the
idea
that
they
should
probably
be
operating
this
from
another
place.
You
know
like
they
have
that
preconception
that
like,
if
they
want
to
deal
with
runners
like
they
should
be
like
more
first-class
citizen
type
of
things.
You
know,
and
if
that's
the
case,
then
they
shouldn't
live
in
settings.
You
know,
because
that's
that's
one
problem.
B
Don't
put
everything
there,
you
know
it
doesn't
make
sense
and
then
there's
a
bunch
of
things
like
people,
don't
understand
that
you
can
actually
go
there
and,
for
instance,
eddie
a
banner.
I
think
that
people
don't
really
don't
get
that.
I
think
they
just
get
the
idea
that
they,
because
many
of
these
things
can
be
operated
from
the
cli
anyway.
So,
like
that's,
that's
one
thing
you
know
like
people
are
like.
No,
I'm
just
gonna
do
this
from
the
cli.
I
yeah.
A
That
was
my
my
follow-up
questions
because
in
this
management
and
I
in
progressive
delivery
as
well,
we
have
a
lot
of
configuration
that
happens
in
both
ci
the
ci
file.
B
B
A
I'm
also
curious
to
hear
how
do
you
handle
or
if
you
handle
this
type
of
setup
right
now
in
this
way,
and
if
you
encountered
any
issues
or
if
you
have
any
good
things
to.
B
Yeah
totally
that's
a
great
question
because
we
actually
do
have
problems
with
that.
So
right
now,
when
you
want
to
install
a
runner,
you
have
to
go
to
settings.
So
that's
the
first
thing
you
always
have
to
go
to
settings
and
then
there
you're
gonna
see
instructions
on
how
to
install
a
runner
and
the
instructions.
B
Tell
I
give
you
the
url
for
the
instance,
and
they
give
you
the
registration
token
for
the
for
the
instance
and
you
need
those
two
values
when
you're
gonna
register
a
runner,
so
you
always
have
to
go
to
settings
now.
One
problem
that
we
have
seen
is
that
people
do
that
and
then
they
forget
to
like
there's
there's
a
process
in
which
you,
you
install
the
runner.
You
need
to
do
all
these
things
on
your
machine
and
then
you
need
to
register
the
runner.
A
B
It's
already
there,
you
know,
but
like
they
forget
that,
there's
a
they
forget
that
there's
a
process
which
they
need
to
bind
the
runner
to
the
instance,
and
I
think
one
big
problem
with
that
is
that
they
live
in
settings
like
people
are
never
going
to
check
that
in
you
know,
workflows.
You
know,
that's
why
we
have
been
thinking
about
the
idea
of
like
if
we
put
this
on
jobs,
which
is
likely
an
area
where
people
are
seeing
a
lot,
we
could
create
like
a
placeholder.
B
For
recently
I
mean
that's,
that's
just
like
a
crazy
idea
that
we
have
right
now
but
like.
If
you
have
a
placeholder
for
your
runner,
then
you
know
that
the
runner
never
got
registered
and
he
never
kind
of
contacted
the
instance
you
know,
but
that
only
works.
If
it's
in
a
place
where
you
can,
you
can
check
it,
you
know
you're
like
actively
seeing
it.
You
know.
So
that's
one
problem
that
we
see
like.
A
Yeah,
that's
a
that's
another
thing:
we've
also
been
discussing
about
the
discoverability
of
settings
in
general
right,
not
even
where
settings
live
efficiently,
if
in
the
in
the
menu
section,
either
in
the
high
level
or
in
the
settings
page,
but
the
discoverability
of
settings
and
also
the
lack
of
contextualization
when
you
are
working
in
a
process.
But
you
need
a
second,
the
third,
the
fourth.
A
I
think
that's
in
general,
that's
a
gitlab
problem
where
we
don't
give
users
the
hints
that
to
proceed.
They
need
to
do
whatever.
B
Right
right,
there's
another
one
that
I
have
heard
a
lot
personal
experience
too,
which
is
sometimes
you
gotta,
you
wanna
do
something
like.
Let's
say
you
wanna.
Let
me
let
me
think
about
a
good
one.
You
wanna,
I'm
gonna,
go
to
cicden.
B
B
So
now
what
you
know
so
like
what
people
will
do
is
that
they
go
on
google,
yeah,
employee,
freeze,
gitlab,
right
and
then,
like
the
documentation,
shows
up
and
the
documentation
like
it's
good,
it's
very
thorough,
but
one
problem
that
I
always
see-
and
I
think
I
have
heard
this
from
a
couple
people-
is
that
when
you
go
through
the
documentation,
you
never
you,
it
always
takes
some
time
to
find
exactly
where's.
B
The
setting
you
know
like
it's
very
hit
and
somewhere
in
the
documentation,
which
is
something
that
I
was
thinking
about,
opening
an
issue
I'm
proposing
to
the
documentation
team
like
every
time
that
it's
about
a
setting.
It
should
have
like
a
big
thing
at
the
top
telling
you
where
to
find
it.
You
know
I
think
that
has
to
do
a
lot
with
the
discoverability
because,
like
we
cannot
expect
people
to
like
that's
the
only
way
to
find
things
you
know
like
you
got,
you
go
and
google
them
and
you
find
the
documentation
right.
B
So
I
think
we
don't
do
like
a
great
job
at
telling
people.
Okay,
like
your
deploy,
freezes,
live
under
settings.
Ci
cd,
deploy
freezes.
That's
where
you
added
you
know,
that's
the
only
information
that
most
people
need.
If
they
need
to
do
something
else,
then
they
will
figure
out.
You
know
almost
like
it's
all.
It's
so
frustrating
because,
like
many
of
the
instructions
that
you
get
for
settings
are
already
in
the
settings,
we
have
instructions
for
runners
in
in
the
runner
settings
you
know.
A
That's
very
interesting
because,
as
a
user,
when
I
had
to
install,
for
example,
auto
devops
in
my
local
instance,
it
was
a
nightmare.
You
decided.
B
A
Do
that-
and
I
think
I
I
still
have
to
talk
to
some
of
the
configured
designers,
but
I'm
super
curious
to
understand
their
perspective
as
well,
because
they
have
settings
that
happen
outside
of
gitlab.
So
there's
the
docs
right.
B
B
A
It's
a
very
it's
very.
B
Interesting
yeah,
by
the
way,
that's
that
many
of
the
things
that
happen
with
runner
also
happen
completely
outside
of
even
like
the
boundaries
of
what
kit
lab
is
you
know?
Sometimes
you
gotta
like
work
with
your
cloud
provider,
which
is
like
aws
or
google
cloud
or
whatever
and
like
once
it's
outside
of
our
realm.
It
also
becomes
way
harder.
I
mean
like
there's
there
gotta
be
also
good
ways
for
us
to
facilitate
that.
You
know,
because
it's
just
because
it
lives
outside
of
our
realm
doesn't
mean
that
we
we
cannot.
B
I
don't
think
we
should
be
like
ignored
the
fact
that
we
could
help
our
users
to
navigate
like
because,
like
the
complex
use
cases
that
they
have
with
external
services,
you
know
one
of
those
being
like.
How
do
I
install
a
runner
in
an
remote
machine?
You
know
which
I,
which
eat
lab,
doesn't
control
at
all,
at
least
from
the
beginning.
You
know
so
I
mean
that's
another
one.
I
think
sometimes
people
like
get
confused
with
those
things
as
well.
Is
this
something
that
I
gotta
set
up
on
github?
B
Or
is
this
something
that
I
got
to
set
up?
My
machine,
you
know,
yeah,
like
it's,
two
completely
different
animals.
You
know
which
I
know
that
there's
I
think
it
was
maria.
I
don't
want
you
the
one
working
on
yeah.
I
think
it's
maria
she's,
the
one
working
on
the
gitlab
agent,
which
it's
supposedly
gonna,
fix
a
lot
of
these
problems.
B
You
know
like
gaps
in
the
experience
I
mean
this
is
especially
important
for
self-hosted
instances,
right
like
where
you
install
gitlab
and
you're
supposed
to
you
know
like
live
with
gitlab
and
make
sure
that
gitlab
works
like
we
don't
control
the
machine
so
like
we
are
somehow
responsible
for
the
machine,
but
we
not
not
to
the
point
that
we
can
like
tell
them
like
what's
broken
within
my
chin.
You
know
so.
B
A
Do
you
have
any
work
on
because
you
mentioned,
I
think
the
items
that
you
mentioned
about,
like
the
coupling
the
runner
settings
there
for
the
future
right
or
you're
right.
B
I
have
issues
open
with
actual
proposals
and
things
this
face.
Simplification
of
things
I'll
add
those
to
the
issue
as
well
that
it's
mostly
it's.
It's
very
nbc
right,
like
very
like,
like
things
that
I'm
suggesting
are
basically
okay.
Let's
make
this
way
simpler,
like
let's
you
know
like
improve
the
visual
aspect
of
these
settings.
Let's
make
it
more
clear:
let's
keep
bubble
up
better
state.
B
What's
going
on
like
that,
it's
very
important
for
runner,
because
in
runners
sometimes
like
for
the
things
that
we're
doing
like-
let's
say
you
open
settings
runner
settings
in
a
project.
Sometimes
you
need
the
context
of
what
are
the
settings
at
the
group
level.
You
know
just
that.
Ux
is
a
little
bit
complex
because
you
gotta
tell
the
customer
like
hey.
You
cannot
enable
sure
runners,
because
share
runners
are
disabled
at
the
group
level
on
your
app
and
your
group,
admin
doesn't
allow
you
to
turn
the
nom
on
turn
them
on
at
the
project
level.
B
So
how
do
you
explain
that
in
your
settings
in
a
way
that
it's
not
a
whole
mess,
you
know
because
it
can't
become
very
provost
and
it
can
and
by
the
way
you
need
to
have
that
context?
It's
like!
Oh,
I
didn't
know
that,
like
group
groups,
can
disable
group
runners,
you
know
so,
like
that's
another
thing,
you
know.
A
Yeah,
that's
another
point:
I'm
also
working
on
the
release
group
releases,
so
settings
and
configuration
of
release
at
the
group
level
and.
A
Users
that
their
project
release
works
the
way
it
does
because
of
the
group
release
component.
A
B
Yeah,
honestly,
we
need
to
do
a
good
job
at
that,
it's
kind
of
like
unreasonable
to
expect
that
this
is
going
to
be
communicated
somehow
between
the
owner
of
the
group
and
like
the
users
of
the
product.
You
know
that
doesn't
make
sense
right,
like
these
things
that
you
really
gotta
be
very
explicit
about
and
tell
them
why
they
cannot
use
certain
features
or
how
why
they
cannot
enable
certain
settings.
You
know.
A
B
A
No,
but
I'm
here
in
a
way
to
try
to
understand
these
problems
and
yeah,
try
to
summarize
or
communicate
them,
because
I'm
gonna
just
go
over
this
hold
on
a
second,
because
I
just
wanted
to
tell
you
the
themes
that
we
have
identified
so
far
like
high-level
things
for
for
settings.
A
Okay,
so
let
me
find
it
here
because
I
have
here
so
this
is
based
on
the
issues
that
550
issues.
We
have
500
issues
for
settings
and
we
have
100
whatever
almost
200
for
ux
settings
ux.
So
we
have
identified
the
core
problems
that
they
live
in
discoverability.
A
So
it's
exactly
what
we're
talking
about
global
versus
items
or,
like
you
know,
global
settings
versus
functionality,
settings
mix.
I
think
you
also
mentioned
that.
A
The
switch
of
the
flow
so
you're
doing
something
here
you
have
to
go
somewhere
else
right:
the
overlap
of
options,
okay,
any
consistency
in
general
across
settings.
So
this
is
more
like
ui
changes
and
I
think
it's
also
because
we
don't
really
have
a
a
library
or
a
pattern
for
us
for
settings.
We
have
the
components,
but
we
don't
have
house
settings
so
I'm
you
know
I'm
happy
to
hear
your
problems
because.
B
B
I
think
they
all
fit
in
those
buckets,
so
you
just
described
you
know
like
they
all.
I
think.
Well,
I'm
glad
that
you
have
those
buckets
described,
because
it
seems
that
we
all
perceive
the
same
problems
which
makes
me
I
mean,
I'm
not
happy
that
we
have
the
problems,
but
I'm
like
happy
that
I'm
not
perceiving
the
wrong
problems.
You
know.
A
And
I
think
the
next
steps
for
me,
of
course,
I'm
just
gonna,
collect
this
information
and
I'll
try
to
bundle
this
your
insights
into
yeah
into
these
teams.
So
if
you
can
share
with
me
on
those
issues,
you
can
like
everything
yeah
anything
you
have
around
this,
the
items
we
discussed.
Let
me
know
yeah.
B
I'm
gonna
add
all
the
issues,
all
the
related
things
to
the
issue,
and
I
just
took
a
note.
I'm
gonna
do
that
today
and
hopefully
that
helps
the
build,
a
better
picture
of
like
how
problem
is
perceived
from
different
groups.
A
For
sure,
and
if
there's
anything
else
that
you
remember
or
if
you
think
that
it's
relevant
just
let
me
know
I'm
doing
this
mostly,
I
think,
but
I'm
meeting
up,
I
think,
hopefully,
when
the
meet
is
back
to
the
office.
I'm
also
gonna
have
a
conversation
with
him,
but
I'm
very
interested
in
knowing
like
trying
to
find
a
common
ground
for
us
because
with
cicd
we're
always
changing
or
at
least
influencing
how
we
do
settings
in
different.
B
B
Yeah,
I
completely
agree.
I
think
that
I
think
that
if
the
outcome
of
this
is
at
least
having
like
a
set
of
standards
that
we
have
to
use
when
dealing
with
settings,
I
think
that
would
be
an
excellent
outcome.
You
know
it's
not
that
we
need
to
fix
everything
right
away,
but
I
think
just
like
having
like
that
guidance
like
that
kind
of,
like
you
know,
framework
to
like
create
settings
and
just
don't
troll
settings,
because
the
way
that
it
feels
is
like
when
someone
needs
settings,
it's
just
like
put
it
there.
B
A
Awesome,
if
you
have
any
other
questions,
just
let
me
know.
I
added
this
as
a
note
here,
maybe
something
that
we
can
add
to
pajamas.
We
have
regions,
we
have
objects,
we
have
content,
but
we
don't
have
like
patterns
right.
A
Yeah,
I'm
gonna
add
this
not
for
myself
to
investigate
to
investigate
this
or
like
add
initial
proposal.
Nice.
Is
that
definitely
something
I
miss
as
a
designer
it's
like.
Am
I
designing
this
using
the
right
patterns.
A
When
you
do
settings,
for
example,
the
extent
collapse,
I
know
how
expand
collapse
work
and
I
know
how
it's
explained
or
how
it's
usable
in
isolation
right
right
in
context
with
a
feature
or
capability.
It
becomes
a
bit
more
complicated.
B
It's
funny
that
you
bring
that
particular
example,
because
I
have
deal
with
that
example.
Even
with
the
idea
like,
can
I
put
an
expand
collapse
within
expand,
pull
ups,
which
seems
like
a
very
natural
way
of
hiding
complexity?
You
know
it's
also
kind
of
like
a
daunting
experience.
You
know
so
I
don't
know
I
mean
like.
If,
if
you
ask
me
like
I'm
just
gonna
be
blonde,
I
will
lobby.
B
We
will
just
like
revamp,
like
all
the
issues
of
all
the
settings
eventually,
but
I
don't
think
that
would
be
also
like
ideal
for
the
customers.
It
would
be
like
too
much
but
being
a
big
bank
probably
affect
their.
You
know
already.
I
think
whatever
we
do.
It
needs
to
be
like
ready,
nbc
or
whatever,
but
but
at
least
I'm
I'm,
I'm
I'm
glad
that
we
are
a
knowledge
into
their
problem.
You
know.
A
It's
awesome
and
I
agree
with
you.
We
had
a
discussion
yesterday
also
because
I
had
another
call
about
settings
and
my
gut
feeling
as
a
designer
is
that
we
want
to
introduce
you
know.
We
don't
want
to
introduce
a
lot
of
friction
here,
because.
A
A
It's
something
that
I
agree
with
you.
My
my
initial
intention,
what's
in
my
head
right
now,
is
to
really
understanding
what
are
the
shared
problems
and
share
opportunities
that
you
know
that
we
can
try
to
prioritize
or.
A
And
find
yeah
just
a
way
to
design
the
vision
together,
but
then
we
build,
you
know
the
way
that
we
can
validate
it.
Yeah
yeah
right.
B
Right
this
is
super
helpful.
I
I
put
those
my
contacts
on
the
issue
and
then
yeah.
I
look
forward
to
keep
collaborating
on
this
awesome.
Thank
you.
We're
going
to
stop
the
party
yeah.