Um, web development excepted, of course. Which is what this post is about, obvioulsy. My question stands for desktop development though.
Wait, are you moving back in time, to old Delphi days of dumbly slamming random code in Button1Clicks? Nooooooo!
What if your IDE is a limiting factor in UI design? What if there is 10x better, nicer and more efficient way to implement UI and integrate it into the code without using IDE UI design tools?
As for the guy who said Firefox Options UI was an afterthought I completely agree and I find it horrible.
I agree with you to an extent, but being a very visual person, designing “wire-frame” click through pages has helped the a few teams I have worked on tremendously. It helped us define the architectural requirements and structure in a much more concise manner when documenting it out after “rough” UI sketches.
UI first can be truly powerful and assists very well in making sure that everyone from the stakeholders to the trench developers are on the same page. I believe in presenting data requirements in a number of formats. Some people can see clearly, all the possible scenarios that could arise from a simple case diagram, but many times once is an actual UI we begin to realize that there is more there that is required. Additionally, some people can sit down and write solid and precise specification while not missing a thing. Still further, some people can interpret the written word in many different perspectives.
My two cents are to build project requirements and specification in many different media’s or styles. Include the case diagrams, include the “faux screenie’s”, and include the obligatory written word document so that it is easy for anyone to wrap their head around.
What is it? People learn by four different mechanisms? Visual, Textual, Oral, and sound? Some people excel in one are or another and presenting data in a multitude of delivery mechanisms can help cover all the bases.
Now don’t get me wrong… I am not suggesting volumes of redundant documentation here, just enough to force you to look at the problem from many angles. Nor should this be any type of replacement for documentation either…
Fun angle Jeff. For some it is a way of life, for others it may seem illogical.
Is paper protoyping really future-proof? Could it handle the ‘Minority Report’ interface? However, I do get the point that if the application will have an interface, the interface should be designed first.
Personally I usually throw a form together in Delphi/VS first and then see where that takes me. Once I think I’ve got something that looks vaguely usable then all I have to do is double-click on a form element to make it do something.
How come the prototype Excel 2007 chart dialog is better than what they actually implemented?
About decoupling UI and backend: Al Cooper writes the same book every couple of years, in which he argues that the skillset of interaction design and programming are almost entirely different, and that UI design should be the responsibility of specialist interaction designers, not programmers. Certainly I’ve seen enough “geekware” that is plenty powerful, but hides its features behind formidibly complex UI or obscure features. The firefox browser might be an example: the tools-options dialogue is very much an afterthought; to /really/ change the configuration, you type in about:config in the address window, and then navigate through an endless sequence of cryptically named configuration options (WTF does dwhelper.adult do?) until you get to the one you think you want.
Thanks for the information shared here. that was an interesting and informative. I had a good experience by participating in the Adobe Summit in 2009 which features the latest developments on the Adobe Flash Platform that is of utmost importance to both developers, as well as designers… I learnt lot of new technologies in Adobe. And I am planning to attend 2010 edition as well. I found the information about the conference from adobesummit.com
I just bought a huge whiteboard. Problem solved: Eco-friendly Whiteboard Prototyping.
Even after 7 years later, this post is relevant.
I will start my new project today with design-first development in-mind.
Doesn’t tackling the model first offer more flexibility, since UIs change and vary far more than business rules?
Certainly it’s important to determine what information the user would like to view and manipulate before beginning work on the model, but is it really so important that we determine how, precisely, that information is presented?
“UI first” seems like a perfectly good approach during a feature’s design phase, but when beginning its implementation phase, “model first” makes more sense to me.