Gotta have a plan (5 min read)
Wise words from a previous colleague of mine — “Prep is prep”. There is nothing that can replace it, you cannot fake it, and it is time well-spent. I just came back down from a week long high of getting paid to work on whatever-I-found-interesting, with the simple caveat of it has to benefit the company in some way. I chose to create a web app for learning and sharing of company knowledge on software engineering topics. Besides already being the coolest named project I have worked on at this point in life (dubbed Holocron), I ran the full gauntlet of web development — wire frames, user stories, inspiration from other sites and testing out each new feature (manually up to this point). I built upon some previous web apps I built while in the FirehoseProject online boot camp. Why reinvent the wheel if you don’t have to? It was nice to be able to work for a week straight in Ruby on Rails too.
If you want to check out the project:
Github repository (open source, if you want to contribute)
Here’s what I learned from the week:
Starting with the Why and a Purpose really helps you to get a sense for what the main features of the app will be. You don’t need to have 100% of the details set in stone, but need to know enough in order to create structure for your database, what your main controllers will be, and which views need to be in place. I started with the big picture as if I were explaining to my mother (read “non-technical person” here, sorry Mom). I filled in some tech thoughts after the big picture.
It was both easy and hard putting stuff to words and in an organized fashion. I realized there were a lot of details that I gloss over in my head normally, and making those thoughts tangible on a whiteboard was a great exercise that saved me time. I realized I had several key questions to which I would need answers or possible solutions pretty soon in order to make real progress beyond simply setting up the project. To avoid being overwhelmed, I concentrated upon what I could do at the moment and got the project setup.
I was able to rough out the index/home page for the site, so that was enough to get me rolling for a day. Once I got my actual view looking close to my wire frame above, I needed to figure out a few things. I asked around at work for some input, since my co-workers would be the potential users if it were implemented upon completion. That feedback once I had something to show, along with those few specific questions, was invaluable. I had enough to whiteboard out some more stuff.
I was able to refine my problem areas and it forced me to re-think the purpose behind what I was doing. In this case, when a user submitted a new topic, I wanted it to visually move from one spot on the site to another. By drawing this out and describing what actually needed to happen, I realized that my original plan was over-complicating things. If I wanted to go with a more elaborate or complex way of visually sorting things, I could do so in a later release as it was not necessary to do it in the initial release.
Overall, some key takeaways from this round of wire frames were that if you write out the user experience first, things go a lot smoother. Also, it dictates the architecture and not the other way around (at least when you are creating new stuff). There is a good reason behind having Web Designers and UX/UI positions on development teams. However, for small projects or in freelance work, it is one of the many hats that you should wear as it saves time in the long run.