Choose new navigation menu structure on homepage

[ShannonBad]

User Story

#### Background Based on #1561 research on the Federalist homepage and on the final research report #1667, design a new navigation menu for the website. *However, noted that this may cause the need for other IA structural changes to website. #### Acceptance Criteria Things to do: - [x] narrow down user needs vs. stakeholders needs (#1667 ) - [ ] Look at the language used to describe these functions (may need feedback from a content strategist for renaming navigation functions?) - [ ] Make a wireframe - [ ] User test wireframe (with non-users) - [ ] May need to iterate on design, based on user research #### Level of effort medium #### Implementation outline (if higher than "low" effort): see list above

[ShannonBad]

I have some concerns that this redesign might overlap into #1626 footer's content?

[wslack]

the footer is already done and in so this issue should treat it as part of the product IMHO.

[ShannonBad]

@wslack the footer is secondary navigation, so what we remove from the top navigation needs a place to live. Also I have concerns about not having a larger footer, and a lack of ease of implementation or possible accessibility issues (ie. screen readers). The current website navigation only shows the few top-level categories, with many things buried in "documentation", a sitemap footer make a complex site more discoverable - this is not a personal opinion but based on standard UX patterns.

[ShannonBad]

I asked on the accessibility slack channel about this because I am noticing that large site map footers are not on all government website homepages - which is either something I am overlooking or an accessibility issue.

[ericronne]

FYI @thebestsophist and i have been noodling on a site structure mural. We've evolved it based on yesterday's case studies meeting. Feel free to mess around in there, @shannonbad and @wslack. (And you can use that space to propose a mega-footer, if like.)

One way the public site could be structured …

• Landing page
  • Product
  • Overiew
  • How it works
  • Features
  • Templates
  • Fact sheets (downloads)
  • Case studies
  • Getting started / Walthrough / ???
  • User manual (links to documentation)
  • Contact us
  • Log in

[wslack]

Reviewed and 👍 as a good direction to drive to!

[wslack]

moved to "in progress" - maybe this can be made "done" if we're happy with the choice?

[ShannonBad]

Do we need the login button at the top navigation? Should it have a new name, since nobody seems knows why they need to login?

[ericronne]

I think it's good to have there, pretty standard. Handy for registered users, and newbies can explore public content to learn more.

cf

[ShannonBad]

@ericronne I agree that it is standard in nav, however the target user for this website is non-customers (and sales) and the Federalist login is for customers. Should it be named "Sign up" instead of "Login"?

[ShannonBad]

Also user manual sounds like its for existing users? Is it? Does "documentation" need more of a structure break down?

[ericronne]

isn't the site for both customers and non-customers? i defer to @wslack

[thebestsophist]

I feel like the documentation site need a bit of an overhaul since a lot of stuff is getting pulled into the main site.

[ShannonBad]

Just an idea - but would it be weird if we had a section for returning customers that was different than the main new users area (or a different website that was attached)? And what is leftover in "documentation" - is cleaned up/organized differently for returning users? I saw that when I login to Federalist I don't see the website anymore but I do see "documentation" as a link.

[thebestsophist]

What sort of content would you want in there? My intuition is as long as stuff is organized well, anything that is useful for returning users is also useful for anyone who is new.

[ShannonBad]

@thebestsophist I agree with your point about both parties could use this "documentation" tab, I just wonder if it needs to live in the navigation menu? Or could it be in a secondary navigation area, since it is a less relevant priority to a new user.

"Documentation" is visually designed as a not cohesive page with the rest of the Federalist site but it's visually cohesive with the login/returning user site. Within the "documentation" tab, I would like to see the left side secondary menu be less visually heavy.

1. I think once you break out "How Federalist works" from this secondary menu, we are still left with a lot of stuff here. And it appears it's mostly all related to "Using Federalist" - however they are not categorized as such in the menu (based on hierarchy)?

2. "About" - this page seems relevant to understanding how or why you use Federalist (new customers) - could this be brought to the navigation?

3. "Content guide" seems very relevant to this, but it's currently existing as a linking page offering a single link, and without any information so it visually looks less important.

4. "For Federalist Developers" - but who exactly is that audience for this tab, isn't everyone developing Federalist a "developer" (since this process is very rapid and easy)? Is this page about advanced technical features? Or about larger websites? Troubleshooting problems? Or all of the above?

5. If we make "documentation" remain a link between new users and returning users, we need to visually make them cohesive with design.

6. Side note: It bugs me that the top navigation bar doesn't tell me which tab I am currently on and can we make the same footer used throughout the site?

I am curious about everyone else's thoughts on this? I would like to see a seamless, cohesive flow between pages occur. I am concerned that by focusing our efforts on one section of the product's IA - we are missing the point of achieving better UX, since UX is holistic.

[wslack]

@ShannonBad Re: https://github.com/18F/federalist/issues/1668#issuecomment-371924588, I'm interested in seeing the findings from interviews, but IIRC I think there was clear understanding from people that "log in" was for people after they have an account.

The signup / log in flow is common enough that I feel confident about adopting it; many many other SaaS services have a main web address that both functions as a marketing site and provides the log in button to get into the backend for live customers.

Zoom:

Slack:

Separately, I think this issue is probably not the right place to discuss the flow/menu structure of the documentation site. That sort of thing should go into https://github.com/18F/federalist-docs/issues/165 (or a new issue). We haven't prioritized work on the docs site so far (though it will come) and the main site's top level menu is more important. Would it be ok to migrate this part of the discussion elsewhere?

[thebestsophist]

Just created a new issue in the docs repo, let’s migrate to: https://github.com/18F/federalist-docs/issues/212

[ShannonBad]

@wslack Re: #1668 (comment) a part of this comment directly relates to the main navigation menu (what to include in main nav.) - not sure how you would typically seperate this on github and still make sense? In UX design methodology we approach this as a whole, and I am not familiar with this teams approach to design. I am sorry if I made a mistake here.

[wslack]

Not a mistake at all! Just trying to keep conversation flows together. If this issue was "navigation menu structure on Federalist websites" then I would feel differently.

I assure you I'm not an expert in terms of best approaches, but right now I think our assumption is that the stuff in "documentation" or whatever we call it will all be accessed via a single menu item on the homepage of "user manual" or something like that, at least in the short term.

If you want to amend the structure in https://github.com/18F/federalist/issues/1668#issuecomment-371568698 with a link to a specific part of the documentation, that would go here, but my sense of your comment was more about the docs site. Because I don't expect us to finalize anything about the docs site right now (since its less a priority), I think the main site nav we're working towards might "stick" pending conclusions about the docs site.

In other words, my approach is very friendly to future revision through further discussion, but that discussion is subject to priorities.

[annahsgraves]

@wslack taking a look at this — I think the reason why you might have tagged me to this one is because of the next step in the issue:

Look at the language used to describe these functions (may need feedback from a content strategist for renaming navigation functions?)

Happy to chat whenever if it's helpful.

[annahsgraves]

I'd like to suggest we pause on anymore work here until we get through more of #1723. There are some small adjustments we can make now (detailed in #1685), but further evolution of the navigational menu should be driven by the IA that we settle on (which will be an output of user research and testing).

[annahsgraves]

@wslack I think this issue might be solved by updates being made in #1723. We can probably close this.

[annahsgraves]

@wslack I think we should archive this issue in favor of #1869.

[wslack]

👍 archiving as noted