►
From YouTube: UX Showcase - Exploring weekly digest (WIP)
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
this
was
basically
a
rough
idea
of
if
we
were
to
create
a
weekly
digest,
email
for
admins
and
group
owner,
we
could
kind
of
achieve
a
couple
of
goals.
The
first
one
would
be
to
provide
interesting
information
to
these
people
that
they
could
act
upon.
The
second
being
drive
awareness
of
additional
stages
and
features
through
this
email
and
the
third
being
combining
the
two
previous
goal.
A
We
would
potentially
potentially
see
an
increase
in
retention,
so
that
was
like
a
let's
say,
a
simple
hypothesis,
and
out
of
that,
we
started
kind
of
adding
a
couple
of
items
that
we
thought
could
be
interesting
into
this
email.
A
But,
as
you
can
see,
if
you
look
at,
for
example,
information
on
projects,
information
on
active
users-
mrs,
like
all
of
this,
is
quite
broad
and
also
at
this
stage,
it
felt
that
we
were
kind
of
you
know
taking
different
themes
without
really
knowing
like
if
this
would
serve
some
kind
of
user
need
like
for
sure
it
would
serve
business
needs
and
potentially
try
to
like
advertise
a
specific
feature
that
we
know
are
important,
but
we
could
not
kind
of
pinpoint
what
was
the
problem
that
we're.
Actually,
what
was
the
user
problem?
A
Sorry
that
we're
actually
trying
to
solve
with
this?
So
this
was
a
good
time
to
take
a
step
back
and
try
to
reframe
the
problem.
Try
to
reframe
the
potential
like
solutions
and
the
way
I
did
this
was
to
use
this
ideation
tool.
That
is
called
the
theory
of
change.
By
the
way
I
highly
recommend
designkid.org.
If
you
ever
need
to
go
through
multiple
ids
on
how
to
ideate
but
yeah.
A
A
And
my
initial
starting
point
was
to
just
simply
focus
on
the
personal
noise
that
we
wanted
to
aim
at
with
this
issue,
so
the
team
lead
and
the
system
administrator,
I'm
more
going
to
be
focusing
on
the
team
need
here.
A
A
This
is
mainly
to
kind
of
like
oversee
the
whole
notification,
but
also
adopt
specific
feature
and
then
potential
stages
that
this
person
would
be
interested
in.
Once
I
had
this,
I
actually
tried
to
think
about
okay.
What
are
the
pain
point?
According
to
this
goal,
to
try
to
retrieve
a
specific
information
and
learn
about
features,
so
I
did
not
invent
at
those
point
points.
A
I
literally
pulled
this
from
another
initiative
that
the
girl
theme
is
working
on,
which
is
building
an
nbc
for
a
dashboard
and
when
we
tackle
this
mate
actually
talked
about
it
in
the
previous
showcase
that
he
did.
But
we
tackled
this
with
design
screens
where
we
interviewed
a
couple
of
engineering
manager
at
gitlab.
So
the
pain
points
that
you're
seeing
here
are
directly
pulled
from
that
effort,
and
essentially
what
I
did
here
was
to
just
kind
of
categorize
into
three
different
groups
and
try
to
narrow
it
down
to
like
three
pain
points.
A
A
So
once
I
had
that
that
was
where
what
helped
me
with
the
first
step
of
the
theory
of
change,
which
is
called
shifts,
and
essentially
what
you
have
to
do
is
write
the
shift
that
you
want
to
observe.
A
So
at
this
stage,
move
on
to
the
second
step,
which
is
to
essentially
write
down
as
many
concepts
as
you
can.
Think
of
that
could
address
this
shift,
and
this
is
the
moment
where
I
started
like
bringing
mike
the
former
team
of
adoption
in
in
this
mural.
Where
I
was
like
look.
A
This
is
the
the
the
shifts
that
I
have
this
all
the
concepts
that
wrote
does
that
make
sense
to
you
and
then
we
started
kind
of
discussing
of
like
okay,
which
concept
is
actually
addressing
each
single
one
of
these
shifts,
and
by
doing
so,
we
kind
of
saw
that
the
weekly
email
address
that
we
initially
thought
of
could
be
a
good
option,
but
also
essentially
trying
to
push
people
to
set
up
integration
with
other
communication
channels,
like
slack
asana
or
discord,
could
also
be
an
interesting
concept
for
us
to
pursue.
A
So
once
we
had
that
we
moved
on
to
the
final
ii
and
sorry
for
that
mission,
and
we
choose
to
like
focus
on
this
specific
shift
and
stash
this
one
for
a
bit.
So
the
shift
that
we
choose
to
focus
on
is
manually
tracking
activity
to
get
lab
and
from
lack
of
future
awareness,
to
activate
feature
that
improve
workflow.
A
So
once
we
had
that,
we
moved
to
the
final
step
we
see,
which
is
essentially
a
summary
of
the
steps
that
we've
been
going
through,
where
we
kind
of
rephrase.
What
is
the
lasting
social
social
change
that
we
want
to
contribute?
So
social
change
is
a
bit
much,
let's
just
say
change
this
case,
but
what
we
wanted
at
this
point
is
to
see
team
leads
can
easily
like
track
their
team
activity
and
are
better
aware
of
gitlab's
feature
and
then
kind
of
the
near
outcome.
A
So
basically,
what
tell
us
that
our
solution
is
working
so
for
us
to
verify
that
we
want
to
see
an
increase
in
the
stage
adopts
right
in
an
increase
in
stage
adoption,
but
based
on
the
future
that
we're
advertising
and
an
increase
in
overall
retention.
A
So
then
same
thing
like
it's,
just
rewriting
the
shifts,
the
different
concept
that
we're
gonna
focus
on
and
then
it's
kind
of
moving
up
to
the
condition
that
require
that
we
basically
need
for
the
solution
to
work.
So
this
is
more
internal.
A
So
in
our
case
we
felt
that
for
us
to
work,
we
need
the
email
to
be
tailored
and
relevant.
We
also
need
the
frequency
to
be
just
right
in
the
sense
that
it
needs
to
be
at
the
right
moment
so
that
it
doesn't
feel
spammy
and
that
it
fits
well
into
a
user's
workflow
and
then
moving
on
to
the
risks
as
to
why
our
concept
solution
could
not
work.
A
So
this
is
more
external,
maybe
not
project
and
group,
but
the
project
and
group
model
is
confusing,
so
you
may
not
know
basically
where
the
activity
is
coming
from
like
are
you
talking
about
project
and
then
the
sorry,
the
yeah?
So
this
one
is
basically,
the
organization
cannot
set
up
the
future
in
the
sense
that
it's
completely
irrelevant
to
the
project
that
they're
working
on
or
they
don't
have
the
budget
to
simply
upgrade
and
use
this
feature.
A
A
The
notification
part
that
we
have
here
and
the
feature
discovery
part
and
for
the
notification
part,
I
started
asking
myself:
okay,
what
could
be
the
content?
What
could
be
the
frequency,
what
the
mvc
content
could
be
and
then
what
are
the
iterations
that
we
could
produce
out
of
that?
A
So,
in
our
case,
still
like
focusing
on
team
activities
or
maybe
merge,
requests
issues
releases
and
then
feature
discovery
on
specific
stages
and
then
in
terms
of
frequency,
based
on
all
the
shifts
that
we
wanted
to
see
weekly
and
bi-weekly
felt
relevant,
but
then
it
kind
of
triggered
another
question
of
like
when
in
the
week
is
this
relevant
again
tying
back
to
the
right
frequency
problem
and
then
I
move
on
to
the
feature
discovery
part
where
I
started
trying
to
pair
what
notification
would
have
here
with
related
feature,
discovery
or
tip
so
say.
A
We
said
we
send
a
digest
that
is
built
around
merge
requests.
So
the
ratio
of
open
and
closed,
merge
requests,
which
higher
c
feature,
could
kind
of
be
relevant
in
this
workflow,
and
this
is,
for
example,
good
review
analytics,
which
is
one
of
our
premium
features.
It
could
really
match
this,
so
this
is
a
moment
where
you
know
it
really
felt
that
things
like
pieces
were
coming
together,
but
at
the
same
time
it
also
felt
that
all
this
was
not
really
grounded
into
reality.
A
The
first
one
was
internal,
where
we
pulled
out
some
engineering
manager
from
git
lab,
and
this
is
we
had
basically
a
what
was
it
30
minute
interview
with
them,
and
this
is
the
discussion
guide
that
we
prepare,
so
we
just
basically
look
at
trying
to
reform
it
over
the
pain
point
and
make
sure
that
the
one
we
tackle-
and
I
show
you
in
the
mural-
were
the
right
one.
By
asking
them,
you
know:
how
do
they
evaluate
their
team
performance?
What
information
are
they
checking?
A
What
is
important
to
them
if
they
could
show
us
how
they
were
doing
it,
and
once
we
kind
of
had
this,
we
moved
into
this
bit
where
we
listed
all
of
the
features
that
we
thought
could
be
interesting
to
an
nvc,
and
we
asked
them
basically
to
rate
it
on
the
scale
of
not
that's
all
useful
to
extremely
useful,
and
that
was
a
helpful
for
general
research,
because
basically
so
I'm
going
to
go
through
all
that.
A
Then
we
started
fleshing
out
some
domain
themes,
so
in
this
case
we
saw
that
another
request,
related
email
or
issue
related
email
was
a
topic
that
was
interesting,
but
then
this
is
where
we
took
another
step
back
and
where
we
felt
that
you
know
how
much
of
this
is
right
in
the
sense
that
we've
only
interviewed
a
gitlab
team
member
right.
So
how
bias
are
we
working
with
git
lab
all
year
long
and
having
our
own
workflows,
and
this
is
where
the
second
phase
came
in,
where
we
actually
shifted.
A
This
discussion
guide
into
a
full
survey
that
we
released
and
externally
so
we
got
overall
60
respondents,
I
think,
and
basically
our
main
takeaway.
We
kind
of
confirmed
some
of
our
hypothesis
that
weekly
digest
around
issue
and
marriage
request
activity
is
interesting,
but
we
also
seen
quite
a
lot
of
people
being
interested
in
cicd
analytics,
which
is
something
that.