In a landscape of moving targets, and the wish to hit the bullseyes in tandem, there is an increasing need to work closer together in order to get things done. In a traditional software “house” or application development team, there are designers and there are developers (or software engineers).
Normally the designers take their list of features/application targets and work away coming up with information flows, user interfaces, user experiences, etc. and test them. They build lower-fidelity prototypes. They use applications like Sketch to build up flows and static representations of the application. They are the painters, applying vision and concepts to virtual canvases – slowly building up an experience. This can be done outside the purview of those in a development department (engineers, developers, coders, whatever you’d like to call them). Or it can be done in tandem with the development department so that there are some reality checks for how things progress. A feature might be easy to pixelate but could have certain ramifications to actually produce and have work robustly.
Each change might need to cascade through artboards. You’ll need to update those and distribute them. You could end up with a very large cycle of repetition that is prone to user error in making all the changes needed… everywhere.
This can be done outside the purview of those in a development department (engineers, developers, coders, whatever you’d like to call them). Or it can be done in tandem with the development department so that there are some reality checks for how things progress. A feature might be easy to pixelate but could have certain ramifications to actually produce and have work robustly.
I’ve seen in some circumstances where developers wait for an approved application design, flow, and experience. Whatever “pseudocode” the designers may have written be tossed aside for fresh & production code. Just because developers know more than designers… right?
Make Mashed Potatoes.
With the passing of every new year, designers strive to express themselves. They’d like to watch their visions come to life. They push new experiences and interactions. The code more and more. Over time, their code generally improves to the point where it can be pretty good and can actually have a chance to live on in compiled applications. Imagine that.
Version controlled prototypes (SVN, Git, etc.) allow for more play without the worry of forever losing something, especially for designers. Developers know all about such things and welcome branching and merging.
The once tall standing walls of categorical thinking that prevented hopping can now become small fences that can be stepped over – if one just knocks on the door first to be polite.
The gap between designers and developers is gradually closing. Code-driven prototypes could be the future of digital product design. Things turn into a collaborative, team-driven exercise. You get to the scrum milestones with greater success, the developers can help designers with a penchant for producing code-based bits of code to do what they envision, the designers can give the developers a greater sense of design sensibilities, and you end up with something production-ready in a shorter timeframe.
You don’t have two teams of people, each with their unique skills, working separately – or worse, gating each other over and over. You have a group of people advancing together (or nearly so).
So. A prototype now becomes a master prototype. All members use version control. It contains all of the features and functionality that the shipping version is expected to have. New features can be worked out on a branch and merged back in if it’s deemed alright to do so. The animations and experiences are part of the prototype – and not lost in a low-fidelity prototype or merely talked about without being implemented until late in the game.
You might worry about this. It assumes that most of your designers know how to code for the target platform. Or that they really even want to. Some might want to only live in Illustrator, Sketch, Invision, etcetera. So it obviously can’t work in all cases. It is a path that can serve a team and company well though if you have all the parts in place.
The master prototype can be taken at the end and optimized, code-reviewed the last time, and given a version 1.0 blessing by whoever is deemed appropriate to do so. Isn’t that better than producing static or canned experiences that take time and need to be recreated in code later on? Isn’t it better not to worry about how a developer might interpret some design description of how an animation or series of animations is supposed to look? You’ve built the actual thing together.
I have actually worked on small teams producing rich prototypes – and the development time is optimized. I am versed well enough to be able to jump into repositories, look around, and get what I need. I can make smart decisions, request features (visible or backend) in order to make my job of creating an experience easier. I get requests to display certain bits of data from backend developers. We work together, communicate concerns, announce issues early on, fix bugs as we go, and make informed group decisions.
At the end of the prototyping cycle, we have something robust and quite nearly release-ready. The code will be good. If things need to be re-worked for release, we’ll have ideas on how to best set that up since we authored the prototype code already. We’ve done nearly all of the work, we haven’t cut corners to merely get something out the door. We haven’t faked much if anything, if possible. We want to live with the prototype, to feel it work, and to gauge its ability to delight users.
I’m just throwing out this idea. Cutting down the amount of time to release great applications is paramount as more and more companies try to get their stuff out there. They aren’t just competing with each other, they are competing with the AppStore update cycles – if you aren’t fairly active in producing updates, you aren’t perceived as taking the application process as seriously as those who produce updates on a fairly regular cadence.
While working on a prototype, I document each day’s activity as an overview. I do this using DokuWiki running on my laptop’s server. I have it customized with extensions and my own code to provide just the right experience and ease of updating. For myself and anyone else who would like to update and document certain aspects and decisions. It’s easy to catalog files (PDF, ZIP, etc.) on the wiki as well. Every night I have a CRON job run a script which backs up any changes to an external drive as well so that we don’t miss anything given a catastrophic drive error. It’s an awesome system. It takes some dedication to maintain, but it’s really worth it. And I can go back into any project and re-live it at any time. For me this was a no-brainer.