Designing Web Apps - Lessons from Ryan Singer(37signals.com)
37signals.com
Designing Web Apps - Lessons from Ryan Singer
http://37signals.com/svn/posts/2608-ryans-talk-at-future-of-web-apps-2010-london
3 comments
Personally I like the Wacom Tablet as an alternative to paper sketching. You get (almost) the immediacy of paper with the benefits of copy / paste, layers, undo, erase, etc
Personally I do high fidelity right away. I want to get as close to the final product as possible which includes the actual flow between the clicks.
The wireframe step is fine if you are dealing with client's and don't want to get into the aesthetic discussion before you have started working on it (believe me you wont). But more often than not it's a wast of time.
The wireframe step is fine if you are dealing with client's and don't want to get into the aesthetic discussion before you have started working on it (believe me you wont). But more often than not it's a wast of time.
I agree that you shouldn't waste time, but I think wireframing is an important and necessary step that shouldn't be avoided or underestimated.
When you go right into high fidelity prototyping you are focusing on many elements of the design simultaneously. You are focusing on the coding (html prototypes), visual design, information architecture (layout, navigation, etc) and you are doing it all at once.
Because of this you end up giving each department bits and pieces of attention, but not enough to see all the details and insights had you focused entirely on each department one-by-one.
I've shot right to hi-fi mockups before and I ended up not seeing a crucial insight in the information architecture side of the project. For me, doing low-fi wireframes and then moving to hi-fi mockups works much better, so I don't overlook certain details and insights.
When you go right into high fidelity prototyping you are focusing on many elements of the design simultaneously. You are focusing on the coding (html prototypes), visual design, information architecture (layout, navigation, etc) and you are doing it all at once.
Because of this you end up giving each department bits and pieces of attention, but not enough to see all the details and insights had you focused entirely on each department one-by-one.
I've shot right to hi-fi mockups before and I ended up not seeing a crucial insight in the information architecture side of the project. For me, doing low-fi wireframes and then moving to hi-fi mockups works much better, so I don't overlook certain details and insights.
Very nice presentation. I'll be passing this along to colleagues.
However--isn't this how most web apps are made? The domain-driven design of model->model interactions->front-end design has been around for a long time now hasn't it? I was hoping for something more to come up as I was watching the presentation.
The apps I do by myself pretty much follow what Ryan Singer outlined. It works very well, and once the code has been sanity checked to work I get started on a "high fidelity" version of the front-end and just play with Photoshop until the look is there. 20-25% of time spent is in a notebook full of class diagrams, database tables and lo-fi wireframes, rationalizing what models make sense for the app, how they will interact, what the user/admin will see, etc.
However--isn't this how most web apps are made? The domain-driven design of model->model interactions->front-end design has been around for a long time now hasn't it? I was hoping for something more to come up as I was watching the presentation.
The apps I do by myself pretty much follow what Ryan Singer outlined. It works very well, and once the code has been sanity checked to work I get started on a "high fidelity" version of the front-end and just play with Photoshop until the look is there. 20-25% of time spent is in a notebook full of class diagrams, database tables and lo-fi wireframes, rationalizing what models make sense for the app, how they will interact, what the user/admin will see, etc.
My most recent experience has me leaning towards spending the time to wireframe though. Ryan warns against this as a waste of time "building higher fidelity sketches" (than paper), but to me building a sketch in omnigraffle is much faster than on paper, and it can be easier to convey more complicated user interactions as you can copy and paste etc. Also, for more interactive components of a UI, showing interactions through a wireframe is much much faster than prototyping it in javascript, so it becomes worth it to quickly validate that the interactive UI makes sense (by sharing the wireframes with a few people) before diving into the code (the simple example he had wouldn't really warrant a more interactive UI, but imagine, say, designing mint.com's transaction browsing / management / tagging app). That process might last a few extra hours, but if it saves you from building a snazzy UI that doesn't make sense, time well spent.