So that users clearly understand how to engage with the FEC for feedback on betaFEC, develop and implement a contact/feedback strategy

[jenniferthibault]

Here are a few light personas/scenarios that embody the needs our feedback channels must meet:

• "Plz Discuss" users who want to engage in discussion about betaFEC
• "Send and End" users who will report feedback or errors, but don't desire back-and-forth conversation
• "Curiosity Rovers" users who would be interested in participating more deeply in the site's research, though interviews or usability tests
• "Do not contact" users who want none of the above, and prefer an undisturbed experience of viewing the site.

Users who fit these profiles have mixed levels of GitHub proficiency.

Design goal:

Provide users an outlet or channel for their engagement and feedback, while keeping the number of channels or tools to a minimum, so that feedback is in as much of the same place as possible.

---

Here is one possible strategy:

PRIMARY PATH: Feedback tool on the site

Ideal for "Send and End," "Do not contact"
Could be improved to meet the needs of: "Plz Discuss"
Could we include one additional (optional) field at the end of the form (either before submit, or after submit success) that says something like:
If you would like to stay updated and receive notifications for conversations on this thread, enter your GitHub username.
or @jmcarp is there another way to connect the feedback tool to someone's GitHub?
This tool would be on every page of the site, including the home page

ALTERNATIVE PATH: Feedback email address

Ideal for No-to-low GitHub savvy "Plz Discuss," "Do not contact"
This could exist for "Plz discuss" users who aren't GitHub savvy, though the email address should be located on the site in a location that is secondary, or less visible than the Feedback button. Possible options: website footer or contact page. A member of the FEC team must be responsible for replying to the emailed feedback, and then populating the feedback into a GitHub issue manually

ALTERNATIVE PATH: Link to GitHub repository

Ideal for GitHub savvy "Plz Discuss," more technical folks
This could exist for "Plz discuss" users who are very GitHub savvy, or for folks who follow 18F that are accustomed to viewing and engaging in the details of our work through GitHub. Priority should be equal to the email address. Possible options: website footer or contact page

BONUS FEATURE: Ethnio

Ideal for "Curiosity Rovers"
Embed a link to Ethnio in the feedback tool so that users who choose to offer feedback can choose to go one step further and participate in further research. This would turn Ethnio into an add-on, instead of a path of its own.
Pros: Doesn't over-disturb or over-interrupt the experience of all users
Cons: We may receive fewer volunteers for interviews and tests, since the Ethnio screener isn't hitting visitors unless the choose to give feedback in the first place.
Though—we'd still be getting more volunteers than we were getting before when we didn't use Ethnio at all.

First steps from here

• @noahmanger & @onezerojeremy : validate or adjust the light personas I've created above. Are they accurate? Anything missing? These personas should define the strategy, so they need to be adjusted before we debate any alternative strategies

[jmcarp]

@jenniferthibault: if users want to subscribe to an issue, they can tag themselves in the feedback, or click through to the issue and click "Subscribe" from the issue page. These both seem pretty awkward.

I can think of a few alternatives, neither of which seems perfect.

• Add a second submit button ("submit with my github account") that opens a new issue dialog in a new window with the user's feedback pre-filled. The user would need to be logged in, and to submit a second time from the issue page.
• Add a "login with github" button that creates a GitHub access token and allows us to file issues on behalf of the user. This could be nice, but would require some backend changes.

In the event that the feedback widget gets spun off as a new library or service, these might be nice additions, but for now, I'm not sure either's worth the time it would take to implement. Just some thoughts.

[LindsayYoung]

I feel like the feedback is for bug reporting and feature requests, if they want to contact us for a deeper conversation, they should use the email. I don't think GitHub is for having conversations with all users.

I think the beauty of what we have now, is that it is light-weight bug reporting and feature requests. If we want interactive conversations, I think that is something we would want to buy zen desk or some type of full-featured tool rather than making a bespoke tool for it.

[noahmanger]

This is terrific. Thanks for the thorough write-up.

As far as personas, I was going to suggest that the "Plz discuss" falls into two types — non-github savvy and github savvy — but I see you made that distinction in the solutions.

A few other thoughts:

1. I agree with Josh and Lindsay that it's probably not worth the dev time to really flesh-out a fully-featured solution to discussion around GitHub issues beyond simply providing the link. I think that savvy users who are interested in having a discussion will go through and submit an issue with their own account. And simply having the email address is good for those who aren't savvy but want to have a conversation.
2. I like your idea of making the feedback email address less prominent than the feedback button. Makes sense to drive people towards a primary feedback call to action. Also, you're alternate path of providing a link to the github issues at equal prominence to the email address makes sense to me as well.
3. As far as Ethnio, I'm starting to think that we should be thinking of this as a "method of feedback". Like, we don't want people signing up to just give us their opinions. And so providing it as an option alongside bug-type feedback reporting feels a little weird to me. So the more I think about it, the more I think we should keep the Ethnio pop-up separate. It only shows up for people the first time they visit, and then never again. We could also embed it on /data too, and it would share the same cookie, so users wouldn't see it on the home page and then the /data, they'd just see it one or the other, depending on where they arrived.

[jenniferthibault]

Interesting! I'm good with all three points.

On Ethnio especially, that's a really helpful perspective. Embedding it with feedback reporting could definitely be confusing. I hadn't thought of putting it on the data page as well, so that all sounds A++ !

If we're ok with this, then it sounds like here's how we go about it:

Tasks to completion:

• Adjust home page copy to ask users to give feedback using the tool at the bottom of the screen. It will replace the following copy on home page Explore our new content and data, and send your feedback to [email protected]. @emileighoutlaw
  • implement @jenniferthibault
• Write footer copy for emailing feedback and GitHub link @emileighoutlaw
  • design @jenniferthibault
• Write contact page copy for emailing feedback and GitHub link @emileighoutlaw
  • design @jenniferthibault
• Add feedback tool to home page @noahmanger
• Add Ethnio screener to home page (left side so it doesn't conflict with feedback box) @noahmanger
• Add Ethnio screener to data page @noahmanger

[noahmanger]

Ok, added the Ethnio screener to the data site #886

Also, the Ethnio screener is already on the beta home page in the left (open the page in incognito mode to see).

[jenniferthibault]

@emileighoutlaw did you have a chance to resolve any thought on the footer copy?

@jmcarp I can't find an issue that tracks this, but want to confirm— will the feedback tool will be on the home page?

[emileighoutlaw]

I think it still needs some mulling, but for now, let's go with 18f.gsa.gov style: a linked URL and icon

[icon]github.com/18F/FEC

I think we can leave the betafeedback email as is, but we might want to consider adding the [mail] icon in front of it

[jenniferthibault]

@emileighoutlaw when mocking this up, it made sense to either go all-icon or no-icon since it's the identical info to the Contact page, once you include the email address.

Thoughts?

[emileighoutlaw]

I think I like it better no icon. What do you think?

[jenniferthibault]

My favorite strategy when I'm not sure about somethign: keep trying other things! This led me to realizing we may need a headline cue:

^ I prefer this one

[emileighoutlaw]

Oh yeah! I love that second option. It gets rid of symbol next to the address and phone number, which were the only two parts that felt a little unwieldy in the original design.

[jenniferthibault]

👍 ! I'll try to implement, but may need to tap in Noah for help.

[onezerojeremy]

agreed, looks great!
also, that email is moving so fast!!

On Thu, Nov 5, 2015 at 4:18 PM, Jennifer Thibault [email protected]
wrote:

[image: 👍] ! I'll try to implement, but may need to tap in Noah for
help.

—
Reply to this email directly or view it on GitHub
#866 (comment)
.

[jenniferthibault]

Closed by:
https://github.com/18F/fec-cms/pull/116
18F/fec-style#174
and #928