Closed jenniferthibault closed 7 years ago
Note from sprint planning: use visual tools such as concept sketches (or other) to facilitate conversation.
The main areas of feedback that came in are:
"Serve the largest groups best" We talked about this one in the first meeting last week, and it felt least on the mark. There are user groups, like filers, who have a statutorily required relationship with the FEC. Since they are legally required to interact with the FEC, the FEC should make them a high priority group, irrespective of the size of that group.
"Folks are uncomfortable with treating the size of the users base as the defining metric at the expense of considering other users' level of involvement (and risk) in the campaign finance process. We believe we owe it to filers to serve them at least equally as well as members of the general public."
"Help users self-identify which tasks apply to them" This one also came up at the first meeting with a little follow-up after, because it seems like we are closing the door too much on helping users self-identify what FEC user group they are. In order to perform all of the requirements for FEC activities, users must eventually learn what group they fall into in the world of campaign finance activity. We could investigate different orders to facilitate this learning.
For example, I've been thinking about it in terms of which order you put the information in. We can use a sentence to demonstrate, but that can also happen visually, with how you present information:
"I am a ________.
That means I need to _______
"
or
"I need to _________
so I must be a _______
"
or
"I am looking for a __________
so that I can __________.
That must mean I'm a _________
"
The three units are tasks, audience type, and object type. We can try different orders and test them with users to find which they navigate the easiest.
To start prepping visual tools for the principles conversation, I started this Mural where I've broken down modules of things we can start sketching in different ways.
Today I'm going to start collecting examples of modules on other sites that do this. I'll drop them into the mural.
@jenniferthibault Thank you for the excellent feedback summary!
I love this:
"I am a ____. That means I need to _" or "I need to ___ so I must be a _" or "I am looking for a __ so that I can __. That must mean I'm a ___" The three units are tasks, audience type, and object type. We can try different orders and test them with users to find which they navigate the easiest.
I think it is a very helpful way of communicating the problem and possible approaches to solving it.
I will check out the Mural!
Hello there! I'm ready for some feedback!
When I pulled apart and reassembled all the principles, everything under “serve the largest group best” fit neatly into the other six principles. Since there’s no rule that we have to start and end with seven principles, I went with this reshuffling (and a few others) to see how things shook out. I actually think this version might get at all the things we care about. [Revised] Principles are on the first page of the [Draft] Principles
document.
I don't think we're 100% there yet, but I think we're getting close. Feel free to mosey over to that doc and take a look. Or, if you'd like, read a full accounting of my changes in the section that follows.
cc @nickykrause @noahmanger @jenniferthibault
Moved the subpoints of Serve the largest group
into other sections
Help users identify which tasks apply to them
Prioritize
.Meet users at their level.
Reordered the principles Once our number 1 principle was gone, it felt like the list order needed reconsidering. I tweaked thing based on what my understanding of our priorities (and the challenges we want to face head on).
Tweaked some of our phrasings and other subpoints All of these are definitely up for a gut check.
help users identify which tasks apply to them
so I moved it.Thank you so much for the lovely writeup, @emileighoutlaw ! Reading through made me feel like I made these updates right along with you.
I am totally in favor of fewer principles as a starting point, and love how you've pulled things together. Reading through made me realize that the remaining tension between Provide a clear and consistent conceptual structure
and Help users identify which tasks apply to them
could be resolved if we admit that identifying tasks is the organizing conceptual structure.
Since task-based nav vs audience-based nav seems to be a tension point, would it be too vague to instead write Help users identify which tasks apply to them
as Help users identify their goals
?
That could mean that a goal is a task, or an exploration, but maybe I am pushing it to be too vague.
Responding to this, from @jenniferthibault:
Since task-based nav vs audience-based nav seems to be a tension point, would it be too vague to instead write Help users identify which tasks apply to them as Help users identify their goals ?
I think the underlying point here about taking out the word "tasks" does make sense, and it might not make the principle too vague to change the wording.
On the idea of goals: We do have research to suggest that the users' "goals" most likely take the form of task completion. So, when we design against the principle of helping users accomplish their goals, we would lean on the research to understand what those goals are. (Meaning: The principle itself does not have to prescribe the goals as being task-oriented).
But, I just said "helping users accomplish their goals," which is different than the wording of "help users identify their goals." I don't know if "goals" is what we are helping users to identify. We are maybe helping them to identify information that will help them accomplish their goals, or to identify pathways to accomplishing their goals...? Hm. I'm not sure. Also, in the latter case, it wouldn't just be about helping them identify all the pathways, but the most effective ones.
Maybe something like "Help users to identify what content will meet their needs?"
Awesome thoughts, y'all! Looking at at the sub-points under Help users...
-Create easily recognizable paths to frequently referenced material. -Users share overlapping goals. They don't fit neatly into buckets. Ensure that people in different groups can accomplish the same tasks, if needed.
sheds light on what principle I think we're actually trying to support. In this case, I think it's Help users accomplish their goals.
An important piece of accomplishing goals is identifying what content applies to them. There might be another bullet to be added to that point, if y'all agree.
@emileighoutlaw Great! yes, agreed
Agreed as well! I gave a last read-through & comments in the document.
I wanted to also give an update on the visual side of things: how we could use the mural of modules to talk about the principles.
Here's an idea for an in-person exercise/discussion prompt:
We might get something like this:
From there, I'm of two minds of how we go with it. We could think of the session goals as
One focuses on process, participation, and open discussion, the other focuses on leaving with a product.
Would love all thoughts and feedback on this exercise, as well as what the goal of it should be. If it's ok with you all, we can also introduce this to the FEC team today when we talk through the revised draft principles, and see if they think this is a good format or activity to do in the first place.
@jenniferthibault and I talked about this earlier, and I just want to say, Jen, that you have already brought this so far in such a short time! The pictures are so helpful in understanding what the exercise would be and how it would work. Your ability to communicate visually is endlessly impressive to me.
To your question at the end: I think I am leaning toward the emphasis on participation and discussion, rather than walking away with a product. There is a part of me that wonders if there will be a lot of pressure on the exercise itself to produce the perfect solution, if there is a sense afterward that the ideas will become our wireframe options. (But, perhaps that is not the idea?)
Also, I worry a bit about not having enough time to reflect, in the session, on whether or not the proposed/sketched ideas will indeed be workable. I don't want the partners to feel, coming out of the session, like we've settled on a wireframe option, and then we have to come back later and say it won't work for some reason? (But, maybe that's unlikely, and maybe that wouldn't be there expectation).
I am also in favor of vetting the idea with the FEC folks. Maybe we frame it to them, though, as a recommendation (since it does indeed seem useful, and like something we ought to do) rather than just passing idea? Maybe then, if they have concerns about it, we have more hope of refining it into something we all can agree would be useful, rather than tossing out the idea of this kind of collaborative session?
And by "tossing out," I meant "abandoning"
Since the principles have been redrafted & prepped for next steps, I started a more precise issue to prepare for the homepage meeting in https://github.com/18F/fec-cms/issues/545
Closing this in favor of that issue.
After presenting the first draft of the principle list on 9/22, and receiving feedback collected by Amy & the FEC team, we should revise the principles and prepare a new draft to bring to our in-person workshops.