Re: wireframes for images to illustrate Content Usable

Hi,
What a lot of work! great job!
Some initial comments. We can have any number of images. Originally we
thought of one "good example" for each objective or user story. Personally
I think it will be a lot clearer if we have one per user story (about two
on average per objective)
That way it will also be easier to see that every pattern is covered
without making the page cluttered. Does that make sense?
If we do use one image as a "good" example, then we need to check it
against every pattern. Whilst we can  "avoid" each bad example.   I think
we can not do included a sample "use" example for each pattern, especially
highlighting the start of a task, the warnings before a task, breadcrumbs,
easy login  etc.


On Thu, Apr 1, 2021 at 8:59 PM Rain Michaels <rainb@google.com> wrote:

> The Content Usable Images subgroup (Jennie, John and I) have been working
> on wireframes to help more clearly communicate the needs of the example
> *"good*" image to the designer.
>
> *We have created this Google slide deck with these wireframes
> <https://docs.google.com/presentation/d/140aQM0BGbt9YE1Ehb3i1mIzJOxcxQerEgIaFbvOCols/edit#slide=id.p> for
> your review.*
>
> (You may have to ask me to give you permission to the deck once you click
> the link above. I tried to add everyone, but some email addresses were
> rejected when I shared the deck.)
>
> We hope to be on the agenda for next *Thursday, April 8*, to get all of
> your feedback and turn over a revised set of wireframes and requirements to
> the designer.
>
> Please take a look before then, if you can.
>
> *Ways to provide feedback:*
>
>    - Add comments to the deck
>    - Reply directly to this email
>    - Wait until our meeting on Thursday and offer your feedback then
>    - Ask me (rainb@google.com) to share the figma file with you directly
>    so that you can comment there, if this is something you want to do
>
> *A few notes about the slides themselves: *
>
>    - *Slide 1: the key image*
>    If we are only able to provide one image initially, this shows what we
>    want it to include, as it represents a snapshot of where the user might be
>    mid-way through the process of purchasing flowers.
>    - *Slide 2: the key image with annotations*
>    This slide does not contain any new visual information. Instead, we
>    have annotated, with arrows, what some of the visual elements are intended
>    to do to support cognition and understanding.
>    - *Slide 3: the key image with tab index*
>    For the sake of clarity, we took the time to represent how the user
>    would navigate through this experience if they were a keyboard only or
>    switch user. While this may not end up in anything public, we did this work
>    to make sure that the designer has this in mind.
>    - *Slide 4: landing page to buy flowers*
>    If we can show more than one image, we would like to show multiple
>    points in the user journey. This image represents what the user sees *before
>    *they have added any filters to the view, or selected any products to
>    add to their cart.
>    - *Slides 5 & 6: filter dropdowns*
>    If we can show more than one image, or show details at various points
>    in the document, these slides represent what information the user should
>    have available to them when they expand the dropdown menus to add filters.
>    - *Slide 7: modal detail for "help me pick"*
>    If we can show more than one image, or details of the user journey,
>    this slide shows a modal that would appear for the user if they select the
>    "help me pick" button.
>    - *Slide 8: modal detail for "ready to buy"*
>    If we can show more than one image, or details of the user journey,
>    this slide shows a modal that appears when the user selects the "ready to
>    buy" button *or *when they select "check out" from the cart.
>    - *Slide 9: representation of single column*
>    This slide represents how we imagine this experience would reflow in
>    the event that the user is zoomed in or the user is on a small mobile
>    device. While it might not make it to any public facing material, we feel
>    that it is important to communicate this to the designer, as well, so that
>    it can be considered when creating the design itself.
>
> Please don't focus on the aesthetics. We intentionally left this somewhat
> "ugly" in order to prevent interfering too much with the designer's ability
> to do their work.
>
> These are meant to be wireframes only, and any colors that you see are
> simply to help communicate our goals to the designer.
>
> We are also coming up with a separate business requirements document to go
> with this deck, but that document will be prepared after receiving all
> feedback so that it takes all feedback into account.
>
> Thank you,
>
> Rain
>