►
From YouTube: UX Showcase: Dev:Create UX Research
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
once
a
user
starts
to
use
things
like
repositories
and
merge
requests,
they
often
start
to
explore
other
capabilities
of
git
lab,
such
as
issues
or
CI,
and
so
create
is
often
at
the
center
of
those
types
of
decision.
Makings
and
things
like
that,
and
so
there
are
connections
between
requests
and
issues,
compliance,
security
and
other
areas
that
are
really
important
to
a
lot
of
our
users,
and
so
because
of
that
creatives
in
a
position
where
there's
a
lot
of
maintenance
needed
for
existing
product
areas.
A
As
this
is
a
an
area
of
Ghaleb,
that's
been
around
very
long,
but
also
driving
toward
new
aspects
of
our
product,
vision
and
kind
of
iterating.
On
the
vision
for
code
review
and
things
like
that,
and
so
UX
research
has
been
a
part
of
helping
the
team
make
iterative
changes
while
also
exploring
new
opportunities
you.
A
So
if
you're
wondering
how
do
I
start
doing,
the
elects
research
I
believe,
there's
a
lot
of
value
in
understanding
what
you
do
know
before
you
start
searching
for
answers
to
what
you
don't
know,
so,
whether
you're
evaluating
various
design
proposals
gathering
data
on
how
common
a
problem
is
testing
the
usability
of
a
proposed
solution
or
even
just
exploring
new
workflows
and
new
groups
of
users.
The
first
step
is
often
to
figure
out
what
you
need
to
learn
from
the
research
and
why
so?
You
can
see
here.
A
Let's
get
my
my
talking
slice,
so
what
kind
of
UX
research
can
I
do
so
as
part
of
the
problem,
validation
and
solution,
validation,
aspects
of
our
products
element
flow.
We
tend
to
focus
more
on
user
interviews
and
usability
testing
and
surveys,
and
so
I
just
wanted
to
give
a
shout
out
to
some
other
things
you
might
consider
as
well
and
the
the
training
article
about
choosing
the
right
methodology.
A
So
I
just
wanted
to
highlight
some
recent
research
efforts
in
the
create
stage
to
show
an
example
of
the
type
of
research
you
can
do
so.
I'll
start
off
with
merge,
request
approval
rules.
We
did
some
moderated
usability
testing
there,
and
so
the
context
for
this
was
that
during
a
UX
scorecard
initiative
for
create
for
evaluating
the
flow
of
creating
a
merge
request,
our
create
designers
found
some
things
that
were
a
little
bit
off
about
the
merger.
A
Cuss
approval
rules
in
that
creation
page
for
emerge
requests,
and
then
they
decided
to
take
a
step
back
and
look
at
the
feature
as
a
whole
and
just
get
kind
of
like
a
baseline
assessment
of
the
experience.
And
so
we
decided
to
do
moderated
usability
testing
with
five
gait
lab
users
who
are
familiar
with
the
EMR
approvals
feature,
but
even
that
varied
a
bit
to
some
people
who
were
super
familiar
with
it.
A
Some
people
who
heard
of
it
but
can't
really
interact
with
it
that
much
because
they
didn't
have
it
available
to
them
so,
but
just
people
who
knew
what
it
was
to
start
with,
and
so
we
learned
a
lot
of
different
things
from
that
study.
It
was
a
very
interesting
being
I
think
some
of
the
key
things
that
came
out
were
that
when
you
tend
when
you
have
settings,
when
you
have
the
option
to
enable
a
feature
in
settings,
sometimes
people
might
look
for
it
outside
of
that
location.
A
So
they
might
look
for
it
in
the
left.
Sidebar
looking
at
the
merger
class
page
rather
than
thinking
to
go
to
settings
repository
settings
general
and
looking
under
there
for
the
actual
setting
to
turn
on
the
feature.
So
that
was
something
that
was
key
to
us,
because
that's
really
important
for
the
discoverability
aspect
of
the
feature
before
you
can
even
get
started
with
it,
and
so
then
also
when
creating
a
merger
class,
some
users
thought
it
made
more
sense
to
attach
the
appropriate
approvable.
A
Instead
of
reducing
the
numbers
required
to
zero.
So
there
were
some
interactions
that
seemed
to
take
extra
steps
rather
than
a
more
direct
or
efficient
way
to
do
it,
and
then
basically,
we
also
came
up
with
some
other
discussion
points
like
understanding.
If
I'm
assigned
to
multiple
approval
rules,
do
I
need
to
approve
them
one
by
one,
or
can
it
be
assumed
that
I'm
approving
them
from
all
the
different
groups?
A
So
that
was
an
interesting
study
and
that
involved
usability
testing,
and
so
the
next
study
is
about
the
multi
filed
snippets
view,
and
so
we
decided
to
do
a
preference
test
and
a
first
click
test
for
this
one
and
basically
Marcel
had
created
an
initial
design
proposal
for
creating
multi
file
snippets,
but
then,
after
iterating
on
it
a
bit.
He
came
up
with
another
idea,
and
so
what
he
wanted
to
do
was
test
the
two
ideas
and
see
which
one
was
preferred
by
gate
lab
users
and
also
why
they
were
preferred
by
gate
lab
users.
A
So
we
went
with
a
design
evaluation
created
in
usability
hub
and
distributed
this
to
users
beard
via
Twitter
or
get
my
first
look.
I
mean
things
like
that,
so
you
can
see
the
the
different
versions
of
the
design,
but
for
the
sake
of
this
presentation,
I
wasn't
really
able
to
put
them
all
on
here.
But
this
is
a
gist
of
it.
A
Participants
were
able
to
click
on
the
right
area
for
deleting
a
file,
but
there
was
also
feedback
on
what
could
make
that
more
more
intuitive
for
them
as
well
so
down
here,
I
put
it's
not
just
about
what
they
prefer.
It's
also
why
they
prefer
it
and
so
for
context.
There
are
actually
a
lot
of
different
opinions,
even
though
the
majority
voted
for
B
version
a
actually
had
a
lot
of
different
arguments.
A
This
should
be
enough,
otherwise
I
would
pick
the
file
picker.
So
the
decision
kind
of
had
a
caveat.
It
might
be
good
for
if
I
have
just
three
to
five
files
on
this
page,
but
if
I
have
more
than
that,
it
might
become
a
bit
unruly
and
I
need
the
other
option
and
similarly
for
version
B
concerns
were
mainly
around
having
less
scrolling,
make
it
easier
to
switch,
and
that
also
felt
similar
to
other
editors,
such
as
Visual
Studio
code,
and
it
might
be
better
for
adding
a
lot
of
files.
A
So
those
are
some
of
the
quotes
there.
But
you
see
here
we
have
another
one
with
a
caveat,
it
has
less
scrolling
involved,
but
if
the
second
option,
so
if
this
option
had
expandable
blocks,
this
might
be
a
tough
decision
for
them.
So
basically
what
they're
saying
there
is,
if
there
are
some
tweaks
here,
maybe
I
think
here
it
might
be
like
if
these
blocks
could
somehow
be
collapsed
or
and
expanded.
Then
that
might
make
the
decision
difficult
for
them.
A
That
was
my.
If
the
pen
slide
and
a
bonus
point,
people
often
get
a
variety
of
different
feedback.
Just
in
one
study
so
always
be
sure
to
read
through
all
the
results
or
you
might
read
through
the
first
ten
and
they're
saying
this
looks
great
I
think
you
should
implement
it
within
the
next
tennis.
They
actually
hear
all
these
other
considerations,
so
I
just
kind
of
put
together
different
comments
that
were
kind
of
contradicting
all
from
the
same
study
and
lastly,
because
I'm
almost
done
what
time.
A
Here's
just
another
example
of
what
you
can
do
if
you're
not
doing
a
usability
study
or
user
interviews
or
other
types
of
research,
you
might
just
dive
right
into
our
gait
lab
issue
tracker
and
start
pulling
out
feedback
from
the
community
issues.
So
reading
comments,
finding
use
cases
and
things
like
that
and
mapping
them
out
into
different
buckets
so
talking
about
pain
points,
suggested
improvements,
missing
capabilities.
Things
like
that.
A
You
can
start
right
from
your
issue
tracker
and
see
what
people
are
saying
directly
there,
and
so
for
the
context
of
that,
we
were
doing
that
for
the
case
of
the
wiki.
We
had
done
a
little
bit
of
research
in
the
past,
so
we
didn't
need
to
start
from
scratch
on
user
interviews
and
what
I,
when
I,
mainly
found
from
there,
is
that
for
wiki.
The
key
thing
to
keep
in
mind
is
that
people
are
working
from
it,
working
on
it
from
both
an
engineering
and
non
engineering
perspective.
A
So
the
core
goal
is
to
have
a
way
for
people
to
easily
access
this
wiki,
whether
they're
comfortable
with
get
lab
or
not.
So
that
brings
in
considerations
about
roles
and
permissions
and
also
the
ease
of
the
editing
experience
and
how
things
are
structured
in
the
wiki
as
well,
so
I
just
included
some
common
use
cases
and
top
feature
requests
for
a
wiki
as
well,
because
it
is
one
on
the
most
top
like
one
of
the
most
buzzing
features
in
the
issue
tracker
along
with
snippets,
so
fun
fact
and
yeah,
that's
about
it.
A
B
I
think
it's
Ian
excellent!
That's
what
you
do
I
wanted
to
say
Katherine!
This
was
awesome.
Thank
you
so
much
for
going
through
this
I
know.
There
are
a
lot
of
questions
right
now
about
like
what
types
of
methodologies
can
we
use
what's
valid
and
I
think
you
did
a
really
good
job
of
showing
it
there's
a
lot
of
different
ways
we
can
do
things
depends
on
what
you
want
to
do.
So.
Thank
you.
Thank.