Posted on Sat Apr, 29, 2017 at 12:50 PM
Hi everybody, it's me, The Geek
On our last podcast, I discussed how to choose a web designer/developer. However, after a review of my comments with Sensei, I realized that it was pretty fast, with a lot of information that may have been a little much for some people to be able to take in. So in this series of blog posts, I'm going to review my talk, hopefully in an understandable manner.
This is part two of a three-part series, in which I'll discuss how to go about getting a website built. In part one, I discussed how to determine the roles you will need to get your site built. In this second part, I will discuss how to go about evaluating prospective designers and/or developers to fill those roles. In part three, I will discuss where you can look to find the people to hire.
Now that you know how to determine which roles you will need for the building of your website, the next thing to discuss is how you will evaluate prospective designers and/or developers. For people outside the industry, this can be a daunting task, as they are evaluating the potential performance of someone who is doing something that the person evaluating does not understand themselves.
When talking to designers and/or developers, one of the main things you want to pay attention throughout the process is how well the person explains themselves. Often they will be building something that you can't really see, so they need to be able to explain it in a manner that you can understand. The better they can explain themselves, the more smoothly the process will proceed, and the more likely you are to end up with a result you are satisfied with. Ask them things about their how they actually go about building a piece of functionality - tell them something you want, and ask them how they would go about creating what you want. The important things to listen to here are, how well did they explain it? How much input did they get from you? Were they able to adapt their ideas to new information you provided? If there is a limitation on a piece of functionality you want, were they able to explain why that limitation exists, and provide potential alternatives?
Evaluating a designer's work product is a fairly straightforward task, as the design is the most tangible part of the website. It's the part that can actually be seen. The most important thing when evaluating a designer is to take a look at previous sites they have designed. Any designer worth their while will have a portfolio of websites they can point you at to see what they are capable of. Take a look at these websites, and consider if the design looks nice to you, if it catches your interest. Then try using the site and see how logically it is laid out. If it's a business website, and you need a map to that business, is it in a place you would logically expect to find it? Can you get to it in a minimal number of clicks? If you need to log in, is the login button in an easy to find location? If they are selling something, are there buttons that stand out to you quickly where you could click to buy it? When evaluating a site, you want to look at how nice it looks, how logically it is laid out, and how effectively it represents the purpose for which the site was actually built.
Evaluating developers is much more difficult, as their product is intangible. That said, if you use the functionality of a site, you'll get a feel for their work. Ask for examples of sites they have built. When you log in, post comments, post images, or buy a product, does it happen bug free? Do you have annoying error messages that are difficult to understand? If you make a mistake, do you have to re-enter information, or is it still there? If the site pulls information from other sites, does this happen smoothly? Does the information pulled match what you would expect? These are the types of things to look at when evaluating the functionality of a site.
You can also ask if they have any certifications. Web development is largely a self-taught profession. There actually are courses that can be taken in web development, but they are usually taught by instructors who are not in the industry and therefore are not keeping up with current trends. Real learning only comes through experience in actually building sites. What's more important than initial education is that developers will have taken the time to self-further their skills by getting various certifications. By getting a certification, they show that they are interested at being at the top of their game, and that they have taken to learn a given technology to its standard. For example, I am a 'Drupal developer'. Drupal is a framework that is used in the back-end for major sites used by organizations such as The White House, NASA, and Tesla Motors. I have achieved the three Drupal main Drupal certifications: developer, front-end specialist, and back-end specialist. I did this so that I can show to those looking to hire Drupal developers, that I am an effective Drupal developer, and can use Drupal the way it is supposed to be used, rather than just hacking through it.
Next, you can ask if it's possible to talk to former or current clients. You can ask these clients about how it was to work with the designer/developer, if they were satisfied with the end product, and if they weren't able to get some functionality they wanted, whether the designer/developer was able to clearly explain why not.
As you are looking for a website, all of the above will help you decide of the person you are considering can build what you want. But there is more to many websites than just the website. You also need to consider the environment around the website.
For example, after the site has gone live, and you want new functionality, do they have a 'staging server' where you can see and test the functionality, before it is actually put on the live site? A proper developer will not do any testing on a live site, they will have a separate hidden site that is only accessible to you and them, where you can see and use the functionality, approving it before it is pushed to the live site. If any bugs show up, they will only affect you, and not your live users.
You also want to consider their backup system. Ask them if they use a Version Control System (VCS). A very common system you can ask about it called GIT. This is a system that tracks changes in code over time, so that at any time they can go back to a previous version of the code. For example, imagine you asked for a new commenting system on your website. When you push it to the live site, you find out that the site crashes any time you post a comment. A version control system will allow the developer to revert back to the code before the comment system, with a single command, in a matter of seconds. If the designer/developer is not using this type of system, they will have lost the previous code when creating the new code. Using a VCS means the old code is never lost.
You don't necessarily need to understand their reply, rather you just want to listen to whether they are actually using some system, and that they come across as being confident in their ability to use it effectively.
You also want to ask about database backups. Databases hold all the data in a system - user accounts, and content posted through the website etc. If the database crashes, you could lose all this data. A good designer/developer will have a method in place for database backups, in case something every goes wrong.
Next, ask if they have any profiles on online design/development communities that you can take a look at. These are places where people in the industry can find solutions to their problems, and help others with solutions to their problems. If you find that the person asks a lot of questions, you know they are inquisitive, and working to increase their knowledge. If you find that the person answers a lot of questions, you know that they are knowledgeable, helpful, and are able to solve a lot of problems when they arrive.
You can also ask to see any example of publications that they have. Tutorials are a good place to see that a person knows how to code. Blog posts will show that they know their industry. Case studies will give an insight into systems they've built.
Finally, as a related note, I'd like to point out something NOT to do when evaluating prospective designers/developers. You generally should not ask them to do 'spec work'. Spec work is when you ask them to do some work for free, in order to determine whether they meet your expectations. From a customer standpoint, asking a couple of designers to submit an example of what they would build for the top page of your site may seem like the best way to evaluate their design ability. But, any designer who has made a name for themselves will not do spec work, as their portfolio will already speak to the work they can do. Often designers and developers will get a lot of their work through word of mouth, and won't be willing to do free work to get work. So when you ask for spec work, the only people who are going to do it are those who are still trying to make a name for themselves, and will generally not be of a professional standard.
You can however ask to hire a designer for a day's work, to evaluate their work product. For example last year in my company, when we were building an in-house project, I hired three top-level designers for a day's work each. I was very clear to them what I was doing, explaining that I had chosen three agencies whose work I liked, and wanted to get a day's work from each of them in order to evaluate their process, and to see what they would produce in that day. This was an expensive venture, costing me about USD$1500 for the three designs. From this, I was able to look at the questions they asked, the process of communication, and how they presented the final product to me.
So now that we have discussed how to determine which roles you will need, and how you can evaluate potential candidates for these roles, in part three, we will look at where to find someone to fill these roles.