Throughout the years of coding, you begin picking up habits and adjusting workflows for maximum efficiency. I can recall one of the earliest things for me in this regard was the addition of Emmet (previously Zen Coding) into my editors and after getting accustomed to it seeing the huge boosts in speed while generating HTML and CSS. These little things in your workflow are generally based off personal experience, and everyone has their own methods of doing things. Shortly after the acquisition I had to elaborate one of my methods with my new team members, which I’ve decided to go ahead and share here as well.
It’s time to build out a new component, a new page, or a whole new app for your site, what do you do? First, you need to get your requirements down. What the new “thing” needs to do, what’s it for, etc. When you have some basic parameters down, generally the first thing that comes out of that are wireframes. Wireframes help create that initial skeleton of “where things go” on the page. At Wombat, wireframes are where the iterations go down; various versions are mocked up and tweaks are made along with other departments’ input till a more finalized version of the wireframe is decided upon. With the final nod of approval and any tweaks that to need to be snuck in, a ticket is created to begin the coding process. The code (and things like prototypes) are seen as something more along the end of the process, nearing finalization.
As the “new guy” to the Wombat Development family I unsurprisingly had a difference in my process which initially seemed to have caused some confusion, and understandably so. The important steps along the process to point out above are that it went “requirements -> wireframes -> revisions -> code” and what I was/am accustomed to at this point was “requirements -> wireframe -> code -> revisions”. As you can imagine, when someone starts throwing code (which is generally perceived as “final phase”) out earlier than expected it can seem like you’re jumping a huge part of the established process. Amusingly, the difference wasn’t as jarring as it initially seemed.
Following a more “design in the browser” philosophy, I’ve become used to writing up my markup and styles as soon as I can to help visualize what it is I’m going to end up coding anyway. With enough practice, it’s possible that you may end up coding as fast as it’d take you to illustrate wireframes/comps. At that point, you basically either go ahead and draw up a static version of what you’re going to code and then code it, or dive in and code it up right from the get-go. I like the latter.
Pros & Cons
In the end, the confusion was just a simple difference in what “mockup” meant to us. I just had to explain that while I code up my prototypes, I’m not trying to skip the whole “revision and reviewing” process, the only difference is that my “mockups” aren’t pictures but code. They are still meant to be totally unfinal, mutable, and easy to adjust ideas that need to follow the same sort of refinement as their static brethren. Now, the prototyping sort of method isn’t something that is probably useful for every instance. Some cons include:
- Versions - It’s slightly more difficult to code different “versions” of the same page in a working prototype since generally a “link” goes to one place.
- Speed - Getting to a speed that makes prototyping worth it over comps might take a while. You definitely shouldn’t expect a junior developer to code up a mockup page as fast as a more experienced designer whipping up wireframes.
- Impression - While the team gets accustomed to it, it can be difficult to initially remember that the prototype is meant to be just as “incomplete” as a wireframe. The illusion that things are clickable, coded, and working can sometimes give the impression “this is how it will be” and that is certainly not the case. A prototype should be able to be completely nuked or redesigned if necessary.
Now of course, if prototyping early were so inefficient developers wouldn’t bother with it, but there are definitely pros which I personally believe outweigh any of the (generally overcomeable) issues:
- Speed - This time, in the good way. When you can code up prototypes at a decent speed it helps to immediately understand some of the workload coming your way. How long certain areas take, what areas might take longer, and depending on what you’re prototyping and how, you might be able to use a good portion of your code and refine it for production!
- Life - Sometimes static images just don’t work well to give the full picture of how something should work. I can do a 4 image wireframe showing how clicking a search box opens a dialog, spins a cool loading indicator, then generates these results with X hover effect or I can code up a mock version you can click and see animate right in front of you. As long as you don’t fall into the above “impression” con, this can be a powerful advantage.
- Tweaks - By the nature of code, it’s possible that tweaks might be more efficient in code than when illustrated. Moving around layers, deleting them, and readjusting across a set of wireframes can’t match the efficiency of cut/pasting a line in a different spot, slapping a class, and seeing your change apply across all the templates it’s in automatically.
In the end, I think it’s really up to the developer to find the way he is most efficient at helping the company get their ideas to become a reality but it’s always important to remember that your team needs to know what you are doing and why so that collaboration can take place rather than confusion.