When designing internal pages for all sites:
- When creating a general page layout, be sure to include a side menu (with nested elements if applicable).
- Include a contact form in the footer
- Include breadcrumbs (these are good for SEO and add an additional navigational element.)
- Do not carryover poor design or UX decisions from their current site. For example, if they have a search bar in the header of their current site but the site is 10 pages, they do not need a search bar and we shouldn’t include it because it requires more effort to setup and is generally not necessary.
For Law Firm sites
- Attorney Bio pages:
- These pages typically include contact details, a bio with a varied content structure (that includes paragraph content as well as multi-level lists and subheadings), portrait/headshots, badges/logos, and a method of contacting them directly (usually via an “email-me” button).
- It’s important to note that not all attorney bios are equally filled out. The design should work for attorneys that have robust bios as well as attorneys that have nothing at all. For that reason it’s best to keep any unique design elements in the header, in one continuous area above or below the body content, or in the sidebar of the page.
- Generic practice area page:
- These pages should be built for ease of maintenance. This means that we should design in a way that allows us to manage the page content via the WordPress editor, rather than via the layout (such as we’d do for the home page). Things we should avoid doing:
- Placing photos in the body content of the page.
- Placing design elements in a way that breaks up the page content. This is OK if it’s a divider that appears after each paragraph or a styled bullet list (so long as it is something that can we can style using CSS so that the styles apply automatically to content that is managed via the WP editor).
- Adding styled callout boxes at the bottom of the page (see the practice area pages of parthemoscurranlaw.com). This is OK for small sites, but is tedious to build for larger sites as it requires the content to be copy pasted into a special field on every page the feature appears.
- Using a practice-area specific photo for all practice area pages. If the firm takes multiple case types, we should not have a photo of a car accident on a page about family law. Try to use a general photo OR if you are going the extra mile, select photos that relevant to each practice area as well as a general photo (for utility pages and non-practice area pages) and include them in Figma with a note for the developer.
- These pages should be built for ease of maintenance. This means that we should design in a way that allows us to manage the page content via the WordPress editor, rather than via the layout (such as we’d do for the home page). Things we should avoid doing:
- For Trade or Service-based sites:
- Service Area page:
- These pages can be designed without many limitations, since these pages are likely going to be more descriptive and include more graphics,, pricing details, and other types of content. We can set these up using custom fields when building the site so the content dynamically flows into the necessary areas of the layout.
- The design should be scalable, in that it should be able to work for other service area pages (i.e. maybe one page has a relevant gallery but another doesn’t – in which case, we should put the gallery in a full-width column somewhere where it won’t look awkward or disrupt the structure of the layout if it was not included on one of the pages.)
- The key thing is that any design element that is not common across all of the service pages is considered so that the layout still works if that element is missing from the page.
- Generic Internal page:
- There usually aren’t a lot of these on these types of websites, since the bulk of their other content will be in the form of blog posts, gallery pages, FAQs, testimonials and the other utility pages. Design with functionality and versatility in mind so that we can effortlessly scale the site without needing to involve a developer post launch.
- Service Area page: