During the past few years I've had the opportunity to work on a variety of coding projects, both professional and personal. And in that time, I've been able to create systems and workflows in order to help facilitate the process of development.

Truth be told, every single project is typically different and has its own set of workflows. But there are similarities in each one that I tend to follow much of the time. For example, they all pretty much involve creating mockups, wireframes, designing databases and inevitably selecting a tech stack in order to build the entire thing.

From idea to design, there's quite a bit that goes into actually taking a project from conception to production, starting with the planning phase.

So today I will walk you through the typical initial process that I personally take on almost every project, before any actual coding starts.

Basic design sketch

While there are a ton of design tools that you can use to build the initial design and sketch of your projects, I tend to put those off until later in the process, mainly because using those tools can be time consuming and often times just make things complicated. Especially when your idea isn't quite as clear yet.

You might end up getting stuck in selecting a color palette and a font way before you are ready to do so. More on that later though.

My initial sketches are kept very simple, with basic lines, shapes and arrows pointing to more detailed explanations when required.

I write down any information that might be considered useful during the development phase. I don't typically design the database portion at this point or jot down any actual code. But if there are important pieces of data that I will more than likely forget later on, I will keep track of it.

Here is a very basic and crude look at a sketch that I drew out when I designed my laptop review website.

It isn't fancy by any means and it is designed to be changed. While the initial idea always sounds great (in your head), there is a good chance that it probably has alot of missing pieces. Pieces that you will figure out during the actual development process.

The basic sketch above let's me know that I'm going to probably need a product feed page and a detailed page for each product. It also gives me a pretty basic ideas as to the properties that each laptop has, such as a title, image and a spec list.

There will probably be many more sketches made during the course of developing this project.

The main reason why this is a back of the napkin sketch is because the actual details will indeed be added with a design tool. I personally use Figma for most of my mockups and brand sheets these days, which I'll dive into next.

Design Mockups

You are free to use any of the most popular design tools currently on the market, such as Adobe Illustrator, Canva or in my case Figma. Really, whatever tool you know best is the best option typically when designing a project.

I mainly use Figma because of its wide assortment of tools that pretty much give you the freedom to design anything. It even has the added benefit of being able to export the given CSS right back ready to implement. And for the most part, it is free to use.

This step, takes considerably longer than the previous one, for obvious reasons. For one, you typically are starting off with a blank canvas and the first few elements will be void of any type of design, shape or form. That can make it daunting to work with, at least initially.

And that's the biggest benefit of utilizing a design tool like Figma, because you can change elements as much as you need to very quickly. You can also clone elements and create layers as well, giving you the ability to create complex looking designs without having to write a single line of CSS.

Sticking with my original sketches from above, here is one of the design mockups that I made for my laptop review website.

Notice that I didn't fill in every single area with the exact content that would appear on the page. I didn't include the navigation panel for example. At least, not in this particular design. The navigation panel would typically have its own Figma design page.

My main purpose here is to layout all of the elements listed above in a more concise and user friendly manner.

I also take color into consideration during this step as well, keeping the palette to around 2 to 3 colors in total. This is also where Figma really helps out, as you can group together multiple elements and change all of their styles all at once.

While I'm not expecting the final version of the design to match this mockup, I do want it to come close.

Brand kit

Let's talk about color and style once again.

While not required, sometimes having a dedicated set of guidelines regarding style to reference later  can make the actual design process much simpler. That's where branding kits come into play.

So what's a brand kit, you may ask? If you're new to design you might not have heard the term before. And if you're mainly a programmer (non design), then you probably ignore creating brand kits in general.

Brand kits are essentially design sheets that specify the fonts that will be used in a project, as well as the color schemas and even components that will be used. Here is a quick example of a set of button layouts for a sample project.

The whole idea here being that you want to maintain a consistent look and feel throughout the entirety of a web project. And the brand kit provides that consistency.

The most beneficial aspect of having a brand kit however is in the fact that you can send this kit to somebody else working on the same project. That way multiple people can keep the same look and feel without having to directly communicate with each other about it.

Again, not required and if you are working on a small enough project it probably won't offer much benefit overall.

But if you have a considerable amount of pages, an or fonts, and multiple people then a brand kit is almost always required.

Picking a tech stack

Not all stacks are created equal, at least, not these days. Before I start to actually code or design anything, I typically need to make up my mind on which technology to choose for this particular project.

I never recommend selecting a stack that you don't know at all. You'll end up spending more time trying to learn how to perform basic operations (like how to read query parameters), then actually working on your business logic.

The caveat here being that if you are trying to learn a brand new stack, then just know that the process will of course take much longer.

For me personally, I have a few options since I've worked on a variety of languages and frameworks during my career already. My go to stack is still based around the .NET framework. It's the one framework that I have the most experience with and I have a substantial amount of .NET code written that I can reuse over and over again.

But I also have substantial experience working in a Node.js environment, particularly using the React framework. And that looks something like the following:

PostgreSQL
Express
React
Node.js

So depending on the scope of the project, or if I'm using a pre-built static site generator (like Gatsby), then I might opt for this particular approach.

This is why I find it more beneficial to first sketch out and design your project before choosing a stack. Certain frameworks are better designed to handle particular situations, such as building single-page applications or even more advanced concepts like reflection.

Whether you are building an OOP application versus a functional one is also something that you should take into consideration during this step.

Once you have all of those data points figured out, you are pretty much ready to start the actual development process.

Road to MVP

Everything else is the work. Which is why I don't have too much to say about it. You pretty much start with a blank canvas and then you paint over and over until it starts to resemble what you had in mind.

This process could take weeks, or it could take months, depending on the complexity of the idea.

The main goal here though is to get something up and running that is fully functional without all of the bells and the whistles. Those can be added on later once the hard part is completed and deployed.

And that's your MVP. Your minimum viable product. You can think of it like a rough draft that still needs several revisions.

For me personally, the standard timeline for any of my projects has been well over 3 months from design to launch. And even after they launch, there is plenty of work left to do.

And that's a look at my initial design process. Truth be told, it takes time and often isn't the funnest part of being a developer. But, it has been hugely beneficial in helping me get a product to launch. And I hope that it does the same for you on your projects.