9 ways we (nearly) perfected our development process
I used to think process was an ugly word. Who wants to be neck deep in charts and documentation, wasting time when we could be actually doing the design or dev work? And it’s that kind of thinking that got us screwed over on jobs our first couple of years in business.
Well this year, I think we finally got it right. Sure, there’s always room for improvement, but there are several ways in which we nailed down, perhaps our most efficient, effective process of building websites and applications, and one that actually enhances the fun for us, while also ensuring clients get what they want in the end.
Take a look at this process chart I made a few months ago:
This process shows a more refined way that we go about a project that fits into one of two camps; Either a website built in ExpressionEngine or an application built within the CodeIgniter framework.
Putting the visuals first: UX first
We’ve recently adopted a UX-first approach to most projects. The bigger and more complex the application, the more important this approach is.
This might sound counter-intuitive. Surely visuals aren’t the most important part of an application? Actually, they are. This is because a) users of an application subconsciously pay more attention to how an interface looks/works than anything else and b) because working out the views first helps shape how the app works itself.
I could write a 30 page function spec that is articulate and detailed, but still doesn’t illustrate to a client what their app will work like in the end. People have increasingly less time for reading, and the same is true for clients. But show them through a sketch, a wireframe or even a fully rendered design what their product will look like, and now we can intuitively discuss, change and plan based on that.
In fact, nowadays we will not actually provide a fixed quote on any project that fits within our definition of ‘application’. This is because the variables are too great and it only leads to revised quotes, scope issues and changes down the road. It’s too early to know how an app will cost when our client doesn’t even know exactly how it’s going to work or what features they need. So we always recommend a UX project first, and then at the end of it we can provide a quote, and if it’s too pricey our client can take the design and run with it themselves, either in-house or with another agency.
Another thing we started doing more is separating visuals from functionality and flow by creating wireframes and flow-charts first and then creating mood-boards to establish visual direction.
A lot has been written about moodboards, so I won’t belabour the point, but in a nutshell: Moodboards are sort of like collages that help clients and designers focus purely on aesthetic design elements such as type, colour, texture, imagery without providing any specifics on how an end-product will work. It’s actually the polar-opposite of a wireframe, which is devoid of any aesthetics but concerned only with where elements sit on a page.
Original moodboard
Final design it's based on
Moodboards can also be executed fairly quickly so it’s possible to show two or three directions without the cost and inherent problems with fully designing multiple options.
Let them click, or how Invision solved my pain
Let me get this out of the way first: Invision is an awesome product.
I’ve long desired a good UX tool, but I found issues with every wireframing tool on the market. They often have clunky interfaces and make designing a chore. As a designer, I’d rather work in the desktop tools I’m comfortable in, namely Adobe Fireworks.
Invision let’s you do that, work in whatever wireframe program you want to, and provides an insanely efficient way to upload your screenshots, create hotspots and link the screenshots together.
What this means in the end is I can design a series of page views, whether low-fidelity wireframes or high-fidelity interfaces, and make them interactive so clients can click around in a prototype as they would if it were a fully coded application. Clients love getting to preview the app before it’s built, and doing this allows us to work out so many design issues and resolve feature enhancement ideas long before we’re ever in the guts of development.
Even afterwards, our developers love having the Invision prototype open along with function specs while coding. It gives them something to refer to and removes the guesswork.
Writing clear, in-depth functional specifications
This is something we’ve been doing for a while, but it’s an essential part of the process. A function spec is a fancy way of saying ‘A word document that clearly articulates in plain language how the application should work’.
The spec is essentially a script that gets constructed after the designs are approved by the client. They are important because certain aspects of an application cannot be communicated with a design, for example, events that trigger email notifications.
If the spec is well organized, detailed and clearly written, then it keeps the client informed about what is considered in-scope, and it leaves little room for developers to misinterpret how something is supposed to work, avoiding costly coding mistakes.
I love Google Docs for writing specs, because I can share it with the client and the developers, people can comment and version it, and it naturally evolves throughout development as aspects evolve and become more clear.
This whole design first and spec out later could be considered a very back-asswords approach and will no doubt cause disagreements between us and those who favor a more traditional approach, but I can say without a doubt that this has been one of the single-most important ways we’ve improved the quality and profitability of our projects and left clients feeling more satisfied with their end-product.
Dividing front-end and back-end
This seems like it should be obvious, but many shops will have a developer who is responsible for every piece of an application build.
I think it’s incredibly important for each project to have a dedicated front-end developer and a dedicated back-end developer who each work on their own parts and then work closely with each other to knit their code together.
Think of it this way; In a restaurant, you wouldn’t expect a chef to serve his own food to customers. It would break his concentration and lead to slow-downs in the kitchen and inefficiencies.
Similarly, the back-end developer should be focused on data moving back and forth within the application. Data is submitted through forms in the view, which then gets passed to controller code, then models which submit it to the database, and data flows back through the system ending up back to the user in the view.
This may be oversimplifying it, and in no way is meant to represent the incredible skill of developers who write elegant code within this MVC structure, but at the end of the day it’s all about data in, data out.
So if the developer doing this also has to worry about how the data is styled when it comes out in the view, it requires a completely different mindset and will only lead to a lower-quality application. Instead, let a front-end developer who is trained in design focus on writing the HTML, CSS and Javascript necessary to implement the visual design of the application.
I’ve seen the two working together in harmony and it’s a beautiful thing to witness. It also keeps the development of the app moving along in a more timely manner.
Breaking the build into phases
I’m almost embarrassed to say now that we never used to break large projects into phases. Instead once everything was set to begin building we just plowed through it and tested when complete.
That is a mistaken approach because testing only at the end of a project is the best way to ensure more bugs will be present and they’ll take longer to solve.
So this is why we now will take a large project and break it up into several phases, usually around 10. We start with the most basic stuff, such as account creation, login, forgot password etc. as Phase 1. And once it’s complete we test it thoroughly, working out any bugs as needed before moving on to the next phase.
Generally the more complex parts of development end up being around the beginning to middle of the dev cycle, with the later phases being equally important, but less complex components such as data export, reports, auto-recurring billing etc.
Basecamp is great for managing these phases. To-Do Lists are a great way to isolate each phase into general pieces of functionality that need to be coded during this phase, and then tying it to milestones in the calendar and assigning responsible team-members.
Proper Architecture
Architecting an application is important. One could simply dive into coding once the design and spec are complete, but it’s far better for the developer to step back and plan out the build from a technical standpoint since it gives her a working guide as she builds. It also assists any other developers who may be working on the app simultaneously or taking it over down the road.
This is not meant to be a technical article so I won’t go into detail, but essentially an architecture doc will contain names and descriptions of classes and methods and a map of relational database tables.
Version-control and code repository
It’s taken a long time for us to find the ideal solution for code repository, version-control and back-up system, but I think we’ve finally found the holy trinity of products. Beanstalk, Cornerstone and Subversion.
Beanstalk is a hosted web-product that acts as a centralized code repository. We set up a project, move our code into it, and then with Cornerstone and Subversion, each team member can download the latest version of an application from Beanstalk, write code locally on their own Macs without worrying about overwriting each others code.
Also, Beanstalk allows us to easily deploy the code to a production server for external user testing or demoing an application to a client.
Adding this suite of software to our development process has added an unprecedented level of professionalism and efficiency to our work-flow.
Proper bug testing software
We used to just use Basecamp to-do’s for bug testing. To-do’s are great for listing client feedback, design changes, or broad features that need to be added, but they really suck for bug-tracking. Bugs can be too numerous for a system like Basecamp to-do’s to be effective, so we needed a more robust solution for our application development process.
Then we found Sifter, a great web-product that also seamlessly integrates into Beanstalk. Sifter allows us to set up a project, track bugs that have various weight in priority, write detailed descriptions and upload screenshots.
A team member can change a bug from ‘open’ to ‘resolved’ meaning the tester should test it again, and once confirmed the bug is fixed, can change it to ‘closed’.
The bugs can be tied to milestones, such as phases, and I love how a progress bar shows how close we are to having the milestone reached.
Remote user-testing
The final piece of the puzzle in our process-nirvana is end-to-end user testing. User testing is important because once we have caught all of the obvious bugs in our software, the only way to check if it really is working well is to have real people test it and inform us of any issues.
At one time, we would have had to round up people off the street and sit them down in our office with usability testing software running. That’s all well and good, but it also is time-consuming. So recently I came across the appropriately named User Testing.com
User Testing allows us to set up a test by defining the goals and tasks we want people to accomplish. Then we can select a demographic of users who are made up of crowdsourced testers. Afterwards, we can view videos and written answers from users, having all their feedback gathered in one place. We can then edit, annotate, make clips and download videos so that the team (or clients) can review feedback and make changes accordingly.
In the interest of full disclosure, we haven’t actually tried this out yet as most of our large applications aren’t yet at the right stage for this kind of testing, but after reading the reviews of usertesting.com I’m really excited to try it out and I have a feeling it will become a valuable part of our process.
Any web designers/developers out there, please comment below and share what the most important elements of your process are.
Yesterday I attended 