Refresh Austin ringleader, speaker, fire starter, UX manager, community catalyst, Web technologist, barbecue acolyte & information junkie
The idea that there are three simple levers that define a feature or a product is passive-aggressive professional absurdity. There are myriad levers the team can adjust, but to understand them you need to understand the people who are actually building the software.
Michael Lopp a.k.a. Rands from Bits, Features, and Truth
If you haven’t picked up his book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager yet, you should.
Dangerbird Prototype Screenshot
Normally a post describing a site launch doesn’t grab my attention, as they cover the same ground (base level descriptions of the design process, technologies used, how great the client is etc.). But the write-up the launch of Dangerbird Records by Athletics, a design firm out of Brooklyn includes a discussion of their home-grown prototyping methods, which is not something you see every day.
I’m constantly refining the process I follow to create wire frames and prototypes. I’m close to a good solution, but it is continually out of reach. Much like the team at Athletics, I’ve investigated Axure RP and similar products, finding them to be much too large for my needs. They’re great for complex, enterprise apps, but they aren’t built for Web apps and sites (they are trying to shift, but I think that will merely lead to larger, more complex apps). I have tinkered with straight up comps and even light weight Web sites, but neither quite meets the need. For the moment I have settled on building wire frames in Visio, followed up by conversations that arise to discuss small details and interactions. No matter how many notes and call outs I add to a wire frame, questions arise.
Wireframes are not ideal for describing the richness and possibilities that are inherent in a Web application.
Prototypes on the other hand are great for conveying placement and interactions without implying design, but they can be time consuming initially as components need to be built and actions and results must be wired together. The Athletics team appear to have found a good method – using Flash plus a little bit of ActionScript to produce fully interactive and informative prototypes. It still requires some of that up-front work, but it is balanced by the ability to quickly revise the prototypes, and more importantly reduces misunderstandings and questions.
If I can carve out some time I will explore this method to see if it’s feasible for my work, but at a minimum it has placed Flash into the toolbox as a possibility for future prototyping projects.
The Task Analysis Grid is an interesting alternative to the standard requirements doc. I think I may give it a whirl at my next opportunity. As noted on the site, it’s a “single document allows anyone looking at it to see the entire scope of a project, figure out what’s in this release (1) as well as what we’re planning for future releases (2, 3, and 4). It’s an extremely effective artifact for getting everyone on the same page.” The numbers (1 – 4) map to priority levels assigned to each requirement.
From Lost Garden comes Software Development’s Evolution towards Product Design a great explanation of how software development should flow, with an excellent, tongue-in-cheek illustration of the entire process.
With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim “And that is what I do!”.
Write That Down is a great blog, documenting Adam’s move from the role of developer of Web-based applications into product management. His posts are very informative and reassure me that my choice to shift towards product management will prove fruitful and challenging.