Fog Creek Software
Discussion Board




UI Mockups


Any suggestions on tools to do UI mockups with?  I'm mostly interested in doing static drawings, not interactive mockups.

Visio seems to be the tool of choice around here, but I don't find it very easy to work with.

Jason
Wednesday, May 14, 2003

Ummm
You can build the real thing as fast as creating mockups, even if there isn't anything behind the controls.

Simon Lucy
Wednesday, May 14, 2003

Photoshop?
We have covered this before: For developers there are a lot of sound reasons not to make your screen mockups look too much like the finished product. A lot of the non-developer crowd will think that when you show them a "lifelike" UI mockup from Visio, the app is nearly done.
Photshop gives you the opportunity to make these babies look like what they truly are: sketches.

Just me (Sir to you)
Wednesday, May 14, 2003

I have to agree.  It has the advantage of being done when approved.  Years ago I tried visio and hated it... but that's me.

B#
Wednesday, May 14, 2003

A bit off topic.

Beware of showing "the real thing" UI mockups even with not active controls. A lot of users and PHBs associate this with time to completion.... "he already has the program. Just needs to get a couple more functions working in the background. Another week or so, and we will be ready to ship!!". Extremely aggressive deadline anyone?

I would do rough sketches on paper. If you do have the real thing, capture the screen, and use photoshop waterpaint/crayon/etc filters to make it look less real, and more like the rough sketch that it really is.

tapiwa
Wednesday, May 14, 2003

Sir... this is quite freaky. When I started typing, your post was not there. When I posted, it was, and very similar train of thought.

I wonder whether this is a case of great minds think alike or fools seldom differ.

tapiwa
Wednesday, May 14, 2003

Probably the latter ;-).

BTW: does anyone have the perfect filter series for this?

Just me (Sir to you)
Wednesday, May 14, 2003

This was on slashdot recently: http://developers.slashdot.org/developers/03/05/12/2142221.shtml?tid=185

It's more for web developers, but I imagine it could be easily used for apps as well.

It's used to quickly mock up an interface on a pen-based system.

Spam
Wednesday, May 14, 2003

http://www.useit.com/alertbox/20030414.html

"With a paper prototype, you can user test early design ideas at an extremely low cost. Doing so lets you fix usability problems before you waste money implementing something that doesn't work." -- Jacob Nielsen

Danil
Wednesday, May 14, 2003

If your using the QT toolkit, go with QT designer.

J.
Wednesday, May 14, 2003

I agree with the folks who say stay away from the "real ui."  While it is tempting, and in many cases not nearly as time consuming, it has several of drawbacks.  However, if you address the drawbacks up front, you may find it easier in the long run.
- It appears near completion so if they accept it, they can have it by Friday. Right?  While annoying, you can explain this a merely "graphics" at the start and control this idea.
- People hate to ask you to change things you have completed.  I know we all know users who have no problem with "just do it again" but in a UI presentation, everyone should feel that asking you to change anything is not only accepted by expected.
- People expect it to work.  At a demo to a client, things were going great.  So great they let her drive.  She then put in bad data and the application did not edit for it.  She then put in good data and the application did not process it.  They then spent half the meeting discussing why the application was not working, when in fact there was none.

Again, set expectations at the start of the meeting and you can use crayons.  Don't and anything short of a production system will reflect poorly on the team. 

It's not reasonable, or fair, but it is life.  And that beats the alternative.

Mike Gamerland
Wednesday, May 14, 2003

I have found that a combination of Photoshop and Powerpoint work really well.

I use Photoshop to get the window look and feel in the background. Then I use Powerpoint to fill in the content from screen to screen.

Powerpoint is good for editing text quickly. Much quicker than remaking another screenshot in Photoshop.

Also, Powerpoint gives a slight illusion of "movement". You can show where the user clicks, add notes, etc.

My boss used a 100+ .ppt to "demo" a project to his bosses. He was able to show the workflow design, which was all he needed at that point in the design process.

martha
Wednesday, May 14, 2003

MS Excel. No form components just using cell-borders, text, background color. And text boxes for comments ("Here pops up employee search dialog")

nobody you know
Wednesday, May 14, 2003

Microsoft Word's drawing tools are adequate to this job, too.

I love the idea of using PowerPoint, though; having a little animation to illustrate "what will happen" can be remarkably useful.

Brent P. Newhall
Wednesday, May 14, 2003

"Any suggestions on tools to do UI mockups with?  I'm mostly interested in doing static drawings, not interactive mockups."

My recommendation is: If you are looking for someone to provide you with a long and comprehensive list of software products that you can use to accomplish this task (static drawings) then I suggest you ask your question at the technical writing forum (techwhirl).

Question: Why are you only interested in doing static drawings? Who is going to be the audience for your UI mockups?

My advise is: the UI Mockup approach you take should be driven by the circumstances you find yourself in.

For example:

If I am doing an enhancement to an existing program, I normally do a "this is how the real thing will look" UI mockup so the end user can provide me with feedback. Normally, I use a screen capturing program for this type of work and send the animated program to a specific end user via the company's email system.

If the UI mockups are part of the discovery process (something that will be part of a project proposal or something that will be included in a detailed requirements document), I only provide screenshots with written commentary.

If I (or someone else I was working with) was doing some type of formal presentation (i.e. for high level management), I would use Powerpoint.

One Programmer's Opinion
Wednesday, May 14, 2003

I have to second the "crayons" idea.  I've been in too many situations like people have already described, where you can't get the idea across that IT'S NOT A REAL PROGRAM.

To the vast majority of people, if it looks like a program, it's a program.  The two possible responses are (a) Why doesn't it work?, and (b) Look practically finished - when will it be ready?  Tomorrow?

If I were presenting to users or to my boss, I'd use actual crayons (my house is knee-deep in them).  For executives, I'd use PowerPoint, and make it look like it was drawn in crayon.  I'm not kidding.  It's the only way to make them engage their brains - you have to slap non-technical people with a wet mackeral when you're making a subtle point to them.

Actually, I was being sarcastic, but it may *be* a subtle point.  To us, it's a no-brainer that a mock-up is just a pretty face with zero brains behind it.  But what metaphor could the non-technical user be given to make this distinction clear?

I suppose if they're literate enough, "Potemkin village" might work.  Maybe a "prop" for the theatrical?  A "poser" for the young?  A "Milli-Vanilli" for the middle-aged?

Spaghetti Rustler
Wednesday, May 14, 2003

I mostly do Web pages and I've found that Photoshop works best for me.  If you link the layers correctly, its easy to move stuff around/change colors etc.  In fact, I've pulled people into my office and tweaked stuff while they were standing over my shoulder.

I must report though, that someone called complaining that the buttons didn't work on the jpg.  I wish I was making that up.

Lee
Wednesday, May 14, 2003

Small point: is it legal to kill grossly incompetent managers? And if not, why not?

Seriously, any manager who can't understand the difference between a mock-up at the start of a project and a nearly finished product is not competent to manage a software project. They don't have to be able to do the code themselves, they just have to be able to understand what "mock-up" actually means.

As you can't legally kill them, the best bet is to replace them - either by owning the company so you can fire them or by moving to a company which actually hires competent people. I've heard rumours that such companies exist.

andrew m
Wednesday, May 14, 2003

Andrew:

I think it's similar to the case of the Canadian Geese that live by my house. Years ago they got on the endangered species list (or something, you can't kill them anyway), and never got off again. So they keep multiplying and multiplying and leaving ever-growing piles of sh*t in the community park.

8-}

j/k!

Mike Swieton
Wednesday, May 14, 2003

If you use the same actual tool to produce the screens, so that it almost looks like the finished product even though it doesn't do anything, some people will believe the real thing is almost done.

Any software project manager who believes that should be fired.  But very often, the managers who see it are the sponsors of the project from the business side, and they may not have a clue about what it takes to develop software.  So if you show them some actual VB or Delphi forms with fields and buttons (even though they don't function), they can't understand why the project is going to take six more months and cost them $2 million out of their budget.

Unless they want and need an interactive prototype, if there are nontechnical managers looking at it who have the power to affect the success or failure or budget of the project, it can be dangerous to show them something that resembles the finished product.

I use PowerPoint -- arranging lines, arrows, rectangles and words on a plain white background.

T. Norman
Wednesday, May 14, 2003

Well, I've used powerpoint for this and it's worked ok. Used visio much more extensively for this purpose and it's a much better tool -- you can not only do page mockups but also site diagrams which often get quite large and they come out nicely on an E-size plotter. Never tried to do anything in PP that was big enough for a plotter.

Anyway, my 'druthers would be to use a drawing tool like Dia that saves its file as a plain text file (it's xml), because then you can do diffs on it from the source control repository rather than trying to tell from one version of the binary *vsd file to another what changes were made. Would make change management easier for such artifacts. Of course, with VBA under both PP and Visio, I suppose one could write an exporter that could dump a drawing out to some structured text-based format for either of them. So far, though, I haven't had much luck getting good results with Dia, plus our UI folks aren't *nix - literate, so sticking them on a redhat box would vapor-lock them.

Not trying to criticize here, but for the size systems we build, and the way we are with our clients, it would be completely unmanagable to think of doing pen & paper mockups. building them, maintaining them, and ensuring some degree of consistency across the mockups would just not be possible for us. Not sure how folks could ever make that happen successfully for non-trivial systems/sites.

anonQAguy
Wednesday, May 14, 2003

Have you guys ever had a basement finished? The "it looks done, why isn't it?" psychology is much deeper than you would expect.

When we had our basement finished, the framing was done in a day. The wiring took two more days, then the drywall was up 48 hours after that. It then took two weeks before the job was done (tape drywall, fill, sand, paint, fill, sand, paint, sand, paint, sand, paint, lay padding, tape, lay carpet, install fixtures...)
When that drywall was up you couldn't help but feel the contractor was "almost done", yet timewise he was only 25% finished.

Ditto on interfaces - I've seen a coworker design a UI mockup, and even knowing how much work there was to be done kept feeling like "hey, we're well on our way", which is BS.

If you're talking early "use the interface to drive the design" type mockups, then I say whiteboard or easel and markers. You can really get what you need out of that, nobody objects to erasing large sections of design, and dammit, it FEELS like you're just starting.

Now if you've got the data and business layers working and you need to fine-tune or tweak the UI, then go with photoshop, visio, powerpoint, etc.

But I'm now firmly convinced that CAD tools shouldn't be anywhere near a UI design during the design phase.

Philo

Philo
Wednesday, May 14, 2003

I believe the idea of not showing a mockup that looks functional to the client was the subject of a JOS posting (q.v.).

How about a grayed out version for things that don't work yet, gradually coloring them in as the start to work.

As far as mockup tools... what are you doing the project in? What about sketches on a piece of paper, or Photoshop drawings?

www.marktaw.com
Wednesday, May 14, 2003

I haven't had any horrible experiences with showing demos, but maybe I just haven't been around the block enough.  People seem to understand and believe me when I show them a demo and enumerate the items that have yet to be completed, concluding with a THERE IS STILL MUCH WORK LEFT TO DO message in upper-caps so they're sure to read it.

Actually, why isn't it possible to leverage the visiblity of the UI more?  When the project is behind and the developers are demoralized because of a lack of visible progress, why not spend more time on the UI initially to give people the subliminal impression that more work is being done than actually completed?

Alyosha`
Thursday, May 15, 2003

I have tried the "be very clear at the start of the meeting that this is just a mock-up" thing and enhanced it with repeting that 1.000 times throughout the meeting.
It does not work. People see what to them looks like an almost finished product, and that is what they react to.
I have not tried the "grayed out" strategy that was mentioned. Could be another way of trying, but it runs the risk of reducing the expectation schedule to whatever was the surface area in the user interface.
Suppose you have a wizard style impementation of some very hary batch processing type of system. You have 20 screens of setting up the parameters, which you do in implementation in a day or two, and then just that "finish" button is grayed out. How are you going to explain that "ungraying" this will now take another 6 months?

Just me (Sir to you)
Thursday, May 15, 2003

The best user driven UIs I've designed were done on a whiteboard with me starting the process, and drawing the page as I saw fit.

The users then stood in turn, modified the page, argued  their points of view and then agreed an acceptable solution. I copied the design to paper, and we moved onto the next page.

The project sponser could flex their muscles in deciding the final layout, everybody had their say, and I had something that had a fighting chance of being accepted first time round.

Larry
Thursday, May 15, 2003

Creating the mockup directly in the IDE can be MUCH faster then in power point. Otoh, the client will probably then say "ok, so... tomorrow?"

So here comes the grand sollution: make it in the IDE. Then take a screen capture. And then open it in Photoshop!!! I hope you appreciate the beauty of this idea. Have never done it myself, but it sounds as it could work. Applying "emboss edges" and "rough crayons" or something like this, you've got yourself a piece of art!!!

I wish it would be possible to add images to this thing...

Dimitri.
Thursday, May 15, 2003

If you are trying to produce Design Comps then use something like Photoshop or Fireworks to produce a variety of screenshots. If you are trying to produce Wireframes then use something like Dreamweaver or Frontpage.

Don't forget to use lots of "Lorem ipsum..." text to simulate content or, as has already been pointed out, the people you show it to will think it's practically done.

If you bring in some users at the earliest stage possible (and you should) it will be a combined effort to produce paper prototypes using yellow post-it stickies, paper and pencil. You will then find that you will generate Storyboards which also perform basic usability testing.

UI Designer
Thursday, May 15, 2003

Dmitri - still looks like it's done.

Whiteboard. Whiteboard whiteboard whiteboard. Just try it sometime - whiteboard the UI with the users/customers.

BTW, I'm currently suffering on a web portal job where the client okayed the design which had been done in Photoshop. We went through a period at the six week point where the client was *pissed* that it was taking so long. Why? Because "you've got the designs done - don't you just have to hook them up?"

BTW, one thing Camel had that was nice - printing whiteboards. Thought they were a silly affectation at first, but got really, really attached to them.

Philo

Philo
Thursday, May 15, 2003

Ding Ding Ding.. Sounds like we have a winner.

Whiteboards are EXCELLENT mockup tools. More people should use it. Whiteboards should replace Powerpoint as the communication medium of choice durin presentations.

Of course, someone will read that and try (and fail) to create a software package that emulates whiteboards, but what can you do?

www.marktaw.com
Friday, May 16, 2003

Dmitri, I've done the Photoshop (actually mostly just window capture) the UI done in whatever the UI was going to be.

I stick by that because using any other method makes assumptions about what the widget set is capable of or reasonable to do on the particular platform.

Yes I use whiteboards, I have one on an easel I take in the car if I have to.  Whiteboarding though has to be recorded, good if you can print the board (that is so cool), even more so if the whiteboard is an actual screen and pen interface (that is even cooler).

But the thing I wrap around me using the actual UI to present proposals is that I never prototype.  Prototypes are evil unless they are little balsa wood models.  Its the prototyping that gives rise to the 'oh its nearly finished' as well as giving rise to the 'oh its a prototype lets make it do this, or this, or this'. 

One client I had, prototyped for around a year. 

So, no prototypes everything is real. 

Simon Lucy
Friday, May 16, 2003

I've just started evaluating the DENIM product from the Berkeley UI Research people and so far it looks quite promising. I use it with a Wacom tablet but it just occured to me that it could be used in a meeting room with a PC Projector to simulate the whiteboard and have changes be made easily.

I'll have to try that out and see how it goes...

UI Designer
Friday, May 16, 2003

We have a smartboard thingie which you use with a projector. Connects to the PC. You write doodle on the board, and it automatically captures on you PC. Really cheap too, a tad under £1000. Strongly recommend.

http://www.smarttech.com/products/smartboard/index.asp

tapiwa
Sunday, May 18, 2003

A lot of the problem may be the misunderstanding of the term prototype.  A prototype is defined as a working model, but what it sounds like you are presenting to clients is actually a mock-up.  A mock-up is simply a model of a particular aspect of a system.  Example:  A prototype of a new model of car would be something you could sit in and drive, but isn't quite ready to be sold at your local dealer, while a mock-up of a new car would be an oversized matchbox car.  Use the right terminology and you may prevent misunderstandings.

Garrison
Tuesday, May 25, 2004

*  Recent Topics

*  Fog Creek Home