To see the websites I've made, check out my portfolio.

m-bread Web Design Methods & Policies

This page explains the various methods I follow and policies I try to adhere to when creating websites. I try to keep the user at the centre of all my website design, and most of the time this takes the form of making sure the website works no matter how they are accessing it, what sort of computer they have or how much experience they have. As such, I put a high priority on accessibility. See below for more information.

Design Methods

I do not follow a fixed design procedure that is the same for every website, as not all methods are appropriate for all websites. I pick the most useful methods in order to be flexible to the customer's & website's needs, and save time in avoiding unnecessary work.

The methods I use to design and make decisions about a website include the following:

Design Brief
For every website I must have a brief describing, in very simple terms, what the website is for. Without this there is too much possibility for confusion between me and the customer. The brief provides vital direction in how to approach designing and creating the website.
For every website I write down ideas for what it can contain, who it is for, what people will want to use the site for, and any other information that may be useful in designing the website. I can do this together with the customer, or on my own. If I do it on my own I then talk it through with the customer to get feedback, more ideas, and to check that I have got the right idea regarding what the website is about.
UML diagrams

If there are complicated processes in the website I can use diagram types from the UML to visually explain my ideas, or to explore other ways of modelling the problem. Even if the customer is not familiar with the UML, putting ideas into a diagram can be a useful aid to explanation.

UML diagrams are unlikely to be used in small, static websites where the pages do not change often. They are more useful in dynamic websites, such as shopping carts or other interactive or database-driven sites.


For anything other than small, static websites I will come up with a checklist of requirements that the website has to fulfil. This will then be agreed between the customer and me before I start work. It would cover what the website needs to contain, and what functionality it needs. As I work through creating the website I can prioritise the requirements and check them off as I go. To be most useful to me when checking the requirements of, they should be specific, measurable, and achievable/realistic.

I can also make a list of 'Qualitative Requirements' which give an idea of the 'spirit' of the website, and can be useful in giving ideas of what areas the requirements need to cover. These are more general, and definitely not specific or measurable.


Prototypes are useful for exploring if an idea is achievable & realistic. Prototypes will show what problems there are with the tested idea or model. These problems might have already been thought of, in which case the prototype shows their extent and can help produce ideas to deal with the problems. If the problems were unforeseen then the prototype is at its most valuable, as it has illuminated a problem that might otherwise have not come out until the final solution was being implemented.

Prototyping is making a working model of an idea. It will not look as good as the final solution, and will probably only be testing a certain area of functionality. If the prototype shows that there are no unforeseen problems with the idea, then it can be used as the starting point for making the actual site. However, if a problem was found, or if the prototype was not made in a way that was easy and secure to extend then the actual solution must start from the beginning. As such, a lot of extra effort can be involved when prototyping is used, and so I will only use it in larger sites, and the fee being paid must be high enough to justify the extra work.

Layout & Visual Style

For pages with complicated interfaces or procedures, I may sketch what the page could look like to experiment with different layouts and combinations of controls. I can experiment with different metaphors and conventions from other areas of IT. For example, people are used to using e-mail, so anywhere where the user is to enter a message the form can be laid out in a way that is familiar to the user from most e-mail applications. The designs can be shown to the customer for their feedback and ideas.

When creating the visual style for a site, I usually create at least three different choices, each quite different to the others. These will usually be displayed in an image, or as a website with no functionality except minimal navigation. The user can then choose one of those designs to be used, or pick the best bits from each of them.

Accesibility Policy

Accessibility is the ease by which people can access and use a website, regardless of what computer or device they are using or what disabilities they may have.

I strive to make all of my websites adhere to the W3C Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines (WCAG) to AA level (which is the medium level). To ensure that the web sites do meet up to this standard, I check them against the WCAG checklist.

AA level means that I have to follow priority 1 and 2 checkpoints, but not those with priority 3. However, I do use some of the priority 3 checkpoints where they are easy to implement.

I group the checkpoints into the following categories:

Text-only display

I check that the pages are clear and useful when displayed in a text-only format. This includes turning off stylesheets, images and interactive content. The pages should still be readable, displayed in a logical order, and easy to navigate.

To make sure this happens, I give all images and other non-text content text alternatives. I also make sure that the content of the page is specified in a logical order and that only stylesheets are used for layout, so that either all of none of the layout style is used.

WCAG checkpoints: 1.1, 2.1, 6.1

Use of standards

I check that the pages obey the rules set out in the standards that I use, and that I use the newest standard appropriate. For example, all my pages are created in XHTML and CSS, and are checked against the W3C validator before publishing. The pages will be in XHTML 1.0 following the HTML Compatibility Guidelines, or in XHTML 1.1. HTTP and XHTML meta-tags (using Dublin Core and GRDDL) will provide correct information about the pages to the browser. This will help it display them correctly and link similar pages together.

WCAG checkpoints: 3.2, 3.3, 3.5, 3.6, 3.7, 4.1, 4.3, 11.1, 11.2, 13.2

Different screen and text sizes

The visitor to any page should be able to make the text reasonably larger without breaking the layout of the page. If a visitor requires such a large text size that the layout does break, they should use the text-only view of the page.

Also, the page should display correctly on any common screen size, without the user having to scroll sideways. Wherever possible the pages will be made to work on small screens, such as on mobile phones.

Whatever problem someone may have with viewing a page, whether that may be because of their browser, screen or eyesight, the pages will be designed to make reading them as easy as possible.

WCAG checkpionts: 2.2, 3.4

Simple language

The language on each page is as simple as is possible in the context. Although some specific names or words have to be used (such as "CSS") the rest of the words can be kept simple.

WCAG checkpoints: 4.2, 12.3, 13.8, 14.1

Easy to use

Any interactive content in the pages is kept as simple as possible without limiting what it needs to do. The pages use conventions that visitors should be familiar with from other websites or computer programs. The visitor should be able to use the same input device (for example, a touchscreen, or a keyboard but no mouse) as they are used to for other programs. The pages should still be able to be used even when interactive content is disabled, or there will be a simpler page for people who do not want to use the interaction.

WCAG checkpoints: 6.2, 6.3, 6.4, 6.5, 8.1, 9.2, 9.3, 9.4, 10.2, 12.4

Easy to navigate

The names of the links in the menu should make it easy to find the page that the visitor is looking for, and the navigation should be consistent on every page. Also, there should be links in the content of pages where another related page may be useful to the visitor. A site map is provided on any site large enough; on small sites the main menu should be enough to allow the visitor to get to any page quickly.

WCAG checkpoints: 13.1, 13.3, 13.4

Other WCAG checkpoints

These checkpoints are unlikely to be applicable, but any page that is relevant will follow them:

3.1 Use text instead of images where appropriate, 7.1 Avoid screen flicker, 7.2 Avoid blinking, 7.3 Avoid movement in pages, 7.4 Avoid auto-refresh, 7.5 Avoid certain redirections, 10.1 Do not use pop-up windows, 11.4 Provide accessable alternatives to unaccessible pages.

To see the websites I've made, check out my portfolio.

If you want more information or a quote on a website go to the contact page.