Dev journal part 1 – How to prepare for a project

Ivan
・April 6, 2020

This post is a part of the series where we go through the process of creating a website in WordPress from A to Z. This is the same process I’ve followed while building this blog’s theme and it’s written as part journal, part guide you can follow along from in order to get from 0 to a finished deployed custom WordPress-based website.

  • How to prepare for a project – You are here
  • Building the website – coming soon
  • Deploying – coming soon

This part is about everything that should be done before you write a single line of code.

Intro / Disclaimer

While this process may work for me, it may not work for you. Maybe you’re the kind of person that wants / needs more preparation, maybe you’re the kind of person that wants to jump into a project right away.

This is written from the perspective of building your own website (where the client is yourself).

Maybe instead of this you’re a freelancer and are about to start working on a website for one of your clients. Or maybe you’re a developer working for a web development agency. In either case, some details might be different:

  • You might have a finished design or you have to come up with one
  • Maybe you already have all the requirements or maybe you have to write them yourself

Either way, apply this guide to your own situation and put your own spin on it.

Since we got that out of the way, let’s get started!

A place for everything and everything in it’s place

This might be an obvious one but…write things down! Why keep everything in your head when you can write something down and forget about it until you need it?

If you’re already doing this – awesome! If not, try doing it for this project and you just might like it.

Where / what should you write?

A single document (on Google Docs for example)

From now on you can use this document for all your project’s info that’s not actionable. Examples of things that should go here:

  • Requirements
  • Target audience notes / info
  • Links to other relevant resources (such as design files, tutorials, etc)

A to do list

It doesn’t really matter what you use, I personally use Trello for all personal projects. It’s free and easy to use. Whatever you use, you can open new cards for everything that needs to be done (everything actionable) and free your mind from having to keep track of so many things.

I try to break things down into tasks (cards) that are 16h of work max. Then each of those tasks (cards) has a checklist for everything that needs to be done for that task (card) to be completed.

Examples of tasks (card):

  • Preparation
  • Initial setup
  • Taks for each component that needs to be built (we’ll talk about component-based development in our next part)
  • Blog posts

Here’s a simple example of my Trell card for the header:

Example Trello card for Metadev's header component
Example Trello component card

Header can be done in 1-2 days and it includes some mini-milestones in the order of which they should be done.

What are you doing?

Once you have a place for your project’s info, let’s fill it up with essentials. This shouldn’t take more than a couple of minutes.

These are the 4 questions you should ask yourself before doing anything else. There are other questions you can ask yourself but this is how I’ve done it. You can do it in 1-2 sentences, no need to go balls deep into it:

  • What is this project about?
  • Who is the target audience?
  • When does this need to be finished?
  • Why am I doing this?

Writing down the answer to each of these, even if you might have the answers already in your head, will give you a solid mini-overview of the project that you can (and should) refer back to and base everything else on.

Research

If you wrote down the info in the previous step, you now have loads of information about your project. 

  • You know what kind of website you’re building
  • You know who is the targeted audience
  • You know does this project have any hard / soft deadlines 
  • You know what is the reason you’re doing this?

The next steps are a bit less clear and what you should or shouldn’t do next depends on the kind of project you’re doing (your own project / freelance project / web dev agency project).

Actionable research tasks

  • Gather more requirements
  • Gather more info about your target audience
    • What is the demographic?
    • What are their needs?
    • Where do they hang out online?
    • Building personas
  • Identify competitors / similar websites
  • Design your website
  • Breaking down the design into components
  • Estimating how long everything will take
  • Etc

Like I wrote in the beginning, this isn’t a one-size-fits-all process.

Maybe you’re building your own project and just want to get started coding. Maybe you’re working for a web dev agency and have some of these things figured out by your colleagues. Maybe you’re working on a freelance project and you can get some of this info from your client, etc.

How I’ve done Metadev research

For this blog I didn’t go too deep, the research part mostly just boiled down to:

  • Writing down some notes about the target audience
  • Looking for design reference websites / pages
  • Writing down a list of components that I need
  • Estimating how long each component should take

The point is, do what you think is necessary for your projects.

Design

Let’s talk about designing the project you’re about to work on.

You already have a design?

Great! Thank your designers or pat yourself on the back, having a finished design makes things much easier.

You can go through all of it, ask the designers any questions you might have and try to break everything down into components which can be reused. Estimate each of those if needed.

No existing design?

Let’s start this section with some context. I am not a designer and I generally hate spending time designing things. What I like is developing and changing things as I write code. So take what I’m about to say with a grain of salt.

.There’s 2 ways you can approach this.

  • Fire up Figma / Sketch and build out the design. But if you know how to do this, you can probably skip this guide’s section. If not and you’re about to do this, you probably need a different tutorial as I’m afraid I can’t help you much there.
  • Gather up (borrow) some reference websites / pages that fit into your vision and build as you go. I like to go through Dribble, find things I like and save them in a document (the one we talked about creating and the start of this tutorial) or just use Google.

I think you can guess which option I chose.

Figuring things out as you go

Designing as you code has some disadvantages tho, especially if you don’t have a keen eye design. 

  • Some things will be too small, some things will be too big depending on which page / component you’re working on
  • Colors might not match if you’re using exact color values from your reference websites, etc.

Generally you want everything you add to your work-in-progress project to fit in with what’s already there.

One book that helped me immensely here is Refactoring UI by Adam Wathan & Steve Schroger. IMO It’s a great book for developers who have to design things as part of their job / project but necessarily know how / want to.

If you want to get a feel of the content, Steve has a kind of tweet series of tips you should check out: https://twitter.com/i/moments/966634275276804096

The most important advice I applied (which helped me to keep things looking like they belong together) is using a spacing system as well as having a color scheme prepared ahead of time.

Using a spacing system

Basically you need an array of possible values for things such as padding, margins, borders, font-sizes, etc and you can (and should) use that array to pick values. This removes a lot of the guesswork from deciding how much should something be large.

Pick a value from the scale and see if it looks good. Too big? Pick the next smaller value? Still too big? Pick the next smaller one, etc.

The point of a spacing system is that all values are appropriately spaced apart so using 2 adjacent values makes a difference. You shouldn’t worry if something should be 40 or 42px. It’s too small of a difference to notice. If 40px is too small, your next values should be something like 52px. A visible difference. The book explains this far better than I can.

I’ve just used the spacing system listed in Refactoring UI but you can build your own. Here’s an example I found: https://www.carbondesignsystem.com/guidelines/spacing/

Color scheme

Defining a color scheme up front really helped to speed up the process of building this blog’s theme and remove much of the guesswork. The book comes with plenty of usable color schemes but you can easily find your own.

The most important thing IMO is to use more colors and more shades of them then you think you need (that includes grays).

Here’s a preview from Refactoring UI explaining this much better: https://refactoringui.com/previews/building-your-color-palette/

Component based development

By now you either have a design or you at least have some references / ideas on how you want things to look.

Now it’s time to break things down into components.

What are components?

It’s simple, components are pieces of your code that can (and should) be used anywhere on your site without relying on other parts of your site.

Gutenberg, the WordPress’s “new” editor, is all about components & blocks. The next part of this series is all about it and how it makes your job much easier, IF you set things up properly.

Examples of components

Card

For example, a card is a component. 

A card component example from Metadev's homepage.

You can change / set it’s title, image, tags and maybe size but regardless of that, you can reuse it anywhere on your site and it won’t break.

Button

A button is also a component.

A button component example from Metadev's contact page.
Component example – button

You can change the target url, button text and style. 

Full height hero section

A hero section is also a component.

An example of hero section component from Metadev's homepage.
Component example – hero section

This is a container component, you can change it’s background image and the inner content.

Start thinking in components

Everything you develop, each part should be built as a component. Independent of other components, being able to function on it’s own. Doing things this way will make reusing code trivial

Think of it as building the lego blocks first and then using those lego blocks to build your website.

Let’s break things down

If you have a design you can go through that. If you have reference links go through that (and use some imagination).

Either way your job here is to identify the components that are repeating on the website and write them down.

Write down the following for each one:

  • Name (header, card, image, etc)
  • The page it’s used on (or multiple if it’s reused on multiple pages)
  • Are there any variations (for example: normal card and featured big card)
  • Any notes (if needed) about this component
An illustrated screenshot of Metadev's contact page showing all components on the page.
Metadev’s contact page component examples

Once you have that, you should have a list of all lego blocks you need to assemble your website.

Now it’s time to estimate how long it will take to make.

Estimations for beginners

This topic would probably deserve a full article on it’s own but I’ll give you the easy to digest summarized version.

Correct estimates take experience

More experience = better estimates. The more you do it, the better you become at it. 

But even with experience you will be off most of the time.

Which brings us to the next point…

Estimations are not deadlines

Unfortunately clients / managers / your grandma will hold you to your estimates. Depending on how lucky you are with you current job / type of work they might be more or less understanding about it.

Your job is to explain to them that estimates are not deadlines. They’re just…estimates.

In an ideal world everyone would be understanding about it. But we do not live in an ideal world so it’s important to give yourself enough time to do it.

ROUGHLY 8 hours / component

If you’ve followed the previous section and have your design broken down into components, it’s relatively easy. From talking with my team lead and from past experiences, each component can be estimated as 8 hours of work.

Some will take more, some will take less but ON AVERAGE it should at least be in the correct ballpark.

DISCLAIMER: There’s no such thing as a one-size fits and your project may be off completely. Or maybe you haven’t broken down EVERYTHING into small enough components. Either way, it’s a good starting point.

Take your best guess and double it

Some 3-4 years ago I was working on a personal project. A friend of mine wanted to collaborate on a different project but I said I needed to finish my own project first. He asked me how long that would take. My initial thought was 3 months but I said 6 months, just to be on the safe side. In the end it took me 6 months and 5 days.

From then on if I’m estimating something I haven’t done before (or estimating something that should last more than 1 month), I double my initial thought. Most of the time it’s very close to the actual time it takes.

Wrapping it up

There you have it, if you’ve followed this guide you’ve now moved your project from the drawing board to a fleshed-out idea board and completed most (if not all) of the boring stuff. Now it’s time for the fun stuff: development!

In our next part of this series, I’m going to tell you all about the boilerplate I used for this blog and we’re going to re-create a page from this blog.