Our Thoughts

What should I know before speaking to a website developer or agency?

dev language
Written By
Published
Categories
Help and advice, Web Design
Reading Time
19 minutes

Even for someone in a high level marketing role, if you’re given the responsibility of sorting out the new website for your business, it can be a pretty daunting task.

The Simpsons (and any cult film) has suggested that I.T nerds (developers) are seen as tricky people to deal with. As a web design agency who employ all sorts of tech savvy individuals – we have the right to tell you that there is some truth in this.

The person writing this blog post is not a developer (most of my experience is in branding). Being ‘Creative Director’ at a web design agency has meant that, as someone who doesn’t code, i’ve been in many conversations that have gone over my head. Nodding along, picking times to chuckle or agree. But over the years I’ve picked up enough to enable me to engage and understand, and this is what I’m able to help you with now!

 

What should you be looking for in an agency or developer?

In a nutshell – relevant experience. Every single person or business you’ll be looking at will tell you they are amazing at what they do. You need to look at the proof – and check out websites they’ve built that are similar to the one you need. If they’ve done it well a few times before, then that team or individual should be well placed to do it again.

Another thing that might be wise is to use people who are used to dealing with similar sized businesses and budgets to yours. You don’t want your project to be too big for them to deal with, but you don’t want your project to be the least financially beneficial to them too. It’s your responsibility to find a good fit. Don’t fall into the trap of thinking a huge, expensive agency must be better in general – all they’re better at is dealing with large projects and are used to invoicing additional costs without warning. On the other extreme, don’t go to the place with the lowest day rate thinking they’ll have the same level of service as more expensive places,- in most cases, they won’t.

 

The first meeting.

The developer or agency you’re getting in touch with will probably aim to get you in for a meeting. This is so they collect as much information as possible to build a proposal with. We have a ‘Briefing Questions’ sheet which we email to a client before meet. We find it helps to get the client thinking about the right things, and having the requested info sent over to us beforehand makes that first face-to-face more fruitful. It’s always worth making sure the people you’re speaking to have enough information from you – so, ask them “do you have everything you need from me before we meet?”

The meeting should be quite informal and, if it’s going well, should be exciting. No doubt you’ll be offered tea and there’ll be plenty of small talk too. This is your opportunity to find out some more about them – so take advantage of that and scope out their team, have a look at their workspace… do the staff all seem to get on? Is there a nice vibe to the place? Or if it’s a freelance developer – do they seem easy to work with? Have you asked them about their other recent work? Be nosey.

 

Tell them about your business.

Start the conversation with something easy. Tell them about the business you need a website for. What’s your story? They might have had some of this information from you already, but it’s the most important thing they need to know, and it starts the conversation off on a nice flow. Then let them lead the conversation and ask them as many questions along the way as you want.

 

What type of site are you asking for?

Perhaps the first thing the developer will want to work out is what sort of site this will be. In terms of size, functionality, complexity. What you’ve told them about the business will inform them to a degree, then they might ask a few other questions to join the dots. Examples of questions they might ask before or during the meeting: What is the purpose of the website? What do you need it to do? Do you have any example sites that do a similar thing? Here are some terms the developer might use at this stage:

  • Brochure site: Imagine the sorts of things people put into a pamphlet in the 80’s. A brochure site is your modern day pamphlet. If your site needs to do is display information clearly, exhibit your branding or show examples of work – then it’s all pretty basic web development and a brochure site is what you need. Depending on what you have in mind, you might even want to look at the free options like Squarespace and see if you need a developer at all.
  • E-commerce: If you’re business is pretty much selling stuff online, then you’re in the e-commerce game. An e-commerce website will allow you to have a shop on your website to sell products from. The whole purpose of the website is to sell the products from your site, so the thinking behind it, the user flow – will all be with this in mind.

Note: A brochure site could also have an e-commerce element if it has a merch page, but the purpose of that website might not be to drive traffic to the merch page.

  • Web-app: Or sometimes SAAS (software as a service). This is something online that opens in your normal browser, but performs more advanced functions… like a management tool. You or I might call it a website, but a developer would refer to it as a web-app, or SAAS.
  • Social network: The popularity in social media has meant that thousands of other people are trying to launch new ones. Building a social media platform is actually easier than you might think because of existing code that performs much of the standard social media features you’d recognise. But it is a lot more involved that a standard website.
  • Blog: You don’t need a developer, unless you want your blog to do crazy things! Just use WordPress’s most basic package and away you go.

 

Platforms & Frameworks.

These are terms the developer will use with their team, but might be in the proposal too. This is possibly a little too technical for you to worry about for an initial conversation, but if it’s mentioned and you understand it, you’ll feel good.

Platform: This is the underlying language a website will utilize. Common ones are PHP, ASP.NET and JSP. Some platforms are open source, meaning they’re free to use and most bits of code are shared amongst the very engaged community. So, there’s an ever growing pool of resources and code modules for the developers to use. From our perspective, it’s good when a website is built on a popular open source platform, because it’s easier to maintain and there’ll be more developers who can work on it. It will probably also make it cheaper for the client.

Framework: Once the developer has decided what platform to use, then they decide what framework to use. A framework is like a tool box, which makes creating the code easier and quicker. Some common frameworks are: Laravel, Python, Ruby on Rails, Node.js.

 

WordPress – what is it?

WordPress is a framework but also a pre-existing application. One third of websites in the world are WordPress websites (that’s a lot of websites), so there’s a likelihood it’ll come up in a meeting. WordPress is, in its simplest form, a pre-made blogging website that is able to be customised to huge degrees because it is open source. WordPress sites can be very simple or incredibly vast. Our recent blog post explains why WordPress is so incredibly popular. Wow, how many times can we say WordPress!?

WordPress is also a Content Management System. It’s user back-end panel is widely used by and already familiar to most marketing professionals.

If your developer has suggested WordPress, they will most likely do one of the below:

  • Use an existing template and customise the content. ‘Paint by numbers’ is an analogy that might fit this case. This is a good way of getting a tidy, functional website that is cheaper and quicker to build than a custom website – but is limited in terms of functionality and creatively.
  • Or, the developer might build a custom template and then hook it up to WordPress, building custom themes in the CMS so the user can edit all the content. The client gets all the benefits of WordPress but with as much creativity, customisation and functionality as they need.

Note: WordPress uses the PHP language, which is also open source.

 

Types of developer.

Generally speaking, there are front end developers (client software) and back end developers (sometimes called ‘server side developers’ because they deal with server software). Some people can do both – known as ‘full stack developers’, but the skill set and attributes needed for each one vary and so usually someone will be more inclined to specialise in one or the other. We can think of it in simple terms as being the stuff a user can see and interact with (front end), and the stuff they don’t see (back end). Or, a common analogy is the body work of a car (front end), and the engine of the car (back end).

Front end developers often have good design skills and can knock up a brochure site for you no problem. A back end developer would usually be part of a larger team, where they’d be working on the logic or database, and thinking like a computer, in ways I still can’t comprehend. The bigger and more technical a website is, the more back end work it’ll need. Good back end developers (they sometimes call themselves programmers) are worth their weight in gold in Silicon Valley. They’re the hipsters of the tech community.

 

Are you needing someone to design the website as well as build it?

There are two main elements to making a website:

  • The design. Think of this as the artists impression, or the 3D version of your new kitchen before it’s made. A designer typically does this.
  • The creation of the code that actually makes it all happen. A developer will do this.

Some talented individuals can design and code (known as Unicorn developers, because they’re quite rare), and they might even design ‘in the browser’ meaning they will go straight to code and mess about with design on that phase rather than take time to properly design it first. Ideally, you want to receive image files from the agency or freelancer you’re using, showing how the site will look… before they build it.

So – you might want it to be designed and coded up by the same team, or you may have a designer already (maybe someone who made your logo or does your posters for example) who you want to use to design the site before you take it elsewhere to be built.

Some websites will also publicly or internally host their pattern library. A pattern library is essentially a collection of the design elements that were used to create the website. A new member of a team, for example, would be able to create a document or design a new template for the website just by using the pattern library as a guide. Good pattern library will save a lot of time, especially within larger organisations where new staff who need to become familiar with the brand are employed regularly.

 

Sorry, but they’ll ask what your budget is.

Money will always be an influence, but make that part of the wider decision rather it being the only deciding factor. Your website an investment which you will see a return on. The better the website, the better your return on investment will be.

We find that some clients will tell us what their budget is straight away, and some won’t. The client wants a good deal, but they don’t want to be the first to say a figure. We understand, and are happy to quote based on the initial brief as a starting point. 50% of the time we’ll find out the budget before writing the proposal, and we’re much more likely to win those jobs because everyone’s on the same page from the start.

Really, you shouldn’t be walking into this with the aim of getting the cheapest deal. It should be to get the best results. You should try and get at least 2 quotes to compare price and proposals. Ideally get 3 or 4. Then you’re likely to decide based on the quality of the proposal rather than the pricing.

 

Assets.

Logo, font, brand colours. Do you have these already? Basically do you have a brand? If so, they’ll need them. If not, you’ll need to have those made. Most agencies can sort that for you. Done properly, this isn’t a quick and easy job – so be prepared for this to make up a significant chunk of a proposal if it’s part of the website build project.

 

The process of making a website.

It’s good to have an idea of what the website making process should look like once the proposal has been signed off. This will probably have been clearly stated in the proposal anyway. If not, ask about the process and see if it’s anything like the below.

 

Research & Discovery.

Your developer or agency might mention research and a ‘discovery phase’: user research, competitor research, stakeholder workshops etc. It will usually make up a percentage of a proposal and is often questioned by the client in order to cut some costs that could have been seen as not essential. Research and testing is absolutely an essential part of the process. No two websites are the same, and so even the most experienced designer or developer will need to include time in a proposal to look into and test elements of their concept or build. 

We like to plan a one day workshop with the stakeholders and encourage a collaborative approach to gathering the information we require. This phase will go on to inform the entire scope of the project, and help to determine who delivers the project within an agency. The more collaboration throughout a project, the more you can rest assured it’s on track. 

 

Content.

A website is just a load of colours, shapes and purposeless buttons if there’s no content. Content means: all the copy (words) and images, mainly. It can also mean video, podcasts etc. Basically all the stuff that you or your marketing person makes. A good agency will hand you a content scope at the beginning of the project detailing what is needed and when. It’s then up to you to provide them with that content in time to ensure the project isn’t delayed. The agency will need to know what the content will be at a very early stage. They won’t be able to plan where things need to go without knowing what the things are. A lot of projects tend to be held up by the client not providing content by the agreed date, so it’s worth noting that this part of the project is collaborative and responsibility lies on the client to get the website builder what they need.

 

Wireframing.

Wireframing is an initial sketch of each page, simply detailing where content, CTA’s (call to actions), forms, navigation menus etc will go. Wireframes should be done first and are sometimes sent to the client to sign off (in our case they are) – if wireframes are all agreed and in good shape, when it comes to design and build the site – you can’t go too far wrong. Everything’s in the right place, and that’s all been agreed.

 

UX – User Experience.

As you guessed, this means the experience the user has when on your website. Is it intuitive? is it clear? does it lead them to the parts of the site you want them to go to? This is all tied into the wireframing process, and then tested fully in user testing phases. 

The feel of the site, the little scroll effects etc, does it match your brand? Do you need it to feel slick? Who are your audience and how will they use the site? UX is crucial to the effectiveness of a website. This will all be considered throughout the project and might be added later on too. A very obvious example of how an audience will change UX is if the site if being designed for children or adults.

 

Copy and UX copy.

Copy often takes a back seat, only really being considered after the website is built – this is the WRONG way to go about it. Words are part of the design. Messages inform design. What the copy says is what the site needs to do. This is more relevant to UX copy rather than larger blocks of text like ‘about us’ copy or blog pieces.

User experience copy is a new term but picking up in popularity. It’s all the words on a site that glue it all together. They’re the sort of words and copy that you don’t really notice yourself reading. Like, what it says on a button, an error message, instructions on payment info fields etc. All this stuff is usually written by the developer, but you might want to ask if there is a UX specialist in the team who’ll be looking at it, because it’s pretty important!

 

Flat designs.

The designer can take all of the above and get to work on the page designs. They might design the header and footer separately. They’ll be in touch with the developers throughout this process and version 1 designs will be sent to you, the client, to feedback on or approve.

 

Prototype for User Testing.

We would usually build out a prototype at this stage with the purpose of carrying out some user testing.

User Testing is a fundamental part of what we do at Huxley. A lot of agencies use it as an opportunity to test and strengthen their work, but sadly some agencies avoid it in the fear it will uncover weaknesses. The truth is – exposing weaknesses is the best outcome of user testing, and why it is so valuable to the client. Testing, branding, design and basic functions at this prototype stage allows the team to see how the website is used by real people. Individual, filmed tests can be carried out, as well as focus group testing. Reports are made and presented to the client with lists of findings and actions. Testing is carried out again after the proper web build.

 

Website build.

Once the designs are approved it’s time to build the website. Developers build a website ‘locally’ at first, meaning it isn’t accessible anywhere other than on their computer. At some stage they’ll ‘push’ their progress to a ‘staging site’ which is usually hosted on their server, so you can have a look at the work. The developer will push their changes only before they’re to be reviewed again, so don’t think of the staging site as a live work in progress.

As previously mentioned, user testing is carried out again here and actions are taken against any notable findings.

 

CMS – Content Management System.

A content management system allows a website admin to be able to add and amend content on the website. If you don’t have a way of doing it yourself, you’ll be asking the developer to make small changes or add blogs (for example) which is NOT an efficient way of doing it. Asking for a CMS is pretty standard, and most people use WordPress. Some agencies might have their own CMS.

Whether or not you’ll have a CMS will be decided before any work starts but most sites will have one these days. If the site is being custom built (rather than a template) then it’ll be integrated with the CMS later on in the project.

 

QA.

Quality Assurance. This is as vital as any other part of the process. Once a website is built it needs thorough testing. This will be done by the developer at first, then usually it’s thrown out to the client to test too. We’d be looking for bugs, typos, inconsistencies, SEO weaknesses and a whole load of other things. I’ll mention user testing here too. For projects with a budget that allows user testing, this can be a very important and useful part of a build. UX issues in particular can be highlighted and then fixed, meaning a more effective website. QA is often something a client will request to be removed from a proposal to save money – but we strongly advise against this. A site that has not been fully tested after completion will usually contain bugs and need design tweaks – this is completely normal. These will only be done later on and billed as additional work if they are not done as part of the main project.

 

Soft Launch.

We like to make a website live and continue with QA for a small period of time, because it’s best to have real people use the site before saying it’s been 100% tested. The soft launch typically lasts until the client makes a song and dance about their new website.

 

Live.

The website goes live. You’ll be invoiced. We give a month’s warranty as standard – to fix any other bugs etc that might be noticed after launch. It’s worth speaking to your developer about post launch support. You might want to get a SLA (Service Level Agreement) in place to make sure any improvements or fixes can be done at short notice each month. SLA’s will also ensure your website is being monitored regularly in terms of security, and security features will be updated when needed.

 

3 Month Review.

Not all agencies / developers will offer this, but we like to carry out further user testing and a analytics review 3 months after a website goes live. A Google Analytics report will give a detailed view of how the website is performing and how the visitors are behaving. The test users will be given slightly different UX tasks than before. Some people believe that user testing should be carried out at set, regular intervals. With new competitors popping up and the marketplace ever shifting, it’s important to stay on top of how your users see your place in the industry and how they’re effected by competitors and the content you’re putting out.

 

If you need help with a project, or just a friendly conversation about to get some questions answered – contact us and we’ll try to help.

 

Thanks for reading this blog. We hope you found it useful.