“Paper Prototyping”?!?! Are you INSANE? Anyone can prototype a user interface in dot net in lightning speed, and ya know what? When you’re done, the thing is WRITTEN IN DOT NET.
If you are building a RESTful web app then I think the best place to start is the URL.
That’s the URL schema for all the resources that go to make up your pages i.e. the individual elements that you want to point to, the elements you want to transclude onto your pages.
Starting from the URL helps map out how the information fits together - what information lives at each page etc.
Once you’ve got this sorted then start making it available as semantic mark-up and design with the css.
Obviously to start this you need to understand your domain - and to do that you need to watch how people currently work etc.
Jeff,
Although my University course in CS only requires command line interfaces, I’m into doing a UI for other projects.
Once I’ve got the data format sorted out ( usually XML), program artitecture (class inheritance, etc) and any other non-UI operations, I write the UI since I figure that the UI usually dictates what data manipulation needs to be done to present that data to the user. Not to mention the fact that the UI has tons of small stuff like tooltips that need to be thought about and done.
Great post!!
It’s great to see a lively discussion on this topic.
I think software design is very much an iterative process of discovery - gathering requirements and use cases, getting a feel for the domain objects, designing the user interface and working on the architecture. All this must come before writing code. I’m convinced of that.
How much effort goes into each area depends a lot on the project so there’s no strict rules for everything. Some projects need hundreds of pages of detailed specification while others can be scribbled on the back of a napkin. You have to use a bit of common sense.
But creating the architecture and back-end systems without regard for the user interface and how users actually want to work with the data (domain objects) can be disasterous.
Several years ago, one project I was involved in struggled really badly after months of careful data and architectural design and implementation. Users asked if they could edit the data in a particular way and were told that the highly optimised data structures didn’t allow for that! It took many more months of re-designs and rewrites to sort it out.
This could have been due to poor requirements gathering in the first place but, in the case of this highly interactive application, the full requirements were not really evident until we had the user interface in front of us and could explore the application a bit more from a user’s perspective. Up-front UI prototyping would have really helped.
My experience with paper prototypes is that they’re good at the early concept stage of a project but design sessions need a fair bit of planning. Unless you’re talking about making quick sketches in a note book, you need a reasonable amount of desk space (or a dedicated area away from your desk) and have some sort of prototyping “kit” ready.
Then you’ve got the hassle of how to keep a copy of the designs. You can’t keep them all up on the whiteboard or laid out on a table indefinitely and just committing them to memory is a really bad idea.
I just checked out Whiteboard Photo at http://www.polyvision.com (thanks for the link Eugene) and the example results look fantastic. But you’ve still got to get the images on to your computer, process them and print them before you can refer to them in your design sessions (unless the lighting was good and your camera has a large, clear display).
PowerPoint, Photoshop and generic drawing tools are used for UI and interaction design because they’re readily available and can just about cope with the job but they’re not really suited or intended for the task. It’s a bit like using a plastic spoon to dig a trench. You can do it but it’s a lot harder work than it ought to be.
Our GUI Design Studio tool at http://wwww.carettasoftware.com (thanks for the mention Jeremy) and the other related tools mentioned in these comments were created to address all of these issues. Many have been around for a few years but I think there’s still a general lack of awareness that they exist. Check them out though because they can really make a difference to your productivity and your ability to prototype.
I totally agree with you…
Hi there. I am working on a tool to solve just this problem. It’s not yet “officially released” yet, but I’m pretty close.
http://www.balsamiq.com/products/mockups
I’d love to hear your feedback!
Peldi
There is good article in Boxes and Arrows from December 2006 that analyzed the market for simulation/prototyping tools that is still worth reading (Visio Replacement? You Be the Judge - An Introduction to the Newest Simulation Tools by Scott McDowell).
You can find it at: http://www.boxesandarrows.com/view/visio_replaceme
Personally, I’m no expert on software development, but a self taught hobbyist Cocoa programmer. So on that basis take my opinion with a grain of salt.
With my limited coding experience, and primarily as a user, starting with the GUI design seems natural enough. Prototyping the UI helps me to refine what my app is and what it isn’t. It allows me to see what I need to do, and suggests the best way to do it, from a usability perspective.
Interface builder and the Cocoa NIB paradigm seems to fulfill many of the sugestions here. NIBs are decoupled from code - there is no way to paste handlers into button attributes, for example. It is quick and easy to prototype a GUI, and even to hook it up to a data model using bindings. Target-Action makes it easy to snap together working buttons. All this obviates the need for distinct UI protyping processes. Paper prototyping is useful, but the freedom to quickly try out many iterations of your UI in IB is liberating. And, once you fill in the blanks with your specialised code, you have a working UI, no extra work.
In my opinion, it seems wasteful to design the UI somewhere other than in your development environment. Surely this is something your IDE should be providing for you? Why do you need a separate app to mock up the UI?
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!
@Alex Clarke:
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.
Felix,
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.
3 Likes