58

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.

Community
  • 1
PentaKon
  • 611
  • 5
  • 7
  • 51
    If you don't have designers, and its not the developers job, then who is supposed to do it? The janitor, maybe? – GrandmasterB Jun 15 '16 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](https://balsamiq.com/) is a good tool for this, as is just drawing your mockup on paper or a whiteboard. – Joe Ballard Jun 15 '16 at 17:49
  • @GrandmasterB obviously do no mocks and 'design' while coding – PentaKon Jun 15 '16 at 17:59
  • @Konstantine 'design while coding': not only might this be expensive if at the end you realise that it's not at all what the users want, but you'd loose a unique opportunity to know more about your users, their needs and their expectations. – Christophe Jun 15 '16 at 18:21
  • 3
    I assume you really mean "mockup?" A "mock" is [something else](https://en.wikipedia.org/wiki/Mock_object). – Robert Harvey Jun 15 '16 at 19:24
  • Yes a UI mockup. No I'm referring to any type of testing – PentaKon Jun 15 '16 at 20:38
  • 23
    User Experience Design goes beyond making things look pretty. Programmers should be very involved with it. – JeffO Jun 15 '16 at 21:12
  • @GrandmasterB: That's one way of ensuring your Hallway Usability Testing goes well :-) And I'm sure the code will be pretty clean, as well. – yatima2975 Jun 16 '16 at 12:40
  • 2
    what is preposterous is your coworkers reaction. this is very common – Claudiu Creanga Jun 16 '16 at 14:19
  • 1
    "No designers in the project" is obviously not true. *Someone* is building the UI and that someone is the UI designer. It may not be their job title, but that person is doing the job. – Zan Lynx Jun 16 '16 at 17:04
  • Yes. Because users are visual and UI mockups will help with communication. Should prevent scope creep – Kyle Johnson Jun 16 '16 at 22:54
  • 1
    "UX isn't much of a priority since our own people will be the ones operating it." UX should be very high priority. It will directly impact the bottom line of the company if using the app makes its users less efficient or results in more mistakes. (Now, *prettiness* can be low priority, but usability definitely shouldn't be.) – jpmc26 Jun 16 '16 at 22:57
  • How come did your co-worker react so strongly? Did he want to create those mockups himself? Does he get paid by the hour to redo the programming from scratch every time there is a change to the UI? Or are you learning Adobe Photoshop so you can create those mockups? Mockups are a necessary step, even for internal software. Just don't go overboard. Use paper sketches, napkins, post it notes, or low fidelity prototyping tools. – Stephan Branczyk Jun 17 '16 at 07:27
  • I virtually always do first-pass mockups myself. If a UX designer is left completely on their own, they're very likely to come up with something that does not fit the schedule timeline, as they don't have the technical knowledge to know what's achievable and what's not. Doing mockups as a developer, and shooting back and forth with the designer from the very start, is the most efficient way to balance cost and quality, in my opinion. – Aurast Jun 17 '16 at 18:29
  • @StephanBranczyk We were contracted to do software development on the product, not UI design. That should be handled by someone else. However there is nobody else to do it and I'd rather have something to refer to while I work. – PentaKon Jun 18 '16 at 18:06
  • @Konstantine, Yes, that's no reason. Someone needs to do it. If no one else does, one of you has to. – Stephan Branczyk Jun 19 '16 at 01:03

8 Answers8

74

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

Stefan Schmiedl
  • 691
  • 6
  • 5
  • 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 Jun 15 '16 at 21:29
  • 9
    Point 2) is terribly important if the business is not trivial! – bigstones Jun 16 '16 at 05: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 Jun 16 '16 at 17:20
39

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

Matthew Whited
  • 768
  • 7
  • 9
  • 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. – RemcoGerlich Jun 16 '16 at 07:25
  • That's just crazy talk... actually doing storyboarding. Way to old school for these new guys :P – Matthew Whited Jun 16 '16 at 14:47
  • 1
    "don't make mockups that look like actual screens" is a very profound insight. – King Jun 17 '16 at 05: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". – Matthieu M. Jun 17 '16 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 :) – Matthew Whited Jun 17 '16 at 14:57
11

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.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • 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 Jun 18 '16 at 18:14
10

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
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.

Eugene Ryabtsev
  • 158
  • 5
  • 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. – Matthew Whited Jun 17 '16 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. – Eugene Ryabtsev Jun 18 '16 at 06:53
3

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.

Jon Milliken
  • 139
  • 3
2

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.

Peter
  • 3,718
  • 1
  • 12
  • 20
  • Really nice point on the importance of comparing the creation times. No point in doubling the time required just because we made drafts. – PentaKon Jun 18 '16 at 18:10
-2

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.

Kshitij Upadhyay
  • 71
  • 3
  • 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 – Kieren Johnstone Jun 16 '16 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 Jun 16 '16 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. – Kshitij Upadhyay Jun 17 '16 at 08: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) – Kieren Johnstone Jun 17 '16 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 Jun 18 '16 at 18:13