The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

App design mockups - 1st failure.

Ok, so I'll be writing an app for my (non computer related) work. I decided to follow the advice of a recent thread, and made a GUI mockup in Visio.

Behold, I showed it to one of the future users, and all he was commenting about was the look of the GUI. "Hey, what kind of skin is that? it's XP right?" - "It looks ugly". Yap, yap. Nothing about the functionality of the app.

So, in order to show to the bosses, I think I have to whip up a black'n'white mockup in a paint program or maybe Illustrator. A whiteboard is unfortunately not an option at this time.

That's my story so far.
Monday, September 20, 2004
Get used to it :) I'm convinced that most people focus on the appearance because the closest they come to knowing what it is they're really doing is rote playback of things they were told to do or things that worked in the past.
Ron Porter Send private email
Monday, September 20, 2004
"I'm convinced that most people focus on the appearance because the closest they come to knowing "

The programer sees that this is a PICTURE of a program. When he sees a program and interacts with it, he can "see" the bits behind it.

The non programmer can't distinguish between the picture and the program.

You need a caption for your GUI mockup, stealing a line from frued (I think):


Read the books on paper protyping: don't make your prot' look too good. Make it LOOK at unformed as the inside really is.
Mr. Analogy {Shrinkwrap ISV owner} Send private email
Monday, September 20, 2004
Mr. Analogy,

The quote you want is under a picture of a tobacco pipe
and reads "This is not a pipe" in french.  It's by
Renee Magritte.

But it's still a good point.

Thomas E. Kammeyer Send private email
Monday, September 20, 2004
"The non programmer can't distinguish between the picture and the program. "

To the average person (including the average Pointy Haired Boss), the GUI *IS* the program.
muppet 3.11 pro gold Send private email
Monday, September 20, 2004
I have found the following analogy works well to explain a mock-up to a non-technical person.

"Think of this like a full-size clay model of a new car. It gives you an idea of what it will look like but there are no moving parts, it is all just clay"
Tuesday, September 21, 2004
I can sympathize.

The number one feedback our client gave us on a screen design document was "make sure there are 15 pixels of space between all the buttons."
Caffeinated Send private email
Tuesday, September 21, 2004
I am even further down the development cycle and I'm totally dismayed.

I have been part of the design of a very neat, highly functional, highly flexible web app and we are just about finished.  My team loves the interface/GUI.  We took out all the unecessary graphics that slowed down the site and made it clunky and less navigable.

We now have a clean, spare GUI that allows us to flip languages, add pages, etc., by adding a few rows in the database, customize it per user, ties data together logically instead of haphazardly.

The initial user testing leads me to believe this was all for naught.  Not a single person has commented on the cleaner look nor navigation nor functionality, and the first impression of their impression is that they want the graphics and whiz bang crap as before.

I've designed the best app of my life and that is the feedback.

I'm disgusted.
Tuesday, September 21, 2004
My suspicion is that you made the prototype look *too much* like a finished product. If they are able to identify the skin then that definitely is the case. IMO a prototype should always clearly be a prototype.

Paper prototyping has the advantage that you don't get the 'your pixels don't line up' problem.

Failing that, I use Powerpoint. Everybody knows what a ppt demonstration is, and no-one should confuse that with working software!
Les C Send private email
Wednesday, September 22, 2004
I agree there are dangers to having paper prototypes that look too finished, but I wonder how much of the problem isn't the prototype, but the questions you ask. Regardless of the quality of the prototype, I rarely ever get useful feedback to asking a very open ended "how's this look?" Instead, I go in with specific questions to address specific usability issues. I show a user the prototype and ask things like "if you wanted to get information on such-and-such, what would you do?" (is my window so cluttered that users can't tell where to begin), "what blanks would you fill out?" (are my means of indicating required field successful), "what do you think would happen if you clicked *this*?" (are my button labels effective). Of course, maybe you tried doing that, and they just cut you off with irrelevancies.
Michael Zuschlag Send private email
Wednesday, September 22, 2004
Working on a websystem I used a model where I first made the mockup on paper with just a pencil on white paper. I drew all windows, input fields and buttons but no text or anything. Then I went trough it with the customer page by page (window by window) like "so this is what youll se first a window with theses buttons, this button do this and this do that. If you press that one you will go to this window and be able to do that and that". This made it possible for the customer to get a feeling for the process of working with the app.

We made changes, rearanged buttons and the order of things, windows and so, very easy.

Next step was to give all this to the designer who then made html mockups with the actual design, colors and everything. And the customer could then bicker about that with him.

This was good for a coupple of reasons. Easy to give the customer a feeling of how the system would work, and it was easy to change anything if I had missunderstood anything in the specifications. And there was no focus on design colors and stuff.

Then the colors and margins and things like that was handled by the designer.

Worked very nice I must say.

Oh, and the I got fired btw... but thats a different story.
Wednesday, September 22, 2004
Yes, don't let Zibbo's unfortunate end cloud the main point.

In presenting design we are abstracting at the highest possible level, higher than any level will subsequently be in implementation.

If you need to prototype an interface make sure you've understood the process the user understands first and their expectations.  Never provide anything that looks like an application unless it behaves in large part like an application and actually does something, in other words it really is the application.

Instead draw it in front of them, no, draw it with them.  If you're fast enough with something like visio then ok, use that but my bet is that that will be an insufficiently abstracted view for the user.  They may cognitively understand it doesn't exist, but emotionally it will seem not only real, but complete.  Not only is that bad because expectations are raised, its bad because the user may feel that their input ends at that point.

So, draw it on paper with a pencil and throw away anything anyone doesn't like, crumple it up and throw it away.  Make it clear that there are no rules for them as users, only means of getting what they need done, done.  As the technical designer/implementor you can worry about the rules of your platform and your framework, that's your problem, not theirs.
Simon Lucy Send private email
Wednesday, September 22, 2004
Oh and people frequently mistake Powerpoint demonstrations and all the other demoware as real applications.
Simon Lucy Send private email
Wednesday, September 22, 2004
Yup, I can't see any point whatsoever in spending time doing a computer based 'mock-up' of an applictation. Depends on the application maybe.

It takes bloody ages to get everything looking nice and it doesn't do anything.

I'd just get an artists pad and a pencil, or a few coloured ones perhaps to differentiate text boxes and command buttons. Then tell them what each is going to do.

If they really need a mockup on the computer then they need one that works. Ish. If it were a database app (which is all I know about, really) then knock something up in Access, before doing the real one using a proper database development tool. Irony.
Mike MacSween Send private email
Wednesday, September 22, 2004
RE Powerpoint as demoware. Those involved at all with software are pretty clear that if it's done with Powerpoint, it's not real. So, it depends on your audience. If you are presenting a design proposal to your peers, Powerpoint is a decent solution. If you are presenting to real users, using paper is probably better.
Miles Archer
Wednesday, September 22, 2004
Show off the Powerpoint slides with a data projector rather than a computer screen to increase the  psychological distance. No keyboard == no real application. Normal salesman animations are fine but don't animate text entry. Another benefit is you can spin to more than one person at once.

If you hand out slide preprints containing space for comments before the show and collect them afterwards you can keep their interest without raising expectations.

These techniques were thrashed out with the overhead projectors you trip over in older conference rooms.
Wednesday, September 22, 2004
Have you guys tried this (hand drawn looking) approach with external customers as well as internal? I'm just thinking that if I gave a presentation or delivered a proposal which included some diagrams that looked like I'd knocked them up on the train on the way over, it might not get taken seriously.

Thursday, September 23, 2004
Well, when presenting the pencil drawn paper mockups, you must have done you homework. You must know everything and how it is connected. And you must know what the customer whatns to accomplish, and why.

To show up with a blank paper and a pen and jst say, "What did you say on the phone you wanted, can't really remeber?" is not the way to go. =D
Thursday, September 23, 2004
Why not, that's the way I write my code ;-)

I'm more concerned that someone seeing hand drawn diagrams might make a false assumption about how good your work is. Assuming aou and your competitor have shown similarly good understanding of the problem, and the only difference in your presentations are hand drawn diagrams against "screen shots", who are they likely to give the work to?

Thursday, September 23, 2004
Here's the general process.

You work up your pictures before you meet, you get it down inside your head your picture of the app and how things stick together.  You might take the pictures with you but you start with an empty pad with the client and you sketch through it as you have a conversation.

And yes it works with internal and external clients.  In a pure developer context I've used white boards to do the same thing.  With a client I may take my portable Nobo board and use the whiteboard on that, or draw on the big tear off sheets.
Simon Lucy Send private email
Thursday, September 23, 2004
The problem with any kind of finished graphic is that its finished and its hard to alter with the stakeholders present.  You end up with some idea in your head of the changes or you've written them down and you go away saying 'I'll get the changes to you...'

You've immediately put a brick wall between the stakeholders and their result. 

Keep it sketchy, keep it fluid then give them something that works quickly and incrementally grow it in front of them.
Simon Lucy Send private email
Thursday, September 23, 2004
> you start with an empty pad with the client and...

My head doesn't contain enough free RAM for that :-)

I'm useless unless I have context, which reminds me of the next "step". I guess once I was a screen or two in I might get the flow, but there is always the chance of missing something you've already worked out. You can hardly ring them up afterwards and say "Oh, you know that case we were talking about which I didn't think I'd thought about. Seems I had and my memory farted on me." They just won't believe you, and even if they do it doesn't exactly look good.

If you're in a "discovery" type phase then I think this approach could work really well, but as a bid document or presentation I don't think I'd use it.

Thursday, September 23, 2004
Well it is all an incremential process. And it all depends on the customer and whatnot. Sometimes the client phones you right after the meeting remembering somethings that never came up, and sometimes (very often I must say) I call the client making a new appointment to talk about things I forgot or more likley, things that showed up during the workprocess that you couldn't forsee.

It's like when you have a problem, you take a break, smoke a cigarett and then BANG! Aw! you know the answer to that problem. It's the same thing when working on a process flow with mockups. It do not take one meeting, it takes several.

Now, this process I am talking about is not during the sellphase, when you start doing this there is allready a commitment.

Where I worked like this the normal process was that a seller booked a meeting with the client and met them and figured out what they wanted (or what he could manage them to think they wanted, you all know the drill). Next time our design department showed up with som brilliant mockups made in powerpoint och flash or something to just throw somethng shiney in front of thir eyes to make them commited to pay for a development process to make the specifications, a pre-studie. And this is where the paper mockups and html designer pages showed up. And this could very very often have no connection whatsoever with whatever was first shown to the customer. But that was no problem, since the customer himself had been involved in the designing of the system to this point.

Next step was than to tell the customer how much it would cost him to bring all this to life. Now tha customer has spent some money on designing a system e really likes he would most of the time put up the money to have it "finished".

This worked quite well in cases where the client was relativley small and the system was not to big.

It did not work well at all with big companies and big or small systems.

And I did only lose my job because the company didn't go that well, and that was due to they management putting all their eggs in one basket with a big big company and the process of getting money for the eggs took about 1 year longer thaen they had intended. No money = no salaries to pay the emplee = layoffs.
Thursday, September 23, 2004
Check out the book "Software For Use" by Constantine and Lockwook, and their web site for some ideas on prototyping. One of their suggestions is to keep focused on (a) the information that is presented, (b) the tools that are available to use or modify that info, and (c) the navigation to and from other parts of the application. They have suggested using different colored Post-Its for the latter. The idea being to keep people thinking not of the static appearance of a final presentation, but on what is to be accomplished by having it.

No silver bullets here, and you'll never satisfy all the people all the time. But some useful ideas to think about adding to your bag of tricks.
Dave Lathrop Send private email
Monday, September 27, 2004
Followup: I decided to go with the Visio route (I tried Illustrator, but I had to design my own widget set, which was painful.)

I added a lot of annotations to each field the users' supposed to edit. I also added notes like "note: this program does NOT exists. it's a drawing only." It doesn't look real.

I'll follow up on the results when the bosses wake from their sleep.
Friday, October 01, 2004

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz