Building a web design website using Agile Methodology

2020 is here and we have started with a bang! On the first writing of this article, it’s the 6th of February, 2020. We have already launched 5 websites this year, with two more brand new websites about to be launched in the near future (case studies coming soon).

Since you’re reading this article, you may (or may not!!!) have realised one of the websites we have launched is our own.

Building a web design website in 2020 using Agile

Building your own website is something that is really difficult as you are constantly looking to improve. It is hard to decide where the MVP (minimum viable product) is, the MVP in this case is really deciding the point at which the website it launch-able.

So…. How do you draw that line in the sand and decide what is needed, what can be added later and when to launch your website?

We used a waterfall agile methodology which involves cycles that fall into 4 categories: discovery, design, development and testing.

As an agency, we are lucky to have the staff to be able to fulfil the roles within a scrum so individuals who are specialists in their respective fields. This enables us to fill the following roles:

  • Product Owner
  • Scrum Master
  • Product Developers (front end dev, back end dev, designers, etc)

Stage 1: Discovery

We need to make sure that the people visiting our website are catered for. How do we achieve this? We have a game that involves a lot of post-it notes to work out why people were coming on our website. It goes something like this…

All of your scrum should be in the discovery if possible and should already have a firm understanding on the project goals, in this case it was to create a new website for us, Respondit.

We set a specific time limit (3 minutes) for us all to come up with as many ideas following these conditions:

As a…
I want…
So that…

As we are a web design business, answers looked like:

As a potential customer,
I want to see previous work/projects,
So that I can judge what the quality of work will look like.

My personal favourite to come out of this exercise:

As a User, I want to be visually pleased, So that my eyes don’t get bored

Once the 3 minutes are up, hopefully you have a variety of ideas that will almost definitely cover the majority of the users requirements for visiting your website. We certainly did!

We now grouped together our post-its and created a backlog of tasks which we put into an order of priority which we then put into the following order of priority:

  1. Wow design – let’s impress our visitors
  2. Contact – Give the clients a way to talk to us
  3. Content – Make sure we have the right services/information for clients
  4. Case studies – show our work
  5. Options / Examples – what else we can do
  6. Emotions – let’s make people feel a certain way

We now have identified what we would like to have on the website in an ideal world. To answer my previous question:

‘How do you draw that line in the sand and decide what is needed, what can be added later and when to launch your website?’

We decided in the planning meeting it’s somewhere between 5 and 6.

Stage 2: Design

Firstly, I’m going to point out that this design didn’t all happen at once. It was broken down into smaller elements, such as the hero, the very first viewport a visitor sees when they land on our website, such as the imagery and text that the customer sees. We break these tasks down again based on agile methodology, where once we decide what task is going into the sprint, we assign a value to the sprint based on the Fibonacci Sequence. The options available are 1, 2, 3, 5, 8, 13 and 21*.

*Any task that gets voted a 21 is deemed to much work for one sprint so must be broken down into smaller tasks.

Once a task has been agreed is going into the sprint, scum members must vote on the task value. The task value is a combination of how long it will take and the complexity of the task. I wish I could give a simple formula of how best to describe it, hell I’ll give it go, THIS IS NOT WILDLY ACCURATE so please don’t berate me for it:

T (time) * C (complexity) + F (thinking time, yes with an F because it makes me smile, #finkaboutit) / K (knowledge) – O (other things we have on)

OK, that’s not a great formula, but hopefully, you have get the idea. *note ignore the mathematics bit in the formula. The best way to get to know how accurate you are is to actually do it. Try it, after 5 or 6 times you’ll get surprisingly accurate.

An exploded view of the Figma design files for the desktop design

Tasks are discussed and then put onto a Kanban board – There are essentially 5 columns with tasks falling into the correct category: To Do, Ready, In Progress, Stuck and Done.

We use for our project management software, which we think is great. There’s plenty of other good options out there though, both premium and open-source.

Back to the design, we use Figma for our designs as it enables clients and stakeholders to comment on design files and we can make real-time changes whilst on a call/meeting/Skype.

Stage 3: Development

Development happens throughout the sprints. Think of it as creating parts of the jigsaw puzzle and then it all comes together neatly at the end. All the blue pieces fit together and form the sky, the yellow bits form the sun and the green bits form the forest. They all then come together to form our picture of a tree on a blue sky background on a sunny day. This is how I’d describe the development stage.

Let’s take our hero for example:

This is formed of multiple elements that we wanted the user to see when they landed on the website:

  • Logo
  • Navigation Menu
  • H1
  • Bold messaging
  • Call to action
  • Accreditation’s/logos

Each of these elements were created based on discovery, design, development and then testing. This enables them to be reused on other pages/sections of the website if required.

Stage 4: Testing

This is the moment where we ensure stages 1-3 actually do what they were designed to do. Initially, we test the site to make sure the basics are covered such as page load speeds, browser and device compatibility, readability, aesthetics, etc are all up to scratch.

We then progress onto testing on live audiences, which is exactly what we are doing right now. As you’re reading this article, you’re being measured as to how far you get along the article, and also what actions you take at the end.

  • Do you contact us?
  • Do you read another article?
  • Do you share the article?
  • How many people don’t make the end of the article?
  • Will you leave a comment at the end?

This all makes for excellent data to help us to constantly improve and the cycle begins again. You raise an issue or make a suggestion, it then creates a ticket. We then go through stages to improve the website.

Thank you for reading, please show your appreciate by sharing this post and/or by leaving a comment.

Let us know
what you think

Leave a Comment