git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Emily Shaffer <emilyshaffer@google.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Alice Merrick <amerrick@google.com>,
	Git List <git@vger.kernel.org>, David Aguilar <davvid@gmail.com>
Subject: Re: Let's have a user experience workshop
Date: Thu, 12 May 2022 15:23:12 -0700	[thread overview]
Message-ID: <CAJoAoZ=t=BEfsfHBay1K7CY2MYEwcvPYKYxvgv_BvLL3SMcf_A@mail.gmail.com> (raw)
In-Reply-To: <Ynndk0L6r9O7jLVU@google.com>

On Mon, May 9, 2022 at 8:35 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
> A few bits I took away:
>
> 0. Examples
>
> The examples Alice gave, especially from the Go project (generics as a
> UX project!) were interesting and helpful.
>
> 1. Continuing the conversation
>
> I and some others (e.g. David, cc-ed) ended the workshop wanting to
> discuss a little more --- when deciding (1) what to work on and (2)
> settling on a design for that work, what has worked well for us in the
> past?  What didn't work?  What research methods have we tried?  What
> would we like to try?  We mentioned wanting to continue that
> discussion on-list, so trying that now. :)
>
> 2. Sharing research
>
> Some of us are already doing some research, in the form of surveys,
> metrics collection, testing with prototypes, analyzing user issues in
> internal bug trackers, and so on.  It would be nice to share that
> more, so different participant's studies can build on each other.
>
> I'm curious about what a good form for that is in an open source
> project.  Should we send findings as papers to the mailing list?  Do
> we want some kind of repository (using git, Figma, or some other tool)
> of findings that we build together collaboratively?  Whatever we do is
> likely to involve some extra work to deal with confidentiality; how do
> we notice when something is worth the work of jumping through that
> hurdle?
>
> 3. Testing ideas with users
>
> It's not unusual for there to be a question on-list about some facet
> of the UI such as an option name, that ends up being decided as a
> matter of taste.  Alice mentioned that we have a chance to make more
> user-focused decisions by just talking to a few users, which can be as
> simple as recruiting five users from #git on IRC and sending them a
> private message asking questions like "Suppose you have just run this
> command; what would you run next? What would you expect that command
> to do?"  This seems like a straightforward addition to our workflow
> that we could get better at over time.
>
> Do you agree?  If this is a good idea, how would we like to go about
> it?  (E.g., how do we notice when there's a question that could
> benefit from that kind of experiment, how do we come up with the
> questions for users, and how do we present the results?)
>
> 4. Stating assumptions about users
>
> Another theme was that when we choose what to work on and form designs
> for our work, we regularly make numerous assumptions about users'
> desires and goals, habits, what will be intuitive for them, and so on.
> Stating these assumptions would have a few benefits:
>
> - they would make the rationale behind a design clearer, which makes
>   it easier to continue to honor that design in the future;
>
> - when those assumptions turn out to be false, it would be easier to
>   revisit early design decisions;
>
> - they could give interested people ideas for how to follow up and
>   check those assumptions;
>
> - over time a clearer model of the user would emerge that could be
>   useful to make use of in later designs
>
> The downside, of course, is that it can be embarrassing to make
> assumptions that turn out to be wrong, but that seems like a small
> downside relative to those benefits.  So I am thinking it could make
> sense for us to make a concerted effort to describe these kinds of
> assumptions in commit messages more often.  If this seems like a good
> idea, I'd be happy to send or review a patch to SubmittingPatches
> saying as much.  What do you think?

For all 4 of the above - I wonder whether it really makes sense to try
and organize those things asynchronously. If I'm being honest, what
I'd much prefer would be a monthly-or-so working group meeting with
other folks interested in performing research, making recommendations,
learning how to improve Git's UX, etc. I'd absolutely make time to
attend such a thing, and I believe it would be the easiest way to
organize research and concert our efforts. Would other folks be
interested in showing up, too?

I'd envision it as something between a working group and a book club -
we could learn different aspects of UX design and research, and apply
them in various ways. It might be nice to have Alice along for at
least the first couple of sessions to answer questions and help us
learn in a bit more targeted direction than we got at the workshop.

 - Emily

  reply	other threads:[~2022-05-12 22:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 21:04 Let's have a user experience workshop Alice Merrick
2022-03-16 17:36 ` Philip Oakley
2022-03-16 17:48   ` Emily Shaffer
2022-03-16 21:50     ` Philip Oakley
2022-03-16 20:10 ` Michal Suchánek
2022-03-16 20:41   ` Emily Shaffer
2022-03-16 21:34     ` Michal Suchánek
2022-03-16 22:05     ` Junio C Hamano
2022-05-10  3:35 ` Jonathan Nieder
2022-05-12 22:23   ` Emily Shaffer [this message]
2022-05-15 16:17     ` Jonathan Nieder
2022-05-16  7:43       ` Emily Shaffer
2022-05-20 16:17         ` Alice Merrick
2022-05-20 16:22           ` rsbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJoAoZ=t=BEfsfHBay1K7CY2MYEwcvPYKYxvgv_BvLL3SMcf_A@mail.gmail.com' \
    --to=emilyshaffer@google.com \
    --cc=amerrick@google.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).