Designer vs. Developer

After years of letting the business group – with input from the customer – decide how the UI of your applications look like, you finally get a proper UI designer. He has taken several courses in UI design, usability, accessibility and several other -ilities. He’s super fast with Photoshop, can crank out a ‘quick mock-up’ during your design call and you are generally very excited as a developer that at last your product, your baby, on which you’ve spent countless hours and written thousands of lines of code, will finally ‘look’ nice.

It starts off great! Your first few meetings go well with the UI designer. You are excited by the ‘look and feel’ and the ‘consistency’ and the ‘ease of use’ of your product. You actually end up saying something like this to your manager, ‘You know John, bringing in a UI designer is one of the best things to happen to our team’. That’s the first positive thing you’ve said about your team in 3 years and 9 months.

Then the application development begins.

Like Kim Kardashian’s fake marriage, your relationship with the UI designer begins to crumble. He wants a ’rounded’ drop down. You know your IDE doesn’t support that. He wants a ‘tree’ structure. You complain it’s going to be a performance hit. You talk code, he talks art. You sit in your little cubicle coding your brains out, he comes back from a week long seminar in Copenhagen to lecture you on the ‘latest trends in UI design’. It keeps getting harder and harder.

Isn’t there a middle ground?

There’s no real short answer to that question. Well, yes there is. The short answer is No!

The primary difference is that he is paid to make your product look great. You are paid to make your product work. There was only one person in this world who could put both in one package but he died of pancreatic cancer last year.

The key is patience. Developers are programmed to think ‘logically’. Designers are not. The first step is to make them understand the business. Half of them come with lofty ideas that fall flat because they are totally unsuited for your business. So making them understand the business, the key elements, and especially the limitations is a key step. Failing this, your relationship is headed for divorce.

That is the easy part. The tough part is to make them understand the limitations of the programming platform you’ve chosen. Snazzy tools cost a lot to buy (and more to maintain the license). Open source tools are generally crappy in the flair department. But as said before, the key is to be patient. Don’t expect the UI person to understand everything upon the first conflict resolution. They need to be nurtured, and the limitation you mentioned in the team meeting yesterday, you need to repeat it today and Monday and the next month as well.

On the other hand you need to understand that he’s trying to make ‘your’ ugly product look better. In the process covering up some of the obvious flaws. Give him some credit. You’ll end up being happy and sleeping peacefully.

BTW, I have not met a ‘he’ UI designer so far.

The 10 Steps To Issue Resolution

We’ve all been through this…

It’s about 3pm on a Friday. You are winding up your work, looking out the window. Traffic is moving steadily. If you got out now, you can make it home by 3:45. You could catch an early dinner and watch ‘Margin Call’.

‘Ping’. Your business guy sends you an IM, ‘You got a minute?’. You know that’s usually not a good sign.

15 minutes later you are in a conference call with your application development team, the systems guys, the DBA, the QA person and of course the business guy. After two hours you decide it’s going nowhere and you need to contact the team in India to figure out what the solution is and defer the issue until Monday. If it’s a premium customer, the issue gets resolved in the wee hours Saturday after everyone and their team is spent.

The problem is not bad software or bad QA. It’s just bad issue resolution management.

Non-technical managers generally tend to pull everyone remotely related to the project into such calls. Instead, managers and teams would be better served following a few simple steps. These are by no means the 10 commandments nor do they work in every situation.

  1. Admit there is an issue: A lot of issues can be attributed to user errors – not without reason. But when you know it’s not the user, admit the error.
  2. Move on from 1: Once the error is confirmed, resist the urge to launch into a blame game, or into a philosophical diatribe. The ‘why’ can be researched later. First it needs fixed.
  3. Get the right people: Managers, you know who they are. There are people who are killer programmers and there are others that can zoom in on an issue quickly. Times like these, get the latter.
  4. Keep the systems guys and DBAs away: At least in the beginning. Make sure the issue is not on the application side before calling them in. They’ll be updating their FB status (with not very kind words about you) if pulled them in unnecessarily.
  5. Peel! Don’t slice and dice: Peel off one layer at a time while determining the problem. Your application is layered right? If not, get ready to say your favorite prayers.
  6. Do not attempt to change the world while addressing this one problem. Other problems have a time, place and patch to be fixed. Keep it simple, quick and easy.
  7. When you’ve fixed the problem, test it. After testing it, test it again. After testing it again, test it again. After testing it again, well you get the idea.
  8. Be nice to the RM guys: Chances are you’ll need them to do an emergency production patch tonight 🙂
  9. Communication: Let the customer that found the problem know the problem is fixed and they are free to test it out. Chances are they have moved on from that end of the world problem and won’t even remember it. But they’ll appreciate that you remembered.
  10. Finally, remember to smile and move on. Nobody died!