the web design workflow

vector or bitmap

The first decision we make for design work is whether we’ll be working on a vector or a bitmap design. This will lead us to our choice of which app to use for the work in hand. Many graphics apps offer the tools and functions to work on both but most designers will have their preferred vector or bitmap tool (i.e. one that focuses on one or the other) and will stick to that depending on the project. If you have not yet decided on an app to use, try out a few options and find the one to suit you.

To decide which approach to take will depend on the project itself and its final output. What kind of design are we creating: a logo? An icon or icons set? A feature visual with photographic detail? A flat colour illustration?

Most could be created as either vector or bitmap but it’s the final output, the details and the nature of the visual which will determine which is best. Logos and icons, for example, are usually planned for various outputs: this could be printed on stationary, or even stitched onto garments, as well as displayed online in various sizes. Flat colour will therefore likely be the best approach ~ hence a vector graphic will be the best format to use.

If the visual contains photographic elements however, especially if the subtleties of light and gradation are essential to the image, the bitmap format is the only one which will yield the right end result. Considerations then will be all about the correct resolution for the final output. If the image is to be printed at a large size, for example, a high resolution will be paramount ~ bearing in mind that it is possible to scale down without the loss of quality but scaling up will deteriorate the quality.

Choosing the app, considering file formats

There are plenty of options when it comes to which software to use. And it’s important to remember that apps are merely tools ~ we can opt for whichever suits us, our mindset and workflow best. While web work in a studio might mean that a certain toolset is required, we should be open minded and try out the different apps available and be prepared to learn new tools as and when needed.

If you are worried that knowledge of a certain software is essential - then rest assured that those days are long gone. It will be your work and your skills that will get you the job, not knowing how to use any particular software. You might be expected to learn new apps but that is a given in most cases.

In addition to the tool itself, an important consideration is the file format. If we work alone, the final output is what we will plan for. If the working file itself is to be shared with others, then we have to consider which apps are used or use formats that remain editable in various apps.

Quick tip: When working in a team,
agree on file formats for file sharing
to make collaboration easy :)

For example, a SVG (vector) file is editable in most vector apps. Proprietary formats however are more difficult to manage. Working in Adobe Illustrator, we end up with a .ai file which only Affinity Designer can open but many other vector apps cannot. In turn, Illustrator will only allow us to open PDF files but not the .afdesign file Designer will create.

dimensions & units

With our chosen app open, we now proceed to create the new file - and we’re confronted with a seemingly endless number of options, dimensions and settings. There are various categories and many, many sizes to choose from ~ enough to make our heads spin.

By deciding on the overall dimensions by aspect ratio we can work at the largest size used for display and then create iterations to fit different outputs. For example, an icon is most likely used for profile images and as shortcut icon on homescreens. It will be square, i.e. have an aspect ratio of 1:1 and at its largest display size will be 512x512px, as shown in the following example.

A promotional feature visual will be quite different and likely have different dimensions, depending on the final use within the design. Working with the proportions given, the aspect ratio of this example is 16:9 - setting the dimensions to the largest planned display size will then allow us to edit the image at high quality and scale it down for optimisation as final step.

Quick tip: Don’t worry about presets to start off with!
Focus on aspect ratio.
Set your own dimensions to fit your project :)

By concentrating on the aspect ratio and working at the largest planned display size, we can bypass the complication of having to select a given preset for a given device. Our design process will therefore start with a fitting approach and flexibility in thinking.

colour space

Before confirming the settings on the new file, we’ll need to check on the colour settings. This again depends on the output of the design. Making this decision at the very start will mean less time needs to be spent on recalibrating the final colours. And this is an easy decision ~ for our work as web designers, we will always work in RGB.

The 2 colour modes vary in how a design’s colour will look in the final output. If we forget this setting and work in CMYK, the final result of the graphic will likely look more dull and less vibrant on screen. We can, of course, change the colour mode after starting the work but this will also change our colour’s tones and shades. We will then have to spend time on changing all colours to recalibrate the colours for the appearance we planned for.

As we begin a design project, we will produce quite a number of files, from drafts and ideas, to iterations and revisions to the final design files. This means that fairly soon we’re dealing with many files. Giving each file a meaningful name will save us lots of headaches and time.

Naming our files will help with the overall workflow, whether we are the only person working on the project or whether we’re team working. This applies to all aspects:

• content: text/visuals/media
• planning: site plans/wireframes/mockups
• design: branding/icons/layouts/style guides
• development: prototypes/production

My advice to newbies is to get into the habit of good naming straight away. It is easier to learn a new method than aiming to change your ways later on. And this applies to your own work, and to working in a team. You will go back to an old project at times and it’ll be easier to find a file if your folder and file names still make sense to you. And if you’re team working, your collaborators will be much happier if they don’t have to guess or open up all files to find a specific design.

naming project files

meaningful naming

One of the easiest ways to improve our workflow is to name our files according to their content. This will mean we can assume or conclude what a file contains without having to open it up. How exactly we choose to approach this will depend on content and focus of the image.

In our example project, we might collect research images such as different kinds of teapots, for example. This file collection could quickly grow and it would be useful to be able to quickly refer back to a specific file. For clear names of our teapot images, we might reference the design/shape of the pot. Alternatively, we could refer to the material or style of decoration ~ there are plenty of possible options.

keeping track of iterations

Once we’re in the flow of the design work (saving files into our ’work-in-progress’ folder we set up earlier), the next question is how to name the different design versions we create. Another complication that arises is how to best label revisions and iterations of the different versions. Deciding on a clear method for this will save endless confusions and duplications. Ideally, the file name will be specific and clearly state a reference.

Including version numbers in the file name for clear labelling will help refer to a specific design and its iteration at the same time. Once the initial versions have been proposed, the version numbers can then be added to (rather than re-named entirely), keeping all iterations linked to their original version. For example, the next iteration of the first version might be called: htr-logo-v01-1-traditional.afdesign.

organising files & folders

While we might start out with a fairly simple approach and only a few folders the the number of files will keep growing. It will be best to do a little tidy-up every so often. This might mean to ’shelf’ the early work on design versions and put related files into another sub-folder, to be kept for reference and archiving. We can then set up new folders for further revisions of the ongoing design work, such as iterations on typesetting or colour schemes.

Importantly, we will stick to meaningful names for any new folders and ensure that their names will clearly reference the content and are tied to the work included. This all becomes even more essential when we work on the website design and the site files as outlined in the following section.

planning

The work on a website project involves quite a few different aspects to deliver on its goal. It is never as straight forward as one type of file or material. It will be vital to start with content, even when you’re learning the basics. Don’t be tempted to work with placeholders ~ give everything context and real content, even your exercises. It might feel like it’s slowing you down initially but you will soon realise that it is indeed a benefit and the best way to work.

content out approach

Starting with our content, then planning the project and lastly moving onto design and development is referred to as ’content out’. Any design has a purpose - and the purpose of web design is primarily to present content - in the most accessible way with clarity and focus. Hence any web project starts with its content.

Content precedes design.
Design in the absence of content is not design, it’s decoration. Jeffrey Zeldman

While this is a beginner's guide to the workflow itself, this is such a vital starting point that it had to be included here :) Here is a quick summary of a typical process from planning to final production of a web project.

the planning folder

Any site project starts with a planning folder, a place to initially collect all content. The content then gets analysed, reviewed and revised with an eye on the site’s goal and target group.

Once the content has been prepared for online presentation, it is used for the site planning. This will involve brainstorming and site map iterations to come up with the best structure, the most effective IA (information architecture) for the site.

the work-in-progress folder

With a site plan in hand, it’s time for design work and prototyping. This folder will keep track of all our working files and could be organised into various different sub-folders. We could first work on mockups and then move onto prototyping, for example. Essentially, this folder will include all ongoing design work.

The nature of files and formats will vary and it will be a good idea to keep links to any online work as reference as well. We could save the web shortcuts, or keep the URLs in a simple text file. It will be important to keep track of all ongoing work, regardless of app or platform.

The website folder itself only includes files used for the site itself. It’s vital to consider both the structure of this folder and the names of all files within. A webpage will refer to each of its elements by file path, name and extension. This is why we initially configured our workspace for quick viewing of both sub-/folder structure and file extension.

naming conventions for web

The naming conventions for web files are not optional, they are an essential aspect of a well-functioning and easily found website. Server setups can vary (throwing up errors if file names are badly formed) and search engines will assess our file names (penalising poorly named pages) ~ sticking strictly to good file names is therefore of the utmost importance.

• Meaningful names.
  File names should be descriptive both for an easy workflow as well as for the benefit of SEO (search engine optimisation). Avoiding abstract abbreviations or single letter/digit file names will be a more effective approach.
• All lowercase.
  Different operating systems treat capitalisation in filenames differently. Using only lowercase will work best across all setups.
• No spaces!
  URLs literally cannot have spaces in them. Since we’re making websites & everything is an URL, our filenames cannot have spaces. For names including multiple words, we will use hyphens as separators.
• Only letters, numbers, and dashes (-).
  URLs only allow ASCII characters unless the characters are encoded. Since the specification specifically disallows non-ASCII characters our filenames will use only basic characters.
  While underscores for separation of words are permitted and can work, hyphens are preferable as many search engines (such as Google) will interpret them as separators, resulting in better search terms.

You might notice that our examples both for design as well as the site files follow this same convention. While it is not absolutely necessary for the design files themselves (before they are added to the site), it is a good idea to stick to the same method for naming of all files. One less thing to worry about when we move the final design files into our site folders :)

website folder

The structure of our website folder can take one of many different approaches. This will all depend on the complexity of the site in hand and we might organise our files by site section or file type. Generally speaking, we'll keep our structure as simple as possible.

Let's look at our example project and how its files might best be organised. For small projects likes this one, the folder structure can be quite simple and the sub-folders set up to reflect our site structure. Our site plan shows 4 sections with varying numbers of sub-pages. The required files will be of different formats: image files (JPG/PNG) for visual content and HTML/CSS for textual content and design.

As there are only a small number files with specific purpose, it will be logical to group the pages together and setup an image folder for all visual elements. This will keep the structure simple and we can choose to add more files as well as sub-folders easily in future should the site grow in content.

If you are new to webdesign your sites will likely be relatively small and therefore the following illustrated structure will serve you well.

If the site was more complex and included many more files, we might have a sub-folder per section which includes separate sub-subfolders for pages and assets. The most important aspect is to approach the structure of folder logically to make it easy to work with. File paths will be the ’glue’ that will bring it all together, hence keeping it simple and clear will be the most effective method.

website folder inside our project folder

To recap: this is how our website folder fits into our overall project folder. All site files will remain inside this folder during the development work.

The file organisation inside this site folder should be decided upon when coding begins. The file paths will be set and would need to be changed if folder/files are reshuffled or renamed.

manual versioning

When we worked on our design files, we were creating iterations of individual files and giving them numbers to keep track of revisions, edits and updates. This is fairly easy as it is one single file only, one that includes all elements in a single instance initially. When it comes to our website design however, this is not quite as straight forward. The site folder should only include files that are used for the site, and doing versions of individual parts within will soon result in a messy folder with too many unused files.

Once you are progressing in your journey into web design/development, you will explore tools for ’versioning’ - a method of working which keeps track of edits to files and code. Popular platforms are GitHub and Bitbucket and you will likely learn how to use these in due course. At the very beginning however, I would advise you not worry about learning these tools. They are quite complex and you will certainly look into them when you feel ready.
As a beginner however, first things first - it will be best to focus on learning the basics. And there is an easy way to still do some form of versioning which I would recommend: doing manual backups to keep track of your progress.

At any point where we make substantial changes to our site, be that to edit the markup (HTML) for a new content structure, or the design (CSS) for an update to layout - we make a copy of the entire site folder. Adding version numbers to keep track of the progress, we can then keep the existing version as reference and work on a new copy. If we make mistakes in our update, we can easily refer back to the previous iteration and restore a broken bit of code by copying it from the earlier version into the new one. A great safeguard against our own mistakes ~ and a great way to collaborate too.

A design file might start off quite messy ~ while we’re in the flow of coming up with ideas and concepts, our focus will be on the work itself, less so the neat organisation of our graphics and visual elements. And this is fine as long as we don’t get lost in our own mess :)

artboards/layers

Before we share our files with others however, we should tidy up and show them the courtesy of a neat and easy-to-use file. Organising our graphics into layers, using clear phrasing for names and making our file easy to understand will show that we respect everyone’s time and input.

• Meaningful names.
  for both file names as well as artboards/layers within. Before we share our working files, we will make sure that our file is easy to understand. This means the file name itself is descriptive and the artboards and layers are organised and named according to their content, too. Short and succinct names will allow everyone to jump straight in and find their way around our files easily.
• Grids and guides.
  Most design files will include some form of guides to align the graphic elements. We might use the inherent functions offered by the software or do those manually. If different apps are used by our collaborators it can be useful to create our own guides and place them all on a separate layer. This layer can then be hidden easily for a clear view of the design.
• Work with artboards if possible.
  Depending on the app in use, avoiding placing different versions on different layers will save time and make it easier to compare iterations. This is usually easily possible in vector app and will save time.

working with fonts

If our design includes fonts, we will have to bear in mind that not everyone will have the typeface in use installed on their machine. Sending any file with editable text can result in font substitutions and therefore render our design into something entirely different. It will no longer look as we designed it as a different font will be used instead.

Depending on whether or not everyone needs to be able to edit the typesetting - we have these 2 options:

1. share the font file
   If typesetting is part of the collaboration, we will have to share all fonts in use alongside the design file; fonts will need to be installed to ensure the work in hand will render as designed.
2. outline all text elements
   If typesetting is not part of the collaboration, then all text can be converted to a graphic; the functions are usually called something like ’convert to curves’ or ’outline type’.

Everyone is swamped with communications, emails and attachments - so it should be our aim not to add to this overload. It will be best not to send files individually but to create a folder to collect all required files. This will include the working file, any reference material (unless embedded into our file) as well as font files as needed. The appropriately named folder can then be compressed and sent easily in one neat package.

inspect online

One of the quickest ways to get help with our code is to make sure the site is online. We can then not only check on the code ourselves in different browsers and use the built-in tools to trouble-shoot - but anyone else can do the same.

Here is a screenshot of this page's header viewed via the ’inspect’ function. We can use the built-in tool by right-clicking an element and selecting inspect from the drop-down menu. An in-window panel will open where we can view the markup (HTML) and check on the CSS and its layout properties and much more. This will make for very easy collaboration ~ our code can be tested and viewed quickly as it is readily available online.

We should only ever send the files that are needed for the work in hand, keep our naming easy to understand and avoid overloading our helpers by all means. Should a file be too heavy to email (which can be the case with some design work) - we can use online services such as wetransfer.

back up! back up!! + back up again!

This is probably stating the obvious, I know - but I have to repeat this anyway. Do ensure you're backing up all your work, and more than just once. Making sure you have a copy of your files in more than one place will give you peace of mind should things go wrong. Ideally, you'll keep one copy on your working machine, one on an external drive and an online copy, too. That way you will always be able to get your files back if technical disaster strikes.

Backups are one of those things - we don’t really think of them until we need them, until there’s a problem. And things can go wrong: a technical glitch, a lost or broken device and all of a sudden, we have to find a way to get our files back, if possible at all. A good backup system will be a life saver ~ so don’t risk having to learn this the hard way - get yourself set up with a solid cycle of backups and you won’t get caught out :)