Learnings From Designing, Developing, Testing, and Launching A Site In A Month
I recently designed, developed, tested, and launched a site in a month. And in this era of the internet, where we see people vlogging about doing just that in a day, that may not seem like a big accomplishment. But I learned a lot through the process that I think is worth taking note of and share with you all.
Backing up a bit, the site is called Lisstr and I’ve had the idea for it since October. Basically, I have a very structured, orderly way of thinking about things. My opinions on the things that I like are very much influenced by comparing it to something I already love . For example, when I play a new video game and I like it a lot, I immediately try to order it in my mental list of Favorite Games of All Time. And when the end of the year comes around, my friends and I love to discuss The Game of the Year and come up with ranked lists for a variety of categories. So the idea is simple: why continue doing that in my head or in a Google Doc when I could build a website that let’s me, and others, create, reorder, and share those lists?
So now that you know the idea, that brings me to my list (get it?) of learnings from this project. I’ll break those out into sections and easily digestible phrases if you don’t feel like reading much today.
Step One, Ideation: Wait for an idea you’re really passionate about
It’s easy to get motivated to start a site, at least for me, anyway. But what I’ve learned is that if it’s not an idea that I’m truly passionate about it’s just not going to happen. The process of actually making your idea a reality will die from a lack of real motivation.
Plan it out in your head for a while- don’t rush the initial idea.
I learned this lesson by necessity for Lisstr because I loved the idea (causing it to always be on my mind). But my development skills were not good enough to actually build it. So I ended up thinking a lot about it, mentally assembling a list of things I’d need to do or learn to get the project off the ground. That happened over a four month period. But when I finally found the answer the the most difficult part of the project (front-end, user-generated posts), I was ready to hit the ground running.
Make something you want to use.
If Lisstr wasn’t something I was truly excited to use myself, I never would have had the motivation to build it, and especially not build it quickly. But having a product idea that you know you’ll get use out of makes the process so much easier.
And a self-interest in your project also helps with creating appropriate expectations. This was a mistake I made with Lisstr all the time but it was easily resolved, mentally. I would think about Lisstr “getting big someday,” and obviously that’s likely not going to happen for any small-scale project. But if it’s something you want to use, that’s good enough, right? It doesn’t necessarily have to get big in order to be a success.
Step Two, Design: Design Fast, Figure Things Out Later
I have the luxury of being a designer / Art Director first, and a developer second. Therefore, the design phase of the project only took 2 days, while the development took the rest of the month. But I think that time breakdown worked really well for me. Especially when you are building the site yourself, there will inevitably be snags in the process where a part of the development process (like a plugin, a particular framework, etc) will end up going against how you designed it. I’ve found that it’s best to meet in the middle on those things rather than forcing the development to exactly match your design. I’ve learned it’s better to design loosely around a particular concept, and then let the development drive the specifics.
And secondly, you can’t be prepared for everything. Even if you think you’ve designed every page you’ll need on your site, there will be additions or things you forgot about and those things don’t always need a PSD / AI / Sketch comp. Just go with the look / feel of the pages you’ve already designed.
Step Three, Development: Risk, Research, And Relax
On Lisstr, I took a big risk starting the development of the site. Luckily, I knew a lot about Wordpress, since I’m the Art Director at a great Wordpress firm, but I knew nothing else about this project, development wise. I had never worked on a project that involved multiple users, user-generated content, and I had never personally written the code for custom fields. So I’ve learned to just jump in even when you don’t know everything.
Research when you get stuck
The key component in taking risks is knowing to research when you get stuck. No matter how creative or awesome your idea is, someone out there has done something similar. I found that every time I got stuck, I was able to find the answer somewhere online, even if it took a while to find.
The best thing you can do when you’re stuck is take a break. I took a full week off in the middle of developing Lisstr because I was majorly stuck on getting content to show up on this page, and because I felt that too much time of my time was going to the project. You should never get so invested in a project that the rest of your life gets neglected, especially your family.
Step Four, Testing: Get Help
No matter how many browsers, devices, virtual boxes, etc you have, you can never test a product alone. I desperately needed other people who were excited about Lisstr to help test it out. Things always make sense to you as the creator, but that doesn’t mean it actually makes sense.
Establish in advance what your MVP is
The one downside of having other people do Quality Assurance for you is that they’ll inevitably have other ideas or features they’d like to see added. It’s always good to write those down to circle back on later, but unless they’re a serious detriment to the usability of your product, it’s ok to turn those down for the time being. Know what your minimum value product (MVP) is and start by just building that.
Step Five, Launch: Release when you feel good about it
Like I said earlier, there is a trend online right now of making an impact with the self-imposed parameters on a project (typically the allotment of time you give yourself to build it), rather than the project itself. But what’s more impactful? It’s easy to hang your hat on “I built a mostly-working site in one night, without sleeping!” But I think it’s much better to be able to say “I build solid, functioning site in a week (or a month) and I’m very happy with it.”
Don’t Expect Perfection
While you shouldn’t release an incomplete product you also can’t expect a perfect one either. I launched Lisstr knowing that there were areas I’d like to improve in the future, but I didn’t let my own nit-pickiness hold the site back.
In the end, a great product is much more important than its parameters and a project’s successes should be able to overshadow its shortcomings.
TLDR: Find a challenging idea you’re passionate about, design it quick, build it on your own timeframe, and launch when you think it’s ready.