Bank website design looks like a normal web project until the second review meeting. Rate tables carry disclosure obligations, accessibility is not optional for an institution serving the public, security and vendor review will inspect every third-party script, and the marketing team rarely has the final word on what publishes. Community banks and credit unions in particular tend to discover this after signing with an agency that has only built brochure sites. The useful way to compare candidates is on whether they have shipped inside these constraints before, and whether they can describe the constraints without being prompted.
What a bank site has to do that a brochure site does not
A bank site is simultaneously a marketing asset, a rate publication, a service channel and a regulated communication. Product pages advertise deposit accounts, and the Truth in Savings rules set out specific requirements for how deposit account advertisements state rates and the terms that go with them, which is why a rate table is never simply a design element. Locations and hours have to be accurate because customers arrive at branches based on them. Login and online banking entry points must be unmistakable and secure, since customers being trained to log in through an unfamiliar page is exactly the pattern phishing exploits. And every page must be usable by people using screen readers and keyboard navigation, which shapes the design system from the first wireframe rather than being retrofitted at the end.
Accessibility is a design constraint, not a checklist item
Financial institutions serve the public, and the Department of Justice publishes guidance on web accessibility and the Americans with Disabilities Act that treats inaccessible websites as a barrier to access. In practice this means colour contrast, focus states, form labelling, error messaging and keyboard operability are decided at the design stage, not patched by a widget afterwards. Overlay tools that promise instant compliance are widely criticised by accessibility practitioners and do not fix underlying markup problems. Ask a candidate agency to name the accessibility standard it builds to, to show you a shipped site, and to explain how it tests. An agency that answers with a plugin name has not done this work before.
What moves the price
Three factors dominate. The first is integration: a site that surfaces live rates, branch data, appointment booking or a loan application from core systems is a software project, while a site that publishes manually maintained pages is a design project, and the cost difference is large. The second is content volume, because banks accumulate hundreds of product, disclosure and support pages over the years and migrating them properly is slow, careful work that buyers routinely underestimate. The third is the review process itself. If compliance, security and executive review each add a week to every deliverable, the timeline stretches and the budget follows. Ask candidates to quote design, build, content migration and integration as separate lines so you can see which part of the estimate is actually large.
How to compare candidates
Ask for two shipped financial institution sites and visit them properly: tab through a form with the keyboard, check whether the rate disclosures are present and legible, look at how the login is presented. Ask who owns the code and the content management system licence at the end, because a proprietary platform you cannot leave is a long term cost that never appears in the proposal. Ask how search visibility is handled during migration, since a redesign that drops rankings costs more in lost traffic than the project saved in fees. Most banks buy design and search as one scope of web design and SEO services precisely so that redirects, page structure and content migration are somebody's explicit responsibility rather than nobody's.
Questions people ask about bank website design
How long does a bank website project usually take?
Most institutional redesigns run several months rather than several weeks, and the review cycles are usually the reason rather than the build. Ask a candidate to lay out the schedule with your compliance and security review times included, then ask what happens to the timeline if a review round takes twice as long as planned.
Do we need a new content management system?
Not always. Replacing the platform, the design and the content at once triples the risk in a single project. If the current platform can support an accessible, well structured front end and your team can publish in it, keeping it is often the better decision. Ask candidates to argue both sides rather than assuming the platform they resell is required.
Will a redesign hurt our search visibility?
It can, and the usual cause is unmanaged URL changes. Insist on a redirect map covering every existing page, a crawl of the old site captured before launch, and a post launch check against it. Ask which named person owns that task. If nobody owns it, assume it will not happen and price the consequence.
Can an accessibility overlay make our site compliant?
No responsible practitioner treats an overlay as compliance. Overlays sit on top of the markup and cannot repair a form that has no labels or a component that traps keyboard focus. Build accessibility into the design system and test with real assistive technology, then use tooling to catch regressions rather than to create the appearance of conformance.