Designed disabling retrospective anonymity

[enriquesanchez]

Issue - Enhancement

From #2806:

When I run a retro in a culture where we individually discuss each reflection we wrote, I want to be able to see who wrote them, so that as a facilitator I can call on each person to share and add color

Just before I start a retro, I want an option to disable anonymity, so that we can have each card author be identified to share more color on their reflections

Before a retro meeting starts, the facilitator can toggle on/off the anonymity of reflections, and meeting participants are made aware of it.

Open questions

• Do we allow this by user (like thread comments) or by meeting (some toggle as meeting settings)?
• Do we allow this by phase (e.g. anonymity is removed at the Discuss phase)?
• How might we indicate that reflections are public so that meeting participants are aware?
• How can we keep the inputs and cards minimal? E.g. use an inline name to start the reflection instead of an avatar

Acceptance criteria

• Create and end-to-end concept for toggling anonymity of retro meetings
• Iterate as necessary based on feedback
• Draft implementation issue

Estimated effort

• 21 hrs

[alihashim]

I think related is the ability to have "non-hidden" tickets in the reflections. I think anonymity can be toggled as well.
Real world scenario:
During in person retro, we come up to the board and stick a post it note with our reflection. It does not have the author name on it.
A way to force shown tickets on reflections would be amazing. It also gives people time to view other tickets and help remind each other of what happened during the sprint. It also makes it easier to group and vote if everyone has seen the tickets beforehand.

[jordanh]

Bumping this one up the backlog a bit based on the frequency of feedback we keep getting

[ackernaut]

This customer 🔒 emailed me today:

I wanted to share a quick feedback from my teams at [company name]. We have ~10 teams that developed and use an internal tool to run their retrospective mainly because there is no option in Parabol to make the reflections not anonymous. Their rationale is that transparency is recommended in retrospectives and anonymity of ideas can be incompatible with this.

Do you already have something like that or would this be possible on your side to implement such a feature? E.g.: on the retro creation screen, a toggle to decide whether feedbacks are anonymous the same way it's possible to include icebreaker

[acressall]

New designs ready! https://www.figma.com/file/o3q946BB5UlYZw0RJeNHdx/Non-anonymous-retros?node-id=0%3A1

Meeting setup logic:

• Anonymous will be selected by default
• The anonymity checkbox will only be available on retros
• For other meeting types, they will only see the icebreaker checkbox

Reflection card logic:

• The user's name will be appended as soon as they begin typing / the card is in focus
• The name will not be editable in this iteration
• when editing they can only select up to the non-editable block
• the name block is inline, i.e. it doesn’t take up an extra line, it just wraps

[ackernaut]

@acressall as we discussed, I think this design is a good starting point. Couple of thoughts:

• We check with developers about how easy it is to include a styled, non-editable block inline after the editable content
  • as early as when the user initially writes their reflection,
  • and when they edit
• We take a quick look at what the anonymity checkbox looks like in the current start meeting view

[mattkrick]

As written, this is pretty difficult! Our new WYSIWYG editor, TipTap, is almost at feature parity with DraftJS, which is what reflections use today. If we build to spec, I'd suggest we wait until we move reflections to the TipTap editor so we don't throw any work away. I imagine this'll be done in the next month or 2.

Alternatively, we do what we do in the discuss phase today when you reply to a reply. It acts like instagram & just at-mentions the person you're replying to. you hit backspace & that mention goes away. we could borrow that pattern & build this quickly. The downside is folks could remove their name if they wanted to. Overall, the feel of it is a little janky, I don't love injecting text on a user's behalf & the value add is just typing someones name for them, which doesn't feel overly compelling.

Another alternative would be to stick their avatar on the card as a watermark like we do with integrated tasks. that way it's immediately obvious that it's not anonymous & there's no way they could remove it. we could build that quickly.

[acressall]

Thanks for your feedback @mattkrick! I want to make sure I understand correctly..

Another alternative would be to stick their avatar on the card as a watermark like we do with integrated tasks

It sounds like this is the simplest solution, is that correct? Would it be just as easy to have the user's name rather than their avatar? In a design chat we thought the name at the end of the card (below the reflection, rather than appended) would be ideal but assumed it would be more work than appending. If that was a wrong assumption, I'm all for changing it!

[ackernaut]

The idea of an avatar watermarks concerns me. I have this impression folks don’t upload their avatars, but I wonder if we could find out. If I just saw some random ‘J’ or a ‘T’ on one of our cards I may wonder who that is. Sure, in this case folks would benefit from uploading their avatar as in other places (avatar groups for presence, or voting, etc.). I think this will still be frustrating for people. I agree if I saw a photo it may be quicker recognition except for those folks that use avatars that aren’t clear and I forget who they are. On the other hand, I think using text actually gives more priority to the written content without decorating with a face. I think in general these should feel generative and less anchored on the person. A name I have to read feels less personal than a face, which is the information hierarchy that makes sense to me. It also probably keeps the cards feeling lighter. It’s a trade-off: a face per card (feels a little heavier to me) or an inline name per card that sometimes causes wrapping, sometimes doesn’t. For the times it doesn’t cause wrapping we’re effectively maintaining the same, lighter footprint we have today.

[enriquesanchez]

Raising a +1 to Terry's concerns above.

A watermarked avatar would not be clear enough and will instead make it harder or cumbersome to identify the author. On short reflections (a few words, one line) the watermark will most likely be behind the text making it hard to read.

To me, appending the name after the text feels like the safest idea to try.

[acressall]

@mattkrick is a version of this where the name is below the reflection (and essentially separate) any simpler than the design concept above? My aim is:

• The editor is irrelevant
• The text is non-editable
• When a card overflows to a scroll, the name is at the end of that scroll (see example in "stop" column), so we're not worrying about sticky positioning

[ackernaut]

I assume both will take some work:

A) switch to the new editor; add a name inline

B) add the name below the content; this adds a condition to laying out the cards in any view or state (e.g. the animation while being dragged by another user), which to my understanding is not trivial

In either case, I think appending a name is the better design path, and am willing to see the work done for it. However, since it’s less than trivial, it may delay shipping what seems like a simple addition as it competes for dev time. I can be okay with that, too. I’m not confident that using avatars for this purpose is a strong enough UX to justify making it because of the trade-off for a simple dev solution.

[acressall]

I'd like to make sure we don't over-discuss and can propose a path forward. As I understand it, this change could have an impact on one of our largest accounts.

I personally prefer the second design, but will concede this is a personal preference. I think both options are safe from a UX perspective, so would like a developer to make the call on which is the simplest to implement.

[Dschoordsch]

@acressall Once this issue has passed design review, please create an implementation issue in "Backlog" for it.

[Dschoordsch]

Adding the name at the bottom of the card feels safe and is not technically difficult.

I wonder if we should add the avatar there as well like in the task cards, or if this would be too distracting and could lead to ambiguities?

[acressall]

I'd like to leave out the avatar for now for two reasons:

• I don't think it should look too much like a task card, so it can't be easily confused
• It might get distracting, when the focus should be on the reflection itself

[igorlesnenko]

I created the implementation issue: #7032

[jmtaber129]

In addition to changing the placeholder + adding the user's name, have we considered something like a modal when a user enters a meeting explaining that reflections are non-anonymous, either as part of this issue or in a follow-up? I'd worry that putting the user's name on the card and changing the placeholder may still be too subtle for some users.

E.g. a pop-up on meeting launch that says something like

Your facilitator has chosen to make reflections non-anonymous. Reflections will show which team member wrote them.

with a little "got it" primary button that closes the modal

[ackernaut]

@jmtaber129 I like the empathy toward potentially catching folks off guard. I wonder what user job stories may be at play.

• If my team has a culture for using public retros (some folks have been explicit that this is their culture, hence they ask for this), I wouldn’t want to see that dialog every retro
• I wonder if a dialog is a little too heavy; what if we scoped something that direct (direct = you have to close it to proceed) to the first time a team runs an anonymous retro? Probably hard to track when an actual group is having their first public retro?
• Maybe there are some other ways to indicate a retro is in public mode? Maybe a small badge in the main view that doesn’t conflict with the timer or phase competed components? Other ideas?
• As is, it’s probably safe to move without this affordance; we could take up a design exploration later; we could even wait until somebody writes in with a tension around not knowing the retro was public (hope they didn’t say something too spicy about the boss 😆 )

[ackernaut]

Napkin sketch for indicating non-anonymous mode, do not ship! 🤣

[gcrickman]

This user 🔒 also asked if reflections could be non-anonymous.