"The first is that most programmers, particularly those who've been trained through University-level computer science courses, learned how to program by first writing code that was intended to be run via the command line. As a consequence, we learned how to implement efficient algorithms for common computer science problems, but we never learned how to design a good UI."

I have an issue with this. Software Engineering != Computer Science.

I'm a computer scientist, not a software engineer. Recently I've started planning what I'd call my first software engineering project.

Sure, I've written tens (or hundreds) of thousands of lines of code in the last couple years. But I have very limited experience with writing a program someone else will actually use, so I've been hung up. I had no clue if it would be more practical to design the GUI first, or hammer out the details of the back end.

Question answered. Thanks Jeff.

I totally agree with this. If you don't do this, you end up spending weeks if not months with feature creep and lots of "oh shit" we didn't think of how this would affect UI moments. 37signals has a similar philosophy: http://gettingreal.37signals.com/ch09_Interface_First.php

I made the switch and bought my team licenses to "GUI Design Studio", and wow.. I HIGHLY recommend it. It certainly isn't perfect, I see many usability issues that the developer could improve on it. But even with it's blemishs, it is worlds above the way I used to prototype interfaces. I recommend anyone interested in prototyping check it out.

UI-First Software Development is essentially Test-Driven Development for the front-end -- and I don't mean "did Firefox catch any JavaScript errors?" UI Testing. I can see combining these two making a natural and powerful union.

I have a problem with this approach. Humans have a limited attention spans, and developers are no exception. Focus too much on the interface, and you'll end up neglecting the architecture or, worse, the data format. Yeah, yeah, I know, the users will never see *those*. But they *will* see a bloated, buggy application that locks them in with its almost-unconvertible data formats. (Any resemblance to real-world applications is not coincidental. :-P)

IMO, the initial design step should be more abstract: "what problem do our users need to solve?" Note the singular "problem", btw - a piece of software should solve one problem and do it well. A well designed architecture can support wildly different interfaces. A well designed data format can be implemented by different architectures. But an arbitrary interface - designed with no concern for what's underneath - will lock the developers in now, and the users later.

Felix,

I think you are missing an important point.. UI often should DRIVE architecture AND data structures.

For example.. I create a UI with multiple windows that all look at the same conceptual objects. If I do that and I know they are not modal, then I immediately know I need to need some sort of observer structure to propegate data object changes. Where as if my needs on the UI are different, I may be able to skimp a little in the way I persist the data layer.

So what happens, working from UI down I am not caught in a suprise moment where a fundimental architecture decision has hamstrung my UI. While working down from the UI, you still have to make the same fundimental architeture decisions that you would make if you were working up purely from the architecture, but you can make them in light of "will they satisfy my current UI needs".

In a perfect world we would make all our backends be able to accept anything and any kind of interface, but we all know that is an impossability. What you can do is ensure that you absolutely support your current UI needs while still eyeing maximum flexability of your lower layers.

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.

I use paper prototyping and I love it. When I'm serious about a project it makes me take a step back from rushing into code to look at the bigger picture. Most importantly, it allows me to mentally walk through various flows of major features for an application. This ultimately informs my decision on how to structure an app and usually leads to new feature ideas which in turn fuels my excitement for the project.

Just because you think about the end users mental model first does not mean that you need to structure the underlying data the exact same way. Structure domain level data the way it needs/wants to be. Often times the two map together nicely and for the places where they don't there is usually some code foo that can remedy the situation with little real performance hit.

Yep, if you're building software for users, and you're not starting with the interface, it's very hard to take a user-centered design approach, which is really what you want to do if you're expecting users to find your software enjoyable and choose to download/buy/use it.

I disagree to an extent that prototyping the UI on paper is universally better than using a UI designer software. Starting with paper gives you a lot of freedom to get the broad strokes right, but quickly switching to a tool like glade can help getting the interface into the hands of a sample user. It also lets the developer start "feeling" the app. Of course, you don't want to get hung up by limitations of the tool or let the tool stifle your creativity with respect to solving your app's unique problems.

Here's a post I wrote about doing low-fi prototypes in Visio: http://blogs.msdn.com/jackiebo/archive/2007/02/28/how-to-create-ui-prototypes-with-visio.aspx

Yet another reason why having a skilled Interaction Designer on your team, whether full-time or contracted, is essential for success. It's not about making the interface look pretty, it's about having the interface make sense, right?

>That's the logical next step up from paper prototyping.

PowerPoint or other digitally-enabled prototyping is a step DOWN from paper prototyping, not up.

With a PowerPoint prototype, the polished look sends a blatant cue to the person evaluating the system: we have already designed this, we care, and if you tell us we screwed up, you will be hurting our feelings and making us do extra work.

With paper prototypes, you provide the opposite cues: this system is totally open to changes, it's easy to change, nothing is set in stone, we aren't married to the design, we welcome your input, you are part of the team, changing this is no big deal, it's going to change anyway.

You can state all these things verbally, but the reality of a paper prototype states them at a much more visceral level and really removes the inhibitions, both conscious and unconscious.

Paper, post-it notes, sharpies, highlighters, pencils, erasers, index cards... these are way better tools than software tools.

Oh, and by the way, moving a post-it note from one side of a "screen" to another is WAY faster than doing it in PowerPoint. You can move two at once, float them around, try things out, undo instantly, set things aside, hand over control... The user/test subject can do it themselves without the social friction of having to say "um, would it be OK if I used your mouse to edit your document?" You could give them control of your computer, but still the difference in what they do is like night and day.

The link for GUI Patterns (http://www.welie.com/patterns/gui/index.html) in your "previous post: http://www.codinghorror.com/blog/archives/000499.html" is broken.

I was happy to read that I wasn't the only one who liked paper prototyping. But when you mentioned using PowerPoint as a prototyping tool I almost fell off my chair. Maybe I'm a bit skeptical because I've seen PowerPoint completely overused. I've also seen a prototype produced in PowerPoint that looked like it was done by someone in the marketing department with zero technical knowledge. Maybe in the right hands it's a good tool...

I feel that in my case it was the other way around, when I started developing applications, I had really good "natural" skills in how to design interfaces that were easy to use, I liked trying different layouts and icons, etc. But then until I finally grasped the concepts behind object oriented methodologies, three tier design and all that, my code was a real mess. Since I had the interface almost ready, then in order to quickly have something working, I used to put code and logic in the most unusual events (click of the buttons, change of a textbox, index changed of a combo, etc..) they were really a nightmare to maintain afterwards, thanks to courses, internet and good books you start understanding the benefits of all the "best practices" ... I felt bad about the code done in the past, but it feels good to evolve, if you are developing applications the same way you did 2 years ago, then you are just accumulating years of experience, but not really improving your career.

Great links to the powerpoint prototyping articles.

Here's a very cute little tool designed to do just this.

http://www.mockupscreens.com/

Sometimes you do not need a swiss army knife, but just a knife. This is it.

Designing nice usable interfaces for applications is my favorite part of writing a program (not that i dislike the algorithm and code behind it part), i guess that makes me fairly unusual.

I think paper-prototyping is something most people should be able to cope with - after all, kids play with paper and crayons for hours (or they did when i was one)

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.

The great thing about paper prototyping for me - and we used it extensively on our current product - is that you don't invest the same amount of time in creating any part of the UI and so don't develop an obstructive "ownership" in the design.

Use any tool, including PowerPoint, and you immediately start building up a reluctance to dismiss the idea because it looks clean and closer to the actual UI. Keep to paper and draw quickly, and if it's not working, shred it and move on. It only took you a minute to draw, so there's no feeling that hours of work have to be tossed.

That way the investment is in getting the design right and no one is reluctant to drop an idea because they spent ages creating it.

That, BTW, is one of the good things VB encourages.

I mean, basically in VB you draw the form (UI) first, then write event handlers (code) that is behind it.

@Felix:
"IMO, the initial design step should be more abstract: "what problem do our users need to solve?""
*Exactly.* And this divides into two questions:
"What will our users do?" => GUI
"What do our users want back?" => GUI

The architecture and data format have absolutely no bearing on this question. They're part of the next questions: "How do *I* solve this problem?", "What problems might *I* encounter in 5 years?", "Will this interface with *my* competitors?"

*How* you get there is entirely immaterial to the user, except that it must be fast enough not to annoy them. Note the word "enough". Also, it doesn't matter if it's come up with a result, unless it DISPLAYS it within this time => GUI.

It doesn't matter if you have the cleanest data format in the world, if the user can't enter their data easily, it'll fail. By contrast, even if the data takes up twice as much space on the drive, or requires a convertor app to interface with a competitor, it'll have a chance to succeed. At which point you can make improvements to the way the data's stored, now you've got *real world* data.

@Felix:
"But an arbitrary interface - designed with no concern for what's underneath - will lock the developers in now, and the users later."

That's the point. Before you design your data format, you should know what'll be going in, and what'll be coming back. => GUI.
Otherwise, where are you getting your data format from?

(Any resemblance to real-world applications is not coincidental. :-P)
Some of these apps are the most successful in the WORLD, though. I'd include both iTunes and Outlook in this. Ever tried to get your music back off an iPod? Tiresome.

another nice tool for mockup website designs is

http://dub.washington.edu/denim/

it's designed to be used with a graphic tablet or similar.
looks like you did the design on paper, and i guess with such a tablet it would be equaly fast to do so.

I talked about this theme in the past. You can read it here: http://blog.codiceplastico.com/?p=87

Totally agree with what Natch said at 10:18 about paper giving the team carte blanche to rip it all up and start over.

Paper prototyping lets you act without thinking about how you're going to act. Instead of drawing lines with a mouse, you just draw some lines. I like to use a fat sharpie on index cards. It forces you to under-design the problem. Digital tools tend to get you mired in the details too early.

You know what else really helps with design, writing, or any creative endeavor? Going outside for a nice walk by yourself and thinking about the problem at hand. You've gotta get away from your tools sometimes, especially tools as distracting as computers.

So this unreadable colour scheme wasn't an April Fools after all!!! TTFN.

Another good tip when scribbling out UI on a whiteboard or paper is to use the fattest tipped markers you have. Most developers go for the fine points because you can be much neater and fit more information into a space but an actual page or form usually has no where near the resolution that a fine tipped marker does.

I couldn't agree more with Tom

In simple terms for any end user application as the term indicates end user requirements / use cases are a first. For me that's the ground to start with. To validate/discuss/freeze the requirements naturally the next step is having a fully detailed and fine tuned UI specification. So mixing it with code designing / architecture makes no sense at all.

Inface application architecture/ code design must be geared up to support all kind of UI requirements and must be flexible enough to acoomodate all changes/modifications in my view.

So requirements & UI first -> and everything else follows isn't it the golden age old rule ??

Though one particular aspect that many designers do not capitalize on that this article has emphasized on is the use of power point. For a recruitment process application using PowerPoint I was able to freeze almost 300 UI specs within 2 / 3 weeks. Its one of the MS products I use extensively for application development. I used dreamweaver/MS word/ Excel / EA and many others for UI protos.

But nothing beats PPT in this segment. Unless a team brain storming is on I don't use even whiteboard or paper. Though it can be a lot of fun its unnecessary to waste all of that.

LOL, I have been designing with Keynot for ages :) It's the best way to "show" what you want, but let the "specifics" for later. I gotta admit that I sometimes DRAW and scan what I want. My fellow programmers love me for that. :)

My only complaint is with the implicit assumption that command-line tools don't have a UI that must be carefully considered as part of the development process -- if it's a tool someone else will use, anyway. Anyone with significant Unix experience should know this.

I disagree, our company has always done GUI first or GUI driven application development (was originally a VB and access shop, now a c# and sql server shop and looking to move into cross platform, distributed, internet aware, db portable, dynamic language based stuff) and we are suffering now. We don't have any good object model, our business rules and db access stuff are tightly coupled with the GUI.

It would have been better to do the object model first, then think about the db layer, then the business logic etc, before even thinking about whether this is going to be presented to the user via a web page, a windows form, a cli, a java applet or a facebook application, or even whether it wont be used by a human at all but rather a web service sitting on a remote server somewhere.

Ideally the actual program functionality would be designed well enough (gui independent) that a lightweight UI module of any type can easily be slapped on as needed.

GUI first might work for small, fully upfront designed, completely specified, user oriented tools, but in these modern times of rapidly changing requirements its just not agile enough.

Forget it. A programmer should never ever design an UI. If you know what you want split the jobs to designers and programmers. we have programmers which never ever doing other things like communication or db. Highly specialiced, but far more efficient than anyone who likes to do everything by himself.

What I'm doing quite often is to use Flash as tool for early interactive prototypes. It has many advantages and you can easily integrate all the pictures of your paper prototype.

I’ve had tremendous luck with a mix of static HTML, paper prototyping, and digital cameras. HTML lets you design a few screens really hastily without worrying about properly aligning or nesting elements (because the browser does it for you). Print the screens out and use scissors and pens to rework the UI and develop workflows. This draws lots of players into the UI design process who might otherwise find themselves excluded, including salespeople, account reps, the customer, and users themselves. When you reach a point of agreement on a particular interface, take a photo of it — this might be all the documentation you need to move forward.

Ryan:
"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."

Yes, I think that's the best way to do it. I, for example, am not a visual person, and that probably influences my opinion. A holistic (is that the right word?) approach to specification/design has the best chances to make everyone involved understand the project.

I have had a lot of success with Axure RP (http://www.axure.com/). It's cheap, and it is really easy to build quite functional prototype screens. Best of all though, is the amount of element annotation you can do. Its straightforward to put together some very quick and dirty prototypes that can be generated to interactive HTML screens (or Windows Help files). But it is also simple to add useful information to screen elements and generate pretty thorough specification documents from the prototype.

The key things for me, for any prototyping tool, are that it needs to be extremely quick and easy to use, and the end result can *never* be mistaken for a real application. It has to look rough - otherwise, you find the customer gets unreasonable expectations for how much work is left. After all - to them, the UI is the application, and if the UI looks finished, then the dirty stuff behind it can't take all that much longer surely?

"UI-First Software Development" aka "Front Ahead Design (FAD)" - don't miss this recent 1. April joke on the topic (controversy included ;-)
http://thedailywtf.com/Articles/FrontAhead-Design.aspx

We use Visio and Omnigraffle extensively in work, before a line of code has been written. We go as far as creating real life clickable prototypes, user testing them, optimising for user behaviour etc.

Personally I don't ask for a single line of code until every aspect of the UI has been created, tested and improved. I find programmers like this approach once they understand it. They know that there is a great piece of software sitting there and seem to enjoy the fact that their job is to bring it into reality.

The only downside of paper prototyping, and wireframing is that in an AJAX world it's hard to communicate the difference between in-page interactions (JS stuff) and actual page changes.

This isn't a new idea - the RAD fad of the eighties/nineties was about this too: build forms quickly, have them accepted, add the logic later on.

The trouble is, this way you often don't get a consistent architecture but code copy-pasted into Button triggers on forms, because the client assumes that it's 80% done and you have not time for planning...

For web applications we use an HTML creator such as Microsoft Expression. The key to fight the temptation to convert it into a working application is that all the pages are just static HTML. We use either links or a standard submit button to demonstrate workflow. I warn my clients before they view the Wireframes that they are ugly and only demonstrate workflow and elements, not presentation.

For Windows applications I rely on Visio, linking the pages to demonstrate workflow. To share with clients I’ll export the Visio pages to a PNG files, which I embed in HTML pages and host on a website.

I'm taking my High School's comp sci course(basic command line java), and the teacher emphasises user friendliness even at this level. She takes our programs home, and if her 7 year old can't run it then we get a 0.

I thought this was a joke at first because 2 days ago at TDWTF there's a tongue-in-cheek post about FAD - Front Ahead Design. ha ha.
http://thedailywtf.com/Articles/FrontAhead-Design.aspx

I'm working off a 100+ page UI design in a pdf, done by a UI company, but that's it. They supposedly did all this work talking to heaps of users and they can sure talk the talk. They created great looking screens, but there's a total lack of flow, they didn't bother giving us any use cases, and from a 'web design' company they expect a lot from html. Sure we're all fancy web 2.0 jazzy widgets, proper CSS. - but you could park the death star in the gaping holes.

It's easy to draw pictures. It's easy to conceptualise what should happen. It's much harder to turn it into a system.

But that's what I do. I make shit work. As always, the devil's in the details.

"Focus too much on the interface, and you'll end up neglecting the architecture or, worse, the data format."
"The trouble is, this way you often don't get a consistent architecture but code copy-pasted into Button triggers on forms, because the client assumes that it's 80% done and you have not time for planning..."
"There's a total lack of flow"

So far, the anti-response seems to be "Well if you do this, you'll end up being really careless and rushing with the rest." I'm not convinced that this attitude is confined to that "if". If you are committed to being careless and sloppy in all but one area, that area might as well be the GUI.
It's like me saying "If you work on a good back-end, you'll inevitably end up with a truly shocking GUI". I'm not saying that. I'm saying that you'll get a lot more information about the data required at the back-end when designing the GUI, than you will about the GUI when designing the back-end.

I've always found paper prototypes to be very helpful. Not least because users feel that suggested changes are 'cost free', as distinct from coded prototypes, where it is perceived as more difficult and costly to tweak a change. The task here is usually to offer a starting point to validate a design, with the intention of iterating to a more suitable (better) design. The methods should be appropriate for the sort of information required. Inter-panel relationships and parsing what goes on which panel can be explored with panel relationship wireframes, on paper, in Powerpoint or, my favourite, Inkscape SVG with a tiny bit of Javascript to allow a page switching presentation in Firefox. Likewise, similar technologies can be used to look at the detailed layout of what's on a panel. However, where I want to explore the subtleties of say autocompletion in a field - which may make a big difference to a panel's usability, paper is less appropriate. I have even prototyped in HTML/Javascript, for an HTML/Javascript Web based admin console but I knew that no developer would use my code to drive the real thing (since it's an enterprise product, using JSPs to generate the interfaces on the fly).

I completely agree about Usability's fundamental relationship to product architecture and on my projects, this is usually where the whole team (architects, developers, test, information developers, UCD, marketing and other stakeholders) enumerate and then detail the use cases. We're very careful to ensure we stay implementation agnostic until we've got the use cases and it's only at the prototype stage that the design & implementation is realised at all.

My view is that prototyping can only be as good as the foundation on which it rests. That starts with Customer requirements, formalised into use cases, which are embodied in use case scenarios, which inform the design, which are a starting point for prototyping, which allow the customers whose requirements we're trying to meet see if we understood what they wanted (or even if they understood what they wanted). And the hip bone's connected to the...

Jeff,

Agree 100%. But decoupling the UI from the back end is as important.

UI-first always runs the risk that all the app's functionality will get built into UI controls that the user completely changes his mind on three days later.

UI drives functionality design, but functionality implementation must be decoupled from UI.

Another advantage of paper prototyping (one I frequently employed in my previous employment) is that it forces the peer-reviewers to criticize the significant features of the UI. If I were to provide a more accurate UI mock-up, I would invariably receive criticism about the alignment, font-choice, and other trivial issues. During development, a lot of those trivialities can be changed up until delivery, whereas reworking a complex layout or adding and removing significant UI features often costs a lot more late in the game.

It is more than 'paper prototypes' -- you actually need to know how the system should work, from the users' point of view.

Ben Cchneiderman (http://www.cs.umd.edu/~ben/) took this a step further in 1987: design the documentation first:

Shneiderman, B. (1987), Designing the User Interface: Strategies for Effective Human-Computer Interaction. Reading, Mass.: Addison-Wesley.

I referenced the technique in my thesis, and proposed it for aircraft autoflight systems!

http://dspace.mit.edu/bitstream/1721.1/37310/1/ICAT-2000-3.pdf

Interesting, why for web design would you use power point over a photoshop comp? Designers use photoshop for design compositions all the time...Photoshop is another good alternative for laying out UI designs.

On my last design project, I used a combination of two Visio tools with a lot of success:
Prototyping Template:
http://www.guuui.com/issues/02_03_02.php

This article and downloadable template/stencil allows me to mock-up simple web user interfaces that look "sketchy" (so users won't think the app is almost done), but is legible (better than my handwriting).

Swipr:
http://www.swipr.com/

Allows you to create a interactive prototype from a screen flow diagram and wireframes. This took a bit of time to get working properly, but it was worth it. The result was the ability for my users to see at a higher level how all the pages interacted, but also allowed them to walk through the user interface like a simple prototype. There is some sample output at their site.

The best part of using these tools was that I didn't end up with prototype code that I felt bad about not using.

A big whiteboard works equally well (and is my preferred method of prototyping just about everything). Easier to "fix" things on a whiteboard than it is with paper, too.

I have to disagree with this approach. Although i have a lot of fun designing how the gui should look, i think you can spend a lot of time wasting doing this before actually doing the backend work. Believe me i have wasted many hours repositioning buttons, and aligning text, only to throw it away.

My approach for developing Applications using the Model-View-Presenter architecture and an Agile Use Case approach:

1. Write Unit Test for the Presenter/Use Case
2. Write the Presenter
3. Write Unit Test for the Model/Use Case
4. Write the model
5. Write the GUI - this is where you have the fun :)

You've done the hard work. You have implemented the required functionality based on a Use Case/User Story, now make it look pretty.

Another useful link, a list of GUI Prototyping tools:
http://c2.com/cgi/wiki?GuiPrototypingTools

I wish I had time to read all the comments, so if someone already mentioned this, then I second it.

Obviously, the business goals and the user goals (not always the same thing) should drive everything and be documented in requirements, use cases, stories or whatever. Its often helpful to have wire-frame sketches of the UI so users and BA's can visualize how they'd work with the program.

During the Design phase, the UI can be refined more with a tool like Visio or PowerPoint.

Then at the beginning of Development, the UI is finally realized, but with absoluate minimal functionality. The users can then get their hand (and mouse & keyboard) on these dumb UIs and give the developers more feedback.

We always have to keep in mind that people typically think inside their little box. When we enlarge their box slightly, they are apt to enlarge their thinking. I think that was Software Development Principle #201 (_201_Principles_of_Software_Development_ by Alan M. Davis http://www.amazon.com/Principles-Software-Development-Alan-Davis/dp/0070158401).

I also wanted to provide a link to a resource that I found very useful. "Visio - the interaction designer's nail gun" (http://www.guuui.com/issues/02_07.php). This site provides Visio templates that can be used for low-fidelity prototypes for web and windows apps.

On the PowerPoint vs Photoshop comment...you can use Photoshop, but the users are going to focus on things like rounded buttons, shadings of controls, texture. The advantage of low-fi prototyping is that they know its a rough sketch, so they won't focus on fluff. Photoshop can come later, like when Marketing gets it.

Like Keithius, I typically start with a whiteboard. Without that, I'd use a piece of paper and a pencil with a good eraser. Never thought of using post-it notes before.

That's really just the first step though. At some point you need to move on to a GUI builder for your widget set. The reason for this is that at some point you are going to discover that a UI element you were planning on using isn't really well supported for what you had hoped to do with it. When that happens, unless you can find a drop-in replacement, everything's going to have to be rearranged anyway.

You wouldn't use a file system for version control, you wouldn't use a text editor instead of an IDE, you wouldn't use a flat file instead of a database, SO WHY ARE YOU USING PAPER FOR UI DESIGN?

We designed a touch-screen interface using 9x12" magnet white boards. We used tape to mark the dimensions of the screen. We printed pages of adhesive labels with our various widgets printed on them in the size we wanted to use, cut them out and stuck them to a flexible magnet material (like you find on refrigerator magnets). It was fast, you could see the proportions of the screen. If you wanted to note things or one-off screen elements, you could use dry erase markers. It was the smartest thing we ever did and made a huge improvement in GUI discussions. You could mock up a dozen screens in just a few minutes and then pass them around the room for people to see and comment on.

Couldn't agree with you more, paper prototyping was a hard lesson learned. I worked on an capital 'A' Agile project (capital 'A' as in Steve Yegge's post Good Agile, Bad Agile). Anyhow, the managers/leads pushed YAGNI, and evolutionary software/UI design. At the time we all thought it seemed like a good idea - none of us had been on a capital 'A' Agile project. Needless to say the UI was a disaster - like a horse in blinders we all focused on what was in front of us - we ended up with Frankenstein, we had overlooked the big picture. One of the biggest lessons learned was big UI design upfront first, but no architectural / software design until later. I'm still not sure what I think about Evolutionary Software Design, it's a neat concept, but I'd rather focus on a plan of attack.

Dude!

You are giving away all our secrets as gatekeepers to the esoteric world of application dev.

This is what I get paid the bigbux for.

What's next? A post about codesmith? Or how about Expression Blend omega-typing? You're gonna make it seem like this isn't hard work at all!

I couldn't disagree with this post more. Don't let your UI lead your requirements specification. Create functional requirements and object rules so that you know what they're going to do before you decide how it will show up in the UI.

don't get me wrong, I agree with Jeff's stipulation that to the user the UI is the application, but don't let that be reason enough to build a house without a foundation.

@Gabe,

i'm pretty sure it's assumed that the requirements are gathered already, before UI starts. nowhere in jeff's post did he suggest to let the UI lead drive the requirement specification.

One advantage of working on the GUI a bit, even if you've already got a design in mind for the rest of the system, is you'll discover things that users need to be able to do, and can build those tasks into the rest of the system rather than implementing them poorly (ie. bugs or confusing behavior) or just not implementing them at all.

You should iterate. Think of a general design for the UI. Think of the design of the rest. Implement some of the rest, use dummy objects with dummy data, maybe just read it from some temporary data store. Then do the GUI, and really play with it. Try to do the kinds of things users will be doing. If you did something like "user stories" then do those. Then you might need to redesign the GUI, and you might need to redesign the rest. Etc.

Oh thank god, I'm not alone.

I have spent the last 4 months trying to build a website for my business that is used totally internally and I have been fighting with GUI the whole time -- trying to fit a square peg in a round whole ... or more accurately, trying to fit a dozen square pegs into a few different sized holes that are less round and more oblong.

I'm with John Pirie (sp?) here. UI and backend should be decoupled. A lot of people here this and think "well, in an academic world that would be possible". Well, it is possible in the real world, and all it requires is that things be done right.

Paper prototyping is good if you aren't wedded to a specific UI. For instance, you start using a Windows GUI designer, and then you are screwed when you try to port that to a Series 60 interface. Or a web interface. Etc.

If the UI is set in stone, a good designer has advantages to offer -- like not letting you draw impossible interfaces. Still, a paper prototype pass has much to offer.

BUT, all UI prototyping let you do is come up with the UI requirements ALONE. If your application is nothing more than a GUI front end for a specialized database, then maybe that's all there is to your requirements.

The moment you have a single business rule that is not an UI-element, then you have to find out what the backend requirements are. The UI requirments help there, as they identify use cases. And sometimes the backend requirements feed back into the UI requirements, by showing there are user interactions required to make the process work that were not taken into account.

I agree that UI specialists are great, the same way that DB specialists are great. As long as no specialist is allowed to impose his vision on fields outside his expertise. Which, of course, requires communication between all experts and consensus-driven design. Which as we all know, is hard as hell. See also the Mythical Man-month for further consequences.

In the end, a generalist may not be able to design a system with particulars as good as those designed by experts, but whole software will probably work better, and will certainly be done faster. Such is life.

My previous and current job have both been "software engineering" jobs where we serve a large portion of folks (intranet apps for university, then county government), but have a small staff to do it with. The apps I've written are typically being served to a decently large scope of folks.

The first thing I've always looked at with new projects is the data involved. First because the client often doesn't exactly know what data they are processing (I just want my app to to X) and secondly it drives what my UI will ultimately be like.

Is the desired application just dealing with a mass of rows and a basic query? Then I'll tailor the app to look more "spreadsheetish" and focus on easy navigation amongst the result set. Is the desired application more of a forms processing type app? Then I'll make sure not to overload the end user with data input, potentially step them through a few pages to enter the data, and then give the final report.

I made the mistake in my first "real world" app of not looking at the data first, going straight to UI, and wound up having to revamp a lot of code in the late phases of coding since they still wanted everything to look the same.

When working in Agile development environments, I find that there is often pushback with regard to any "up front" design work. With Interaction Design, you ABSOLUTELY have to do some up front design. You wouldn't pour the foundation of a house before the architect decided if the building should face south in order to capture as much natural light as possible. That might seem like a minor detail to the concrete contractor, but that drastically effect the success of a building.

I have done some paper prototyping but I find that, while it is useful for myself other designers, stakeholders and test subjects don't "get it". I usually fall back to lo-fi mockups done in Illustrator which give everyone a better visual. I can still do a "boxes and lines" mockup in illustrator faster than paper any way and it is easier to share with others than paper.

I think whatever method allows you to be efficient personally is fine as long as you don't get too hung up in the details at this stage. If you are mocking something up in illustrator or photoshop you can tell if you are getting too detailed by how much work it is to change. If you find yourself saying "Great... now I have to change 40 layers... I can't believe I need to change this" then that might mean that it is too detailed and you are too attached to it.

You must remember that many changes and modifications to the design are expected so plan for it.

I totally agree with you: The UI is the first thing, a user sees and is very important. A great software with a bad UI is a bad software. 37signals say something similar: http://gettingreal.37signals.com/ch09_Interface_First.php

For the pros and cons of paper-prototyping see http://www.uie.com/articles/paper_prototyping/.

And for a great introduction to User Interfaces take a look at this MIT course: http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall-2004/CourseHome/

Totally agreed Jeff - The customer could care less about anything behind the UI. In my 17 years of experience working both as a developer on several ISV and SI projects, the customer only cares about the UI and really, isn't that all that matters :-)

http://softwareindustrialization.com/CategoryView,category,Storyboard+Designer.aspx

And a great storyboard tool can be found at: http://www.stpsoft.co.uk/story/

Say yes to UI first!

I'm 100% on board with UI first.

I usually start with a quick bullet list of features/components for each page. I'll give the items in the list a weighting too so I can determine which widget/component/element of the page gets more real estate or prominence on the page.

My next step is to browse tons of sites for good UI ideas. Some of the best sites to check out may have nothing to do with the type of app your building so its a good idea to get creative here. When I find widgets or metaphors that apply to my app I'll print 'em out.

After that I'll hit the notepad w/ a pencil and draw out a UI making sure I adhere to the weights that I assigned in my listing step.

Finally, its off to Photoshop. If I have a graphics person on board (which is rare... aka never) then they can start a comp while I move on to non-ui code.

After the comp is done I mark up margins etc with their sizes in pixels... then off to CSS land.

As far as code goes i'll stub out the functions for gathering first... even if they just return BS for now. That way if someone else on the team starts on the HTML/CSS they have data to work with even if its fake. If i'm running solo I'll take it one component at a time; write data access stuff, make it look cute, then the next component etc etc

Personally I've found photoshop to be the most useful tool in the process. You can get pixel perfect and all that which is a big advantage when moving to writing the CSS. You can make it feel interactive if you use layer groups... its not the same cuz you're not hitting the submit button but its better than nothing.

-Arin

I absolutely disagree with this approach. I've just spent the past 6 months of my life groping through a tangled mess of code that has been implemented this way. The problem is that it is too easy to just add code to the form controls' event handlers, and many coders seem to do just that (ie put virtually all the code there). This leads to a maintenance nightmare. A clear decoupling of UI from back end code is essential, and decoupling of elements within the back end is highly desirable. Whilst UI design may have some impact on parts of the back end, these parts should be decoupled from the business logic.

"I absolutely disagree with this approach. I've just spent the past 6 months of my life groping through a tangled mess of code that has been implemented this way. The problem is that it is too easy to just add code to the form controls' event handlers, and many coders seem to do just that (ie put virtually all the code there). This leads to a maintenance nightmare. A clear decoupling of UI from back end code is essential, and decoupling of elements within the back end is highly desirable. Whilst UI design may have some impact on parts of the back end, these parts should be decoupled from the business logic."

i don't think you quite understand the point of the post. what you described is a bad practice in coding, has nothing to do with UI design upfront.

How come the prototype Excel 2007 chart dialog is better than what they actually implemented?

Personally, unless i start a project with the fun stuff (the coding) then there's no chance it will ever materialize, i'll just sit with pen and paper frustrated at the lack of progress - i might sit for hours trying to decide on a good interface design without getting anywhere. If i start to code then i'm guaranteed to get somewhere. And if it means i have to redo the code in the future because i rushed in then no problem, more coding = more fun. I'd rather code multiple times than endure the frustration and disappointment of UI design (or anything artistic). I'd rather go around in circles for a while than having to sit still - at least i get some exercise - if that's a valid analogy.

Allow me to introduce the "excellent" principle of "The Easier First". :)

Start a project, code the easy and exciting stuff until you hit a wall. Ask yourself, "is there a wall better than this one that i could be hitting my head against"? If answer is yes work your way through that wall until you hit a wall tougher than the previous one. If answer is no then change your state of mind to "this has to be done" and "the sooner the better" remind yourself of what's on the other side (easier walls). Repeat.

Know thyself.

One development method does not cover all types of projects. Very large projects with many forms cry out for full many design approaches to get the whole story. A small application with a single form and a small number of use cases might just as well start with the UI.

The question is how do you get a shared definition of what is needed? Words have different meanings to programmers/architects/db and users. Users need something concrete. People who actually execute work processes have to use this stuff. Most don't understand use cases. They understand widgets on a screen.

It depends, right? I agree that you have to design the UI well enough to design the program logic, and design the program logic well enough to design the data layer. But what that entails will vary from one project to another. If I'm writing something like Google 1.0 or Deep Blue, I'm sorry to disappoint you, but the UI design is so simple it might not even make it onto a napkin.

One guy I worked with insisted that you should always start with the database model. Always. Evidently he never ventured far outside his domain of data-centric applications. His approach may be fine, as long as the UI and logic are so simple that they are effectively implicit.

I'd also like to add that I've observed that when it comes to UI design, programmers are like the children of Lake Wobegon. They're all above average. It's pretty rare for a programmer to consider himself a poor UI designer. You can't see your own blind spots. This false confidence is probably a big reason why so many programmer-designed UIs suck... even if they are done first.

I've never been on a team that suffered from having too many UI designers. Too few, very typical in my 15 years. A really good designer will be able to work on an Agile team -- it takes knowing which decisions should be made up front, which ones can be deferred, and how to communicate them to the team.

@Bobby

Please don't apply for a position in my development team. Coding "easy" first is the WORST way I can imagine creating a system. Quite often it's "easy" because you haven't come to grips the with requirements yet. I have had enough of wiping the up after coders with this "philosophy".

Seriously though.. all the people that say "you end up with tightly coupled spagetti hell" by doing UI first are missing a VERY big point. I never would recommend actually designing UI in your primary development environment. Use a graphics program or a special UI design tool. You do NO programming.. you are only defining application flow, data needed, and functional requirements. You are NOT creating the actual UI code that is to be used. So when you are done with the UI "design" you can still code from the bottom. But like the house and a foundation metaphor, you now have the blueprint for the house and you can make the foundation fit it.

I love doing back-of-the-envelope drawings of interface elements, application flow, architecture etc. But once I start implementing stuff I inevitably discover things I hadn't though about, and realize that other things won't quite work as planned. So I guess it's best to take small steps. Doing UI-driven development doesn't mean you need to design the entire UI upfront!

@Jeremy

I follow a very modular and component based approach. If i have all the requirements and understanding necessary to implement a component (i.e. it's easy) then i implement it immediately, otherwise i wait on it until i have a better understanding. I guess the advantages of component based development are lost on some of us.

Joel Spolsky's entry on Biculturalism is relevant here.
He claims there is a cultural divide between UNIX people and Windows people, which explains why Windows software is GUI-oriented while Unix software is command-line oriented. He explains this much more beautifully than I. If only I could post the link...

OK, posting it:
http://www.joelonsoftware.com/articles/Biculturalism.html

A question from which direction you come and in which direction you have to go. And it's a question of personality if you use paper based prototypes or excel. I personally prefer mind prototype. I move elements around in my imagination and come to high quality result where elements are positioned in the best way. I do this because it's more quickly than drawing anything. In team work prototypes are very important to share your point of view. I came to programming vie HTML so for me it's so f*ing normal to think (better say imagine) of the UI intuitively that I have changed completely to an API (or data interface) view of things. It's more important to create a webservice (which is or could be accessible via terminal) than creating a well-formed user-interface. So you SHOULD NEVER let a UI designer design a webservice. The first step is the layers behind the thing and easy information flow on an abstract level. I for my self HATE terminals because I really hate hacking dumb words into a keyboard, it's stupid work. WHEN I do this I want that this work gets a high value, so I want to write reusable code. E.g. I never insert simple SQL statements to a terminal. For simple statement I use PHP scripts or UI like PMA.

So creating interfaces (good interfaces ;) is a natural intuitive process for me because the more often you access structured information the same way the more you "cry" for an easy human interface. People who embrace their console the whole day are not human beings.

Forgive the commercial plug, but anyone who is interested in participating in a prototyping software beta, visit here: http://www.protoshare.com/

All the issues discussed here were the impetus for our product dev. You've got to do the UI first, do it quickly, change it a lot, and get all the stakeholders involved. ( I hate it when the client doesn't actually look at what you're doing until 3 days before the site goes live.) It's really about developing a workable, implementable spec with the client before you start coding.

The last several years I have been very much a UI first type of developer it has seemed to work out very nicely for me.

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.

Tom (and co), who think that GUIs are the be-all-and-end-all of user interfaces, please cosider those of us who really don't want to work with them.

We like to automate stuff, having a nice scriptable interface is a must. Don't assume that I particularly care to learn your programming/scripting languages of choice, just let my choice of glue language interface with it.

Never assume that the input of any program will be provided by a human, it's just as likely for me to script the process.

Never assume that your reports are the end of your application, they might as well be input for something else.

@Tom:
Quote: "What will our users do?" => GUI
Nope. Perl script, getting data off another host and sending it to your application.

Quote: "What do our users want back?" => GUI
Nope, plain text output for sending to another system as a regular task which MUST not involve humans for normal use.

Quote: The architecture and data format have absolutely no bearing on this question. They're part of the next questions: "How do *I* solve this problem?", "What problems might *I* encounter in 5 years?", "Will this interface with *my* competitors?"

You also forgot the bit about being able to use them with multiple other programs, on multiple different hosts.

Quote: *How* you get there is entirely immaterial to the user, except that it must be fast enough not to annoy them. Note the word "enough". Also, it doesn't matter if it's come up with a result, unless it DISPLAYS it within this time => GUI.

I don't want/need a display. I need the data, not the formatting. Formatting is an option, but lack of formatting is mandatory.

Devdas, you're confusing UI with GUI.

also, if a program is automated then of course it doesn't need much of an UI...

"I don't want/need a display. I need the data, not the formatting. Formatting is an option, but lack of formatting is mandatory."

are you THE ONLY user of the system? and will always be THE ONLY user? can you speak for others who are using or may be using the application??

Jin, the comment I was responding to was trying to do the GUI enforcement.

Lack of mandated formatting allows me to easily convert the data into other forms.

Having formatted data as an option allows for humans to deal with the data.

Having lack of formatting allows machines to deal with the data. Machine readable data can be converted into human readable format more easily than vice versa (cue the comment from people who have written screen scraping programs for mainframes).

My point was more in terms of making automation easy, rather than trying to enforce a GUI and making it difficult.

Devads, i'm for using a method where the method applies, appropriately. if you're focusing on automation, then a UI may not be a focus. I didn't read through all the comments in this particular blog, i just hope people don't mistake UI in this topic with GUI.

Designing the UI first is critical to delivering a good experience for normal users. When prototyping a web interface (intranet or internet) for a client, it's pen and paper, to Photoshop/Illustrator, to HTML+CSS ready for implementation. The Photoshop step can sometimes be jumped if you have a decent Web Designer.

Even if you have awful graphic design skills you can still iterate using this methodology. Even go as far as using some JavaScript or similar to emulate how data may be loaded from a backend. Best of all is that you can work this way and not overly compromise on design or architecture (an invalid point raised in some comments).

Something else that is important but is more of a 'softer' issue is branding. You can follow the approach above and deliver a UI that is usable, but the icing on the cake is involving a good graphic designer and someone in a marketing type role who ensures you have a consistent design across your collection of applications, and common functionality/patterns exist.

If you are developing in C or C++, consider using XVT for your GUI layout. It has a convenient drop and drag layout for user interface objects/views/widgets, etc. Then, when you're done, you'll get ansi compliant C or C++ code for the GUI, and you can compile this code on any (and all) of a dozen platforms. This product's capabilities seems to be the best kept secret in the developer world *sigh*

Whiteboard + digital camera + Whiteboard Photo http://www.polyvision.com/products/wbp.asp . I really love this tool (not affiliated with it in any way). It's not obvious it actually adds anything other then aesthetics, but it's just magical...

I don't know why anyone would use paper over a whiteboard in the digital age :-p

also +1 for Denim http://dub.washington.edu/denim/

Typically, my big GUI designs so far has been moving paper-and-pen processes to web-based applications for internal clients. So I've developed the following process:

1 - GUI design starts with looking at the paper forms that currently exist; find out what information is not on the forms that is also collected.

2 - Mock up with whiteboard, dry erase markers, Post-It Notes, and the end-users. One large package of yellow sticky notes used up now is worth many, many hours of my time spent in redesign later.

3 - Mock up the whiteboard ideas in HTML (static screens only, no live data) Review with end-users. This second review will often prompt recall of things that were not thought up in the previous step.

4 - Build application

5 - Review working application with end-users. Let them play with it, without live data, for a week or so.

6 - Make the GUI screens a bit prettier, neaten up placement, move a few elements around as requested. Couple of days for further review.

7 - Go production and maintain. If serious changes are required, back to step 1 or 2.

"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.

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.

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!!

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.

Of course UI is must while working on the Web app or by adding a feature to the exsisting application or while working on plug-in for some other application. UI is quite hard but i think now we got the solution to make the UI very easy.....