: Mockups: Coding vs Drawing? This isn't about web design but about interface design in general. Is better to code Interface Mockups or "draw" them in a graphics program, like GIMP, Photoshop,

@Kaufman565

For UI design I have three stages with different objectives:


Sketching. First, you want to get the basic idea down of what elements there will be and how they will fit together. Any fine detail or aesthetic perfectionism at this stage is a distraction. I use a whiteboard and fat erasable pen so it's impossible to get distracted by too much detail and easy to scribble loads of different ideas and start again at any time. I've heard of people who only sketch on small post-it notes or only use their off-hand (e.g. left hand if you're right handed) to force themselves to not pay any attention at all to the aesthetics and focus 100% on the idea and function. (image not mine, from Frank Prendegast)





(2!) Simulating. Second, you want to get the look down and get feedback, finding out as much as you can about what people's intuitions and unprompted responses are before you start the time consuming implementation work. This should be in whatever you work most effeciently in since if you're doing it right, you should be going 'back to the drawing board' often, seeking out criticism and aiming to identify as many unexpected issues as early as possible. If you're a crazy coding machine and it's what you work most comfortably in, then coding is fine, but most people will work faster in something like Fireworks, Photoshop, dedicated wireframing software, or maybe a UI-driven interface builder like Flash Catalyst (fine if the end product isn't Flash, the goal is to get good feedback before you begin implementation).
(3!) Implementing. Finally, you implement the thing and aim to do so in a way that allows you to get more feedback early and often.


These three parts of the project cycle have different aims so if it's a big project it makes sense to use the most suitable tool for the job in each stage.

Vote Up Vote Down

@Shelton719

What works for me is to create mockups using a program that emphasizes not creating pixel-perfect layouts. For me that is Balsamiq Mockups, which you can check out at www.balsamiq.com/products/mockups

Vote Up Vote Down

@Shelley591

This question is a bit vague and, as such, as are the answers.

On top of that, projects will vary wildly, as will teams.

That said, there is no 'best'. It's about using all tools in a workflow that makes the most sense for you and your team.

Generically speaking, I'd say this is the type of workflow you should aim for:


Sketch. Pencil + paper. Whiteboards. Iterate. Work with as many team members as you can.
low-fi mock-ups. Could be PSD, could be visio. Could be paper. User test these.
Get to building prototypes. This is where you want to start doing as much as you can in working code. Jump into Photoshop as you need and get the stuff out of it into code as fast as you can. Continue user testing/iterating.

Vote Up Vote Down

@Turnbaugh909

Ask yourself these questions:


How many UI layouts/options can you explore in 30 minutes by coding? How many can you explore by sketching?
How often do you get a UI design exactly right on the very first try? If not very often, how quick/easy is it to change a sketch versus a coded mockup?
Can you instantly identify a color just by looking at its hex/rgb code (not just a ballpark guess, but the exact shade/color)? When you picture a color in your mind, can you immediately translate that to hex? How fast can you pick out a color scheme by typing in hex codes versus using a real color picker?


The fact that you're asking this question tells me that you're most-likely a programmer, not a designer, by training. If you were a designer, then it would be as absurd as developing an application without planning out the class structure, database design, application architecture, etc. and just jumping right into coding—and if you're an experienced developer, then you know what kind of problems this sort of bottom-up development causes.

Similarly, if you jump straight to code without actually designing your UI first, then the results aren't going to be pretty, if only because it's impractical to perfect a good design by coding blindly.

Vote Up Vote Down

@Si6392903

I'd vote for "drawing" first. In GUI, proper layout/presentation is the key and it calls for visual means to be designed. Designing GUI visually lets you rapidly change your design without having to "imagine" each change, "translate it to code" and finally test it. The other way is also possible, but it's rarely better (e.g. project is extremely small, like just a couple of buttons and you're familiar and used to working at "code" level; during design some patterns may emerge, that can be just reused with slight modification).

If you're designing for a specific widget toolkit, you can also use some "GUI designer" application if available. It'll speed up even more GUI design process, because it both shows exactly how designed GUI will look like in running program and can export ready to use GUI description at presentational level.

Vote Up Vote Down