1) Don’t underestimate the importance of Information gatheringThe information gathering phase is where we rely on our clients to help fill in the blanks. It’s okay if you don’t know the answers to all the questions we ask but it is a great benefit to a project to be prepared to speak about the following topics: your user goals and the business goals, site objectives, pain points, features/functionality and comparable websites.
2) The sitemap reflects the pages of your website not the contents of those pages.We see it quite often when we are working with new clients. There is a tendency to put all content on the sitemap at the starting of a project. The sitemap reflects the pages of your website not the contents of those pages. If we were to follow this line of logic we would have a pretty dull looking website with all the individual pieces of a page isolated. Take for example a page dedicated to a contact form or a search bar. Decisions to on how to integrate these elements into a site make up the wireframing UX phase of the project. These decisions should be made after the pages have been established. This will allow them to be properly contextualized within the website in a way that benefits the user experience.
3) How to name your menu itemsMenu labels should be named in a way where they consistently speak to the people who use your site. Consistency in this sense is where they all represent a similar lens from which to navigate the content. Take for example the menu items: "members", "public"," volunteers”, “council meetings", "contact". Which one of these items is out of place? If you removed "council meetings" from this list, you would have an easily digestible menu at first glance because the other menu buckets are consistent in their language and can be understood in how they relate to each other. The "Council meetings" heading is too specific, so it makes the user think that they maybe be missing something on the page and takes away from the clarity of their journey through the site.
4) The forgotten “functional requirement”Generally, when we start defining requirements for what we build we find it helpful to focus on two different aspects. The first is how the piece we are developing is going to function on the website and the other aspect is how are we going to build it so that it is easy and intuitive for you to manage. It’s important to think about usability beyond the front-end. Our team carefully consider how you will administer your site from the backend – not just what the user sees. Surprisingly this is often over looked so we always come up with a few different options for how we envision the administrative side of things to work, but we would encourage anyone to start this conversation with their web development company as soon as possible so that the details can be worked out from an earlier point in time rather than relying on last minute changes.
5) When to involve your stakeholdersIt is not our place to tell you how to communicate with your team, but we can draw on our experience here and offer a bit of advice. Typically projects with multiple stakeholders tend to get bottlenecked when there are too many points of interaction. The initial stages of the project often require heavy stakeholder involvement but once we have gathered enough information and we go through the project we suggest that they only check-in the larger group when we are presenting or need approval on the major milestones ie wireframe, creative brief, mockup, Alpha and Beta site reviews.
Related BlogsHow to Create Your First Sitemap
Is it Time To Redesign Your Website?