As a Product Manager at WeddingWire, a key function of my job (and one of the things I love the most!) is creating wireframe prototypes. A wireframe can take many forms - a sketch on a whiteboard, or a basic set of boxes, text, and buttons on any number of client or web-based applications. At WeddingWire, we favor a wireframing program called Axure. The intent of a wireframe is to convey the functionality of a feature and the general layout of the elements on the screen or page. As a general rule, the wireframes are shared with internal stakeholders (like Sales and Marketing teams) to get collective understanding about the feature, demoed to Engineering to make sure the requirements are achievable, and after any necessary tweaks, handed off to the Design team to create high fidelity mockups. Along the way for most projects, wireframes are also used for usability testing, which is another great benefit of creating a good detailed prototype.
One of the most challenging projects I've led at WeddingWire was Project CloudOps, which was to expand the basic "My Leads" feature (for our vendors) into a more fully-featured CRM productivity suite. After many weeks of product discovery, meetings, and reviews, I had created my biggest and best-ever wireframe prototype…106 screens! That number is burned into my brain because I had numbered and re-numbered the screens countless times, and I felt like I had really achieved something when I crossed that 3-digit mark. The prototype was very detailed - almost every link or button went to a new page, showing how the product should work. Success! Right?
Fast-forward a year and a half. Our CRM productivity suite - the artist formerly known as CloudOps - had launched. My own team had grown by two people, the entire Product Development team had more than doubled, and we had launched many new features for both our consumers and vendors. These projects often involved wireframes, and over time I got better and more efficient at creating them using the features within Axure. My current major project is reminiscent of the CloudOps in some ways (mainly the size and scope), and thus the need for a detailed prototype. However a great prototype looks very different to me now, since I learned the art of dynamic panels! *cue the angels singing, and double rainbows sprouting from both of my monitors…what does it mean??*
A dynamic panel is a feature in Axure that allows you to create an area or a window within a prototype that changes based on some user action or variable - very much like an actual working website or app. Using interactions, you can make the panel visible or hidden, and set the current visible state. (Now I’m talking nerdy to you - PM style!)
Why create an entirely new page when you can add a dynamic element to the existing page? Long gone are the days of select all, copy, add new page, paste. My latest prototype is 6 - not 106 - pages, but one of those pages has over 50 dynamic panels, most with two or more states. It is always fun to make a product, big or small, come to life with a wireframe prototype, and undoubtedly better when you can use the features of a tool to work smarter instead of harder.