I'm working with a small team that creates a proprietary web application and UX isn't much of a priority since our own people will be the ones operating it, but we do try to make their jobs easier.

Should I, as a developer, create a UI mockup before I start creating a new screen? Nothing too fancy, mostly the general layout in order to talk it over with colleagues and to have a reference model. I was comparing it to creating some UML diagrams before delving into writing code blindly.

One of my coworkers says this is preposterous and isn't my job to do that.

  • 51
    If you don't have designers, and its not the developers job, then who is supposed to do it? The janitor, maybe? Commented Jun 15, 2016 at 17:48
  • 10
    You certainly could, maybe you should, but it is far from unusual and definitely not "preposterous" as your overly dramatic coworker puts it. Depending on the situation and environment, you may be better doing a purposly rough mockup rather than something that looks too much like a finished product. Balsamiq is a good tool for this, as is just drawing your mockup on paper or a whiteboard. Commented Jun 15, 2016 at 17:49
  • 3
    I assume you really mean "mockup?" A "mock" is something else. Commented Jun 15, 2016 at 19:24
  • 23
    User Experience Design goes beyond making things look pretty. Programmers should be very involved with it.
    – JeffO
    Commented Jun 15, 2016 at 21:12
  • 2
    what is preposterous is your coworkers reaction. this is very common Commented Jun 16, 2016 at 14:19

8 Answers 8


I very often work in such projects, and the answer is a resounding YES, and as early as possible.

People find it much easier to criticize improve some draft than to come up with a solution from scratch. So I start drafting early for two reasons:

  • Give the matter experts an impression on how the information could be presented.
  • Show my current understanding of the problem and informational structures.

In rare cases it was also nice to have some proof that I've actually delivered what we agreed on...

  • 16
    And honestly, it's so much easier to write the code if you have at least a napkin sketch sitting in front of you.
    – Kathy
    Commented Jun 15, 2016 at 21:29
  • 9
    Point 2) is terribly important if the business is not trivial!
    – bigstones
    Commented Jun 16, 2016 at 5:24
  • 4
    As someone who did UX work for 3 years, just having a sketch to talk to people (developers, clients, end users) about is incredibly useful and important. It will save you a LOT of time down the road when you don't need to completely redo the site because someone got frustrated!
    – Gnomejon
    Commented Jun 16, 2016 at 17:20

Mockups are fantastic and there is no reason a dev shouldn't do them. (It can even be handy for a dev to do a rough draft of a UI layout even when you have UI designers on the project.)

I highly recomend you don't make mockups that look like actual screens. If you share these with end users that often focus on things that don't matter like colors and themes. What I recomend you do are either create hand drawn on paper or whiteboard sketches. Or if you want them in the computer use something like Pencil Project or Visio (here are some Visio stencils from a Jonathan Abbett that look handdrawn.)

  • 6
    You can even hand draw overlays, dialogs etc, cut them out with scissors, and place them on top of the hand drawn main screen when the user touches a hand drawn button. Very quick to give some idea of what they find intuitive, how many buttons you're actually going to need, and so on. Commented Jun 16, 2016 at 7:25
  • That's just crazy talk... actually doing storyboarding. Way to old school for these new guys :P Commented Jun 16, 2016 at 14:47
  • 1
    "don't make mockups that look like actual screens" is a very profound insight.
    – King
    Commented Jun 17, 2016 at 5:07
  • 1
    I remember an anecdote that users would judge the completion of a project by how polished the screenshots they were presented looked. For such non-technical users who do not differentiate between presentation and functionality, keeping a sketch is very important to communicate "it is not done". Commented Jun 17, 2016 at 11:29
  • 1
    @Andrew... it's one of the things I learned back when I was mocking apps in Access and VB. You show someone something that looks like a screenshot and they expect you can ship it :) Commented Jun 17, 2016 at 14:57

Yes, absolutely.

Don't let someone else tell you how to do your job. And you are right, it's very much like doing UML for your data model. Assuming you are a developer, your job is to deliver quality software. If mockups help you do that, then that's part of your job.

Do low fidelity mockups -- don't make them look like real screens. You'll waste too much time adjusting fonts and pixels and borders, and your users will obsess over such details rather than focus on the functionality. Something like balsamiq is great for this, there are no doubt other similar tools. With mockup in hand it becomes much easier to discuss features of the project with your users and with the other members of the development team.

  • Of course as you say I'm talking about low fidelity mockups. I personally use draw.io as a super lightweight solution and for easy sharing between colleagues.
    – PentaKon
    Commented Jun 18, 2016 at 18:14

When designing "a new screen", you want to discuss the rough idea of the UI first with a user and/or your colleagues. You cannot discuss this with a user "in code" or "in UML", that simply does not work (it won't even work between programmers). And you should expect that you need to throw away your first two or three scetches, or at least rearrange the UI elements heavily.

So if you have a graphical UI design tool which lets you do this quickly, it makes sense to use it. However, if you need to code the UI elements manually, and throwing away or rearranging the UI elements takes a lots of effort, then it obviously make more sense not to "code" the UI first. It will be much more efficent to create separate mockups, either by using a graphical drawing tool, or simply by using pencil and paper.


Not necessarily. There are at least two reasons why mockups might be of little use.

First, if there are well-established industry practices regarding doing the things you are about to be doing, you can just go ahead and do exactly that. You won't be pushing forward the art of UI design, but that is just as well.

Second, your end users often don't know what is good for them, and why so. They just can't tell until they start using the program (with actual or mock data). No amount of static mockups will help with that.

With a modestly flexible web framework, for "just another UI screen, like previous N screens", you can start with a working prototype and rearrange as you go. Do a mockup and discuss with colleagues any time you are about to do something fancy.

  • Semi-true about end users not knowing what's best. But you can't even honestly say you know whats best until you see the layout and flow of the application. The biggest issue with using the UI as a mockup is the expectation you are setting. People see something and complain about the little things that don't matter or just wonder why you are taking so long on everthing else. Commented Jun 17, 2016 at 14:59
  • @MatthewWhited Do they complain about little things when you come to discuss the UI or do they complain about them when you propose to use the product to accomplish their thask at hand? I rather expect the later case would be more constructive, and this lends itself well to an in-house web application with installed base of 1. Commented Jun 18, 2016 at 6:53


I work for a small company, and I am the only "Soft" IT person. I do all requirements, design, coding, testing (though someone always validates my testing), database design etc.

NEVER CUT CORNERS ON THE DESIGN STEPS - your end users will thank you. You will thank yourself too, because you WILL end up re-working it to make the end users happy. Even if your mockup is nothing more than a hand scribbled piece of paper, it gives them an idea of what to expect. Taking 10 minutes to scribble something out can save a week's work of time (been there, done that)

It also helps you in your coding. It gives you the chance to think about what you need to do, the most efficient way to accomplish it, and any obstacles that may be in the way.

For example, you may find that "simple" report you need to create is harder than you first thought because you aren't capturing some date on table xyz. It also broadens your horizons and shows your team, superiors, or even can be used for potential future career opportunities that you do more than the bare minimum and can get outside that box of "it's not my job" (<--- seriously, DON'T be that guy, we all hate him) or it gives you a chance for additional learning.


Let's look at this in a more general way:

  • Is creating drafts a good idea?
  • Who should create the drafts?

Is creating drafts a good idea?

Creating drafts mainly provides 2 benefits. First, it provides focus, which leads to a speedup in the actual work being done. Second, it makes discussing the direction of the work before the work is complete so much simpler.

The downside of creating a draft is that it uses time. It makes little sense to spend 2 hours creating an elaborate draft for something that takes 4 hours to create.

In your case, the level of the mockup needs to take into account the estimated amount of work that goes into the project, and the benefit of the draft. Depending on these, your mockup can be anywhere between a 10 second scribble on a post-it and a fully interactive website. For very large and expensive projects it's not uncommon to have entire teams work on a draft for weeks and create drafts of their draft while doing that.

Who should create the drafts?

No need for an elaborate answer here: If you benefit from creating a draft, you create a draft. If you benefit from someone else making a draft for you, ask someone else to make a draft for you.

  • Really nice point on the importance of comparing the creation times. No point in doubling the time required just because we made drafts.
    – PentaKon
    Commented Jun 18, 2016 at 18:10

Your collegue is absolutely correct. Internal applications generally have a predefined look. Also for such applications, users are not looking for cutting-edge UI. All they want is something that works and is reasonably easy to use. Unless you plan to radically change the UI(which I will strongly advise against....for internal apps), just follow the existing look and feel. Mock-ups are great, but in your case, will only increase your pain.

  • 1
    Mockups aren't for building cutting-edge UI, they're for mocking up the layout and behaviour of a screen. In fact in most cases, they're really not that pretty. I just don't agree Commented Jun 16, 2016 at 16:17
  • 3
    I found mockups to be useful for a particular internal application I was developing. The idea wasn't to design the look or invent a new UI paradigm (as you say, this wasn't needed), but to tease out of the users what the requirements are, since a UI gives you something concrete to discuss.
    – James_pic
    Commented Jun 16, 2016 at 16:56
  • @KierenJohnstone I completely agree with you. However he himself says that "UX isn't much of a priority ". Unless he is a reasonably senior member of the team, his rewards will not match the efforts(creating mock-ups). Mock-ups are great. But not in his situation. Commented Jun 17, 2016 at 8:57
  • I don't agree - mockups are really useful in this situation - in most situations - to see how the app will work, if it makes sense, and if the requirement is understood by the developer - before the expensive part happens (writing code) Commented Jun 17, 2016 at 11:03
  • 1
    Our team is about 3 people. There is one senior member / team leader, and me and another guy who have been contracted to work on the project. The draft was mainly done to discuss the new screen over with the team leader. Also there was no predefined look since the whole point of the new screen was to improve an existing one that was a pain to use, so everything had to be re-done.
    – PentaKon
    Commented Jun 18, 2016 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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