Should a developer do UI mockups if there are no designers in the project?

Question

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.

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

ALWAYS!

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.

Answer 7

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.

Answer 8

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.