Tell me more ×
Graphic Design Stack Exchange is a question and answer site for professional graphic designers and non-designers trying to do their own graphic design. It's 100% free, no registration required.
up vote 7 down vote favorite
3

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, etc.?

share|improve this question
3  
I always get told "sketch your interface,if you do it in photoshop or whatever people will think you're further than you really are. Leave your mockups looking sketchy, just get the basics down so your client knows what to expect and then expand on your UI later." – Johannes Dec 15 '11 at 19:26
1  
It's entirely dependent on the project. There's no universal 'best' answer. – DA01 Nov 29 '12 at 18:37

5 Answers

up vote 5 down vote

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.

share|improve this answer
2  
"and you're familiar and used to working at "code" level" -> It's important that the UI/UX team can work at code level. Every designer doesn't have to be a coder, but the team needs to be able to build everything they design and understand the engineering as much as the visual design. – DA01 Dec 15 '11 at 15:23
I can agree as long as you mean a team as a whole. I think that, when you're just designing UI/UX, not coding it, knowledge of code inner workings can actually hold you back, because you'll tend to avoid some potential solutions only because you'll consider them "too hard to implement". It means that your designs can be stripped of some brilliant ideas, because "toolkit thinking" will lock up parts of your imagination. Then again… it's only one side of the blade :) Besides, the question was about "mock-ups" only. – thebodzio Dec 15 '11 at 19:33
1  
I hear the 'hold you back' argument a lot, but find it only comes from visual designers who are stubbornly against learning presentation layer code. These folks also tend to drift towards doing everything in Flash. :) I like to suggest that it's no different than print design. Knowing how printing works doesn't 'hold you back' as a print designer. Rather, it prevents you from creating files that will choke the RIP, or cause the printer to scream at you for 300% ink coverage. It's just about understanding the medium and its associated constraints. – DA01 Dec 15 '11 at 19:36
1  
WYSIWYG isn't for facilitating 'visual thinking'. It's for letting people that don't want to learn something limp along. ;) As for constraints, they define the medium. An architect that can draw great pictures, but doesn't understand the basics of loads and spans is held back to a great extent...as nothing they draw can actually be built. – DA01 Dec 15 '11 at 19:57
1  
(and a lot of my opinion has been formed working either with or on UX teams that have no idea how to build anything they come up with. They aren't innovating most of the time...but rather designing only half-thought out solutions that aren't practical in terms of implementation, timelines, users, or budgets [which are all additional constraints that, rather than being 'walls' are what helps define the design solution]) P.S.: good discussion! – DA01 Dec 15 '11 at 20:04
show 6 more comments
up vote 13 down vote

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.

share|improve this answer
The OP could be talinkg about using a WYSIWYG code editor, with it you can pick colours or even "draw" the objects... – jackJoe Dec 15 '11 at 10:21
2  
Actually, coding without designing UI first is quite valid technique. That is, of course, if "coding" doesn't mean UI or UX parts :). Most APIs and libraries are designed in fact without taking UI into account – that would be just impractical. – thebodzio Dec 15 '11 at 11:46
1  
@lese, you're pitching a waterfall method. Which can be OK, but the trend these days is to go agile, in which it's very likely that you're working in code from day one. – DA01 Dec 15 '11 at 15:24
@DA01: You're working on code from day one, but you're still applying a top-down methodology. There's nothing in agile that says you can't plan out your data architecture or define UI-first before coding (which I think most agile firms prefer over UML, class diagrams, etc.). – Lèse majesté Dec 15 '11 at 18:59
2  
@thebodzio: Yes, of course, that's what separation of concerns is for. But I'm not referring to coding the backend. When I say coding in terms of the designing part of the question (not the programming analogy I used to illustrate the point--I know, a bit confusing), I mean coding the mockup (CSS + HTML or whatever your UI language may be). – Lèse majesté Dec 15 '11 at 19:02
show 7 more comments
up vote 1 down vote

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:

  1. Sketch. Pencil + paper. Whiteboards. Iterate. Work with as many team members as you can.
  2. low-fi mock-ups. Could be PSD, could be visio. Could be paper. User test these.
  3. 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.
share|improve this answer
up vote 0 down vote

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 http://www.balsamiq.com/products/mockups

share|improve this answer
up vote 1 down vote

For UI design I have three stages with different objectives:

  1. 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)

Photo of whiteboard wireframe

  1. (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).

  2. (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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.