In this first article on building my personal website, I focus on the way I planned out the construction and roll out of the website, using the MVP philosophy.
I started thinking about redoing my personal website almost more than one year ago. I had just graduated from the CAWEB master’s programme at the University of Strasbourg and was lucky enough to immediately get job as a front-end developer at a small communications agency and on top of that landed some freelance work. During my studies I had a typical website that almost every student in web design/development has: some basic (half-empty) portfolio and CV website with which we’d hope to get the job of ours dreams. With the security of having a job, I put my website redesign on hold and unpublished my existing website that was rapidly becoming less and less reflective of my professional skills.
Not having the direct necessity for a personal website allowed me some time to reflect on what I want to achieve with my website. I knew that I wanted to move away from the classic CV like portfolio website, but I wasn’t sure about what shape it should take.
An inspiring article in the process of conceiving and planning the website has been “Post Mortem : Pourquoi j’ai arrêté mon agence Web“ where French entrepreneur and WordPress developer Maxime Bernard-Jacquet analyses the reasons why he stopped his healthy web agency after 10 years and shares the lessons learned.
He explains that projects rarely go as planned and end up taking up a lot more time than estimated. Their agency decided to triple the price of any quote that they did and tried to impose a lean project management workflow with their clients, finding the Minimum Viable Product and going about a web project in phases.
Even though I do not have have the same experiences as them, I do strongly identify with these problems. More often than not, a web project doesn’t go as planned, both as a freelancer as working for an agency. The saying “on time, on budget” rarely applies. Time estimates are usually too optimistic. The bigger the project and the less clients knows about the web, the higher the risk.
I’ve seen small finished websites being put on hold for over a year, just because the client couldn’t deliver on content. I’ve seen big projects being pushed back further and further because clients keep changing their minds and keep wanting to add stuff. On my first freelance projects, where I was in charge of the entirety of the project (design, development and project management), I severely underestimated my level of productivity, working in my free time after a 35 hour working week, on top of the time spent managing the project. What’s more, when working in the field of web development, one tends to overestimate just how web-savvy people actually are!
As a front-end developer, it can be very frustrating working really hard on a specific project that is not published for ages or having to keep redoing or changing something that already works without it ever seeing the light of day.
That’s why, for the redesign of my personal website, I decided to take a different approach: the MVP.
What is the Minimum Viable Product?
The minimum viable product is according to Eric Ries, one amongst the first to coin this term:
[..] that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
This definition includes the idea of testing, and data and feedback collection. The data collection and user feedback combined with a phased development makes it possible to iterate the product more quickly and efficiently until the ideal product is found or until the product is deemed unviable.
When trying to apply this principle to my personal portfolio website, one could argue that the product that I am trying to “sell” is myself, and therefore that I’d have to change myself to change my product. I don’t want to go too much into semantics here, but I will try to apply the concept of the MVP to the actual site, which is sort of an extension of myself and how I “sell” myself.
Obviously, as a front-end developer, I had loads of cool ideas in mind for my personal portfolio: crazy SVG animations, multilingualism, extensive case studies of my projects, optimized accessibility, etcetera, etcetera. But this time, I wanted to find my MVP, so I started to analyse what most essential and what the smallest amount of features needed were for the goal I was trying to achieve.
The goal here is to create and establish my online personal brand. So I started asking questions trying to deconstruct the final product I had in mind:
- Does the website need to be in three languages initially?
- Do I need lot’s of fancy sliders and animations?
- Is a full-fledged projects and about section?
- Do I really need to have that contact form before I can launch my website?
- Will an awesome design me from others in the long run?
The answer to these seemingly rhetorical questions seemed to be no. But they didn’t indicate what I should do instead.
Asking the right questions
Contrary to what the term product might suggest, it doesn’t mean to find a smaller, cheaper, crappier version of a product, but according to Ramli John in his article The Minimum Viable Product is NOT About Features it is all about doing the least amount of work to get the highest result, whilst creating value and good experience for your target audience.
— Ramli John (@RamliJohn) August 17, 2014
So it turns out, I wasn’t asking the right questions. Instead, I should have been asking:
- What’s the main goal I am trying to achieve?
- How will I make people come back?
- How can provide a complete experience without compromising the quality?
- How can I create a solid foundation to expand on, so as to not lose time rebuilding when I add features (scalability)?
- How can I have the most results with the least amount of efforts?
One and half year of full time front-end development has made me realize that in my career I would not want to only focus on that part of my skillset, but also put into practice my knowledge and skills in translation, localization and education. My website should be a reflection of those things. Not only who I am but also who I aspire to be.
I felt like writing about these different ‘domains’ on a blog-like format would be much more valuable and engaging than having some pages with static information or with the occasional project showcase. Of course such pages would eventually be useful in case of future job searches, but they are not a priority.
Last 2 years, I have done mainly front-end development work. A project page with description and link to the published website only goes so far in showing my skills as a front-end developer. To see the “actual” work I do, one would have to inspect source code, run tests like pagespeed insights or html validation. Writing about code and everything related to the profession would tell visitors of my site a lot more about me, because it shows how I think, work and communicate. It provides a complete experience to the visitor.
Using the MVP principles I managed to build and publish this blog in space of about a month. This has been crucial for me as I had little time to spend on it, as I work full-time and also have various other projects going. Now that the website is online, it is more motivating to keep improving it and to keep publishing content, because “it’s out there”.
I think this lean approach can be a very efficient way of managing small as well as bigger projects, especially when time and/or deadline are short. Finding your MVP forces you to ask the right questions, focusing on what the experience should be, and not what different pages, sections, plugins, or features there should be.
I am by no means an experienced project manager, but in every website project I do, whether it’s just the web design, front-end development or project management, or all 3, I always try to improve my workflow based on past experiences by trying new concepts or tools. I am not saying that you should always use the MVP method but thinking about your work methods in advance can both benefit you, your client and your target audience, because it can drastically improve your workflow and the quality of the product. I’d encourage anybody to do this with every project, big or small, especially when facing short deadlines.
If you have any experience applying this or other “unusual” strategies for small (personal) projects, I’d love to hear how that worked out for you. Let me know in the comments!