What's the plan, man?

June 29, 2010 7:24 AM

How do web apps get planned? What is the "blueprint" for a web app? The storyboard, the map, the plan, the.... well, you get it.

I'm a designer, a UI designer in this case, and I work for a small company that makes proprietary web apps. The approach currently used is a bit haphazard -- lots of talk, maybe rudimentary schematics of pages... and a lot of revision. I think every party involved has a different picture of the final product. Somewhat like constructing a building with some sketches on napkins as a blueprint.

I'm wondering if there are some "standard" approaches to this process that might work better. Some form of flowcharting, mapping, schematics etc. to provide a blueprint for the app before everyone starts working on their bit.

Anyone?

posted by ecorrocio to computers & internet (10 answers total)

The projects I've worked on had two parts of blueprinting: front-end and back-end. The front-end side was fun, beginning with napkin scribbles until a basic idea had been nailed down. Then we recreated it digitally. We've done mockups in Photoshop, Visio, and even PowerPoint (surprisingly effective for this task). We've also created more natural-looking mockups in HTML/JS/CSS that had no real functionality behind them but gave a good feel for what the various screens would look like. These mockups usually got built out with actual code, so they served a good purpose.

Back-end blueprints were done mostly on whiteboard and focused on database structure. When we had a lot of tables to keep track of, we moved to one of those big markerpads with many pages. The large form was helpful in group meetings. And once we'd figured out exactly how it was going to be built, we covered our offices in the pages. It looked like John Nash's place in A Beautiful Mind but it was very handy to be able to glance over for quick reference while coding.
posted by The Winsome Parker Lewis at 7:38 AM on June 29, 2010

Broad strokes: Typically these are called business requirements. In a lot of environments, someone (a product manager,project manager, or BA, depending on the org and the specific responsibilties) talks to stakeholders about their goals and gathers their ideas for how to meet those goals, then works with implementers to understand what the best way for the app to meet those goals is. There are typically multiple iterations of increasing specificity that begin to move into functional requirements and tech design documents.

In my experience the key is to have an authoritative document with an empowered owner -- that document will change and evolve constantly, but if everyone buys into the idea that that document describes What Will Be, you don't lose so many cycles and you can avoid a lot of misunderstandings.

PM me if you want more info from my own experience. I'm sure it doesn't echo everyone elses...
posted by chesty_a_arthur at 7:38 AM on June 29, 2010 [1 favorite]

The process you're describing is basically what a business systems analyst does. Depending on how formal you want the process to be, it goes something like: gather user requirements [review, revise, sign-off], build use cases [review, revise, sign-off], create process flows [review, revise, sign-off], prototype (if necessary), development, QA, regression testing, etc. A lot of time content and design is happening concurrently to the process above.

Now having said all that, I rarely actually see that process followed in the right order with all the steps. There are deadlines, business needs versus development needs etc. I'm currently working on a project that was being developed by a third party vendor before the flows were done which as it sounds like you know, is frustrating. I am surprised that requirements and flows aren't really being built out. At least some consensus needs to be reached about what the final product should be before development starts.
posted by Kimberly at 7:43 AM on June 29, 2010

Oh, chiming back in to echo chesty's comments about business requirements. I assumed you already had those in place. Before you start building anything you need to formalize what your app will do (and by implication, what it won't do — or scope creep will eat you alive). I've found that it also helps, from a biz-dev point of view, to determine what your market is, who your target audience is, and exactly what needs you'll be fulfilling, to see if your idea's really as viable as you think it might be. Coming up with a pricing model's important too. And it doesn't hurt to write a one-sentence mission statement to keep everybody on the same page philosophically during development.
posted by The Winsome Parker Lewis at 7:47 AM on June 29, 2010

You might benefit from reading up on the MVC design pattern, too. http://en.wikipedia.org/wiki/Model–view–controller
posted by koudelka at 8:03 AM on June 29, 2010

Information Architecture for the World Wide Web (aka The Polar Bear Book) and The Elements of User Experience are pretty much the standard texts on this subject.
posted by stet at 8:06 AM on June 29, 2010 [1 favorite]

I came here to recommend The Elements of User Experience, as well, it establishes a conceptual framework for the kind of project you are talking about.
posted by oulipian at 8:37 AM on June 29, 2010

The roughed out way we do it: discuss the goals > create some mishmash of business requirements (aka what the people selling want) and user personas or descriptions (aka what the people actually using it will want) > application map > rough wireframes > detailed wires. Each step gets more detailed so things aren't revised after too much time has been put in. You'll still have revisions, but they shouldn't be out of control.
posted by dame at 10:04 AM on June 29, 2010

[Formerly] professional BA here.

I recommend the book Mastering the Requirements Process.

I took a workshop given by the author, James Robertson, that was awesome. They have a companion book called Complete Systems Analysis as well. It really helps if ALL the stakeholders can be schooled in the basics of business requirements, but at the very least the project manager and BA should be.

UML is also a common tool used to gather requirements, and Visio supports its use (though it's clunky to use).

Feel free to memail me if you have further questions.
posted by wwartorff at 11:34 AM on June 29, 2010

Great stuff from all! Thank you for your time.
posted by ecorrocio at 7:35 AM on June 30, 2010