Rapid Web-App Prototyping
One of the complications of developing a web-app is getting the development team and the design team on the same page as far as user flow and experience. Often, without visual mock-ups teams will spend their time fighting features that could be simply explained through a simple prototype. We find that traditional prototyping can take too many hours, as the design team will have their own work-flow process.
As BLUETUX develops out new web-apps, we needed to streamline our prototyping process to cut down on over-head and allow the development team and design team to provide input early on. Over the last few months, we’ve taken our design and development process and whittled it down to a strong core in order to meet that end.
High Level Goals
- Increased Communication between Development & Design teams – By involving the development team in the prototyping and UX phase of prototyping often will get the design team clued in on the technical limitations of the technology (platform, languages, etc) being used to develop your app. Often, the dev team is able to provide usability ideas that the design team wouldn’t think of as they are not always as current on technology or programming techniques.
- Picking the right tools – This is very important to our process. Over the last few years, we have moved away from Photoshop and towards using Adobe Fireworks. There are many complaints against the software, yet it allows us to use vector formats to layout our apps without having to worry about raster format graphics that are more difficult to manipulate.
- Link design features to real-world code – Often, the dev team gets handed a prototype with a whole bunch of pretty features. Pretty features that have to be made… it can be a nightmare. By creating a library of “features” that can be linked to real-world code demos is an invaluable way your team can communicate a feature list that both teams benefit from.
The Process
Step One: Hug it Out
Right now, our team is small. We’ve been able to pick and choose who we work with, so we’ve got a team that we like working with. It should be important to you as you begin to form your team that everyone wants to be there, is like-minded in goals, and is eager to contribute their skills to the project.
If you work remotely from each other, get them all together for regular project meetings, and a project kick-off that gets everyone some personal face-to-face time.
Step Two: 80-20!
This should be your mantra. The concept of spending more time planning your project, and developing the concept using all of your team before sending them off to build it has been well documented (Pioneered as the Pareto Principle) and when applied to managing a project we’ve seen that it helps immensely.
Step Three : Choose Your Weapon
It is important that your team be comfortable with the tools that they are experienced at using. That being said, if you haven’t discovered vector-based tools yet, you need to consider taking a look at Fireworks (http://www.adobe.com/products/fireworks/).
Fireworks is a well designed tool, that allows you to fairly quickly begin prototyping websites and UI for apps with a minimal learning curve.
Step Four : Create your Library
We wanted a wide array of “stock” features and actions that we could drag and drop between “layers” of our source document. We went out and found different javascript effects, table layouts, pop-ups, and other features you might want in your app and then themed them to meet 1 generally consistant look.
Each of these resources was arranged inside it’s own multi-layered folder and grouped by what it does. “Action” or “Button” etc etc.
Additionally, each resource was linked to it’s real-world equivalent whenever possible. That way, a designer or developer could quickly navigate to the code that controlled that design element at a later time.
Step Five : Create A Unified Grid
The two previous steps were written based on the assumption that you have a fairly competent development team, and they’ve done much planning for the application before reaching these phases.
This phase is semi-specific to the design team and is really here to just offer insight to our process.
We have several apps that we’re developing at BLUETUX, and many of them share concepts / features. We decided that we’d spend a bit of time coming up with a universal grid / user flow that would carry over between the applications.
Several of us got together, and based on our experience and our plan for the applications, we developed a hierarchal grid that focused on the application, usability and process flow.
The result was a simple layered .PNG template that included our resource items, and contained a basic navigational structure.
We didn’t focus on making it “pretty”, the “shell” can come later. Don’t get me wrong, I actually like the way it is starting to look, but that was not our focus.
Step Six : Putting It Together
Once we’d developed the grid, our design team was able to take the notes from planning, the grid, and our resource folder and create each unique page of the application in a matter of 2 days.
Popups, notifications, flow, and much of the actual functionality for the application was mapped out in visual flow that our development team is able to understand and provide useful feedback from.
Results Roundup
In the end, much of this process may or may not work for your team. I encourage you to take any ideas here and use them to benefit yourself in your web project.
However, for us, we are seeing great results from this style of planning / design in our applications. Not only are we able to rapidly product multiple applications at the same time, but we’re finding that our teams are able to develop better products at a much quicker turn around than in the past.
I apologize for any spelling / grammatical problems in this article. I’m working on becoming a better communicator, and will be updating more often in the next few months & years as we continue to streamline our processes.
If you’re interested in working with BLUETUX, or would like to talk to me more about our process, please email me at sam [at] bluetux [dot] com.
It’s true. I have alot of experience with moving between dev / design teams and it’s something I plan on discussing / writing about more in the future.
It’s great because right now, I’m spending more time playing that roll directly as we work on our apps, and I’m actually recording it and developing our process.
Great post Sam. I’ll have to bring some of these ideas up at the next meeting at my day job as I can see us only getting better by coming up with a better process (at the very least it would save me some headaches).
“Often, the dev team gets handed a prototype with a whole bunch of pretty features. Pretty features that have to be made… it can be a nightmare. ”
Been in that exact situation before, it’s even worse when the pretty features are called one thing, but they really mean something else. Case in point, someone wanted an accordion menu. I know what an accordion menu does as they all pretty much act the same way. Turns out they wanted it to look like an accordion menu, but not be one (even though I was constantly told accordion menu). A Photoshop file and a description doesn’t exactly show functionality, having a live example is always helpful.