Fog Creek Software
Discussion Board




who will do the UI ?

Our small team comprises of  smart people involved in developing cool high tech software. The complete system comprises of various backend components and , of course ,  the UI !! The problem arises when every one wants to work on the challenging but valueable backend components , and no one wants to work on the UI part. Because UI , though essential for every software , is not a core skill valueable to the domain or the company. So this is not like , who will bell the cat : this would have motivated lots of wannabe heroes , myself included , to volunteer. This is more like who sweeps the floor , except that the person will have to do it , for a long time because the UI is huge. How does this kind of problem get resolved . What should be my approach . Looking for some enlighted advice from JOS readers.

joe programmer
Wednesday, September 10, 2003


I think that this is why they pay the boss the big bucks: IT's his JOB to solve this problem.

JMHO.

Matt H.
Wednesday, September 10, 2003

It's not a core skill, so maybe outsource to a company where the UI *is* a core skill?  Maybe a company with Experience Design people as well as programmers.

-=$>Dave<$=-

Dave Torok
Wednesday, September 10, 2003

I should have clarifed this first. The boss has let the dynamics of the team to solve this problem !! So the one who is daring will refuse to do the UI and get away. The meekest one , or the one who is most risk averse , will probably end up doing it. I am wondering which type should i be. How does this get resolved in other software teams without disturbing the team harmony.

joe programmer
Wednesday, September 10, 2003


Sorry to be harsh, but I find this attitude to be so backward that I wonder if you might as well not just cancel the project right now. Your chances of failure are high.

How can UI NOT be considered a core skill?? Haven't we all experienced an otherwise good product that was ruined by poor user interface? If your users are essentially uneducated in the problem domain, then, to them, it's ALL about the user interface.

Domain knowledge is also VERY pertinent to user interface design. If the domain is used to viewing information in a particular way, you'd better present it that way in your interface or your product is likely going to be a failure.

I will give your team credit for not believing they are interface experts which another common developer sin.

Ok, rant over. Now, what can you do about it?

In our shop (which I will warn you up front uses XP), user interface is a very important part of the development process. The layout/design is usually fleshed out in communal brainstorming sessions. We have basic standards for common components and templates for commonly used dialogs (such as CRUD type dialogs). The feature team that is working on the feature actually does the implementation.

So, point by point:

- Find a domain expert who doesn't mind working with your team to act as a "customer" and drive the ui design from a user perspective.

- If, as you say, the UI is huge, get yourself some rough standards so the final interface doesn't look like a mish-mash.

- Do brainstorming sessions for the interface.

- Once your architecture is fleshed out, stop cutting your application by layer. Insteadcut it by feature. Have the feature team do the interface implementation. That way the "pain" is spread out.

Good luck.

anon
Wednesday, September 10, 2003

An UI professional should design the UI.

Would you let a carpenter design your house?  If you did, it would be a box with no windows.  Why?  Because it is the easiest to build.  That's why we have architects design houses and have carpenters build them.

This is why UI professionals should design the UI and programmers should implement them.

Gary C (remove oink and 3)
Wednesday, September 10, 2003

[An UI professional should design the UI.]

Absolutely. If you have one in house.

And even a UI professional doesn't usually have the necessary domain knowledge to drive some aspects of user interface design. Which is why I basically distrust statements like "so and so should do this".

anon
Wednesday, September 10, 2003

I find this very weird.

On most of the projects that I've worked on, everyone wanted to do the UI stuff and nobody wanted to get stuck with the back-end bits and pieces.

Perhaps you have some super-cool business that means working on the back-end will make you into superstars, but I doubt if your users will really care too much if the UI doesn't do it justice.

Come on, let's get real. I've worked on a system that took measurements directly out of the main steam line of a nuclear submarine. This is a pretty cool (very hot actually) project to work on, but it was clear from the start that the clients (Royal Navy) were more interested in how the UI would work.

Perhaps it comes down to personal choice, and all of your team just happen to not like UI work. I love it, so outsource the work to me and we'll all be happy.

What is the application, if it's not too secret ? I'd love to know what's so exciting that the UI has to take a back seat.

Steve Jones (UK)
Wednesday, September 10, 2003

I think your company's biggest challenge is the possibility that everyone there has the same writing skills as you. </slam> But seriously, a good UI should be done by someone who knows what they're doing. Since you don't have that person, either hire them or outsource to a company that has them. There is no other alternative.

StickyWicket
Wednesday, September 10, 2003

I second the person who commented that it's usually the UI that people fight over.

It's the most visible part, and thus the part that gets the attention from the customers.  Working on backend stuff may be more technically exciting, but it's usually not the part that gets the acclaim.  It's also much easier to show dramatic progress when working on a user interface, and thus less stressful to meet progress deadlines.

Points to ponder.

Phibian
Wednesday, September 10, 2003

I think it's funny that the UI isn't considered challenging.  In my experience, deciphering customer/end-user is an art unto itself.

That, however, is a challenge that is not code related.  Maybe these particular programmers would prefer a challenging code problem.

With that in mind, I would suggest that plenty of challenge can come from coding the UI.  To be specific, I've found that minor changes in UI requirements can reveal significant flaws in the back-end design.  The challenge is that the UI programmer actually deals with the final nitty-gritty design issues.  Too often it's in these latter stages that earlier design decisions are revealed as adequate or not.

1/4 Ain't Bad
Wednesday, September 10, 2003

Consider this counter-intuitive approach:

http://www.nakedobjects.org/

The basis of their argument is that the behaviour of the UI is not the value add: it's the selection of entities to model. The naked objects approach is to expose the entities to the user where (s)he can work directly with them.

"The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound statement."

--Niels Bohr (Laurence J. Peter, Peter's Quotations, New York: Bantam Books, Inc., 1977, 500.)

Reginald Braithwaite-Lee
Wednesday, September 10, 2003

"I find this very weird.
On most of the projects that I've worked on, everyone wanted to do the UI stuff and nobody wanted to get stuck with the back-end bits and pieces."

Maybe they are a UNIX shop *duck* :-)

Just me (Sir to you)
Wednesday, September 10, 2003

Hate to sound harsh too, but you have answered the question already.

The one that pulls the short straw will do the UI.

I think a more interesting question and topic for discussion would have been an examination of why this UI phobia is so in your project when it is generally the other way around in other firms/projects.

Another interesting question is how to fix this given that anecdotal evidence would suggest that users perceptions are driven more by UI and gloss than the robustness of the backend. (*nix vs windows).

Tapiwa
Wednesday, September 10, 2003

UI Development needs to become a core skill in your company, even if you have a bunch of programmers who don't want to do it. Your entire application will only be as strong as the weakest part. If you UI is weak, the application will be weak, no matter how cool the back end is. It's not just an appearance issue, either. Software is a tool, and the interface to the tool is what determines how useful the tool is.  Your backend will be garbage if it has junk for a front end.

Want an example?  Most larger slotted screws can be turned with a thin coin, not just a screwdriver. But if you've ever tried to do it, you'll probably admit that the coin lacks something in utility. It's because the interface is bad; you only have a little bit to hold on to. A screwdriver, on the other hand, has a nice big handle that fits right into the palm of your hand. Which is why most people prefer the screwdriver to the coin.

So stop prancing around like a bunch of nancies and learn how to build an interface, or admit that you need to hire somebody to do it.

Clay Dowling
Wednesday, September 10, 2003

A "UI professional" is a UI designer who can't program. The best UI designers are ones who are programmers.


Wednesday, September 10, 2003

Hire a UI person and fire one of you guys.

valraven
Wednesday, September 10, 2003

"given that anecdotal evidence would suggest that users perceptions are driven more by UI and gloss than the robustness of the backend. (*nix vs windows)."

Win2k vs WinXP (aka "Win2k with frosting")

Philo

Philo
Wednesday, September 10, 2003

Step up, assert your alpha geek status.
Go to the boss; tell him "This is a big job. I am willing to take it on and do a good job. I may need some help down the road, but let me work on fleshing out a spec."
Start you specs. Talk to the sales weasels, the customer service gnomes, and customers if you can. Look at Joel's article on specifications for some help.
Do a schedule, break it up into pieces, and find resources. In other words, MANAGE THE PROJECT. If it is a huge task, get other people in the group to help. You lead the project, and they are your followers.
Now, think about your next review. What if your boss leaves and they need a replacement? Do you see where I am going with this? Show some initiative and good things will happen.

Dougwithau
Wednesday, September 10, 2003

"Step up, assert your alpha geek status..."

Your advice is all well and good assuming joe programmer has prior UI experience to draw from.  I originally came from a green screen and batch processing mainframe background.  One of the hardest technical things I had to cope with during my transition was GUI design and creation.  At the time, nobody taught UI design and I couldn't find any decent books to learn from.  The first few PC desktop applications that I wrote were butt ugly and were quickly enhanced by others.

As for why joe programmer and his teammates all want to work on the various backend components my guess is one of the following is going on:

* It pure coding baby!

* The backend is where most of their prior work experience comes from and they are all afraid of trying something new and looking bad.

* Most of them only have GUI desktop experience and are looking for something new to do that they can put it on their resume.

Joe programmer wrote, "The boss has let the dynamics of the team to solve this problem !!"

Well, don't you have a team lead or an alpha dog working on the project?  If not, you should because it sounds like your boss is not a project manager and if he/she is then he/she is a shitty one.  ;-)

One Programmer's Opinion
Wednesday, September 10, 2003

UI is not sweeping the floor.  UI is harder than back end stuff.  Why?  Because it's easier to break.  Coding for the back you can simply design by contract.  You can code defensively at all your entry points and create virtually unbreakable software.  If it breaks, it's not your fault, it's the caller's, and you can harass them into fixing their code because they're probably sitting in the next cube.  With UI, esp. GUI, if it breaks, there is no caller, only a user, and no matter what they are doing to your program, it's not their fault.  So you have to fix it.  But if you can do this task well, you will be invaluable to the team. 

Ken
Wednesday, September 10, 2003

+1 to what Ken said. UI is generally the harder and larger task. It not only takes someone who has great attention to detail, but generally also needs that person (or team) to have good aesthetic sense and usability sense.

In my experience, very few engineers make good UIs. Most of them make Medusa UIs. :-p

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, September 10, 2003

If don't seek out the advice and/or services of a User Interaction Design company you may well end up with something like this:

http://www.franklins.net/badui2.jpg

instead of something like this:

http://www.sapdesignguild.org/editions/philosophy_articles/images/SAP_B2B.gif

UI Designer
Wednesday, September 10, 2003

UI Designer, I hate to be argumentative (ok, i don't) but the "bad" ui example might very well be better than the "good". The good one is much easier on the eyes, but it might do strange things or be hiding key information in one of the tabs. As complicated as the first one is, if it works as it looks like it should, all of the fields are required, matches the way the user expects it to work, it might actually be a good UI.

pdq
Wednesday, September 10, 2003

I'll second that: the second form has a variety of problems similar to those in the first one.  It's much prettier, but it has weird usages of controls, outputs physically separated from the primary data (look at the weird highlighting scheme), and other flaws that the first one has, from a usability perspective.  I don't think I'd want to use either one, and I definitely wouldn't want to have to train somebody how to use them.

Phillip J. Eby
Wednesday, September 10, 2003

It's impossible to tell from a simple screenshot whether a UI is good or not; the only true test is regular use.  You're right to say that there might be problems with the "good" UI.  But if so, they're hidden and not immediately obvious; but the "bad" UI violates every rule of UI design in the book, starting from using an outrageous numbers of colors, wildly varying button, input, and font styles, the frequent use of cryptic abbreviations, too many controls all on one page, and a complete lack of layout spacing and gridlines.

The "good" UI have a good number of hidden flaws to even compare with the "bad" UI's obvious ones.

Alyosha`
Wednesday, September 10, 2003

You say: ...nobody wants to do a UI...

I and thousands of under/unemployeed programmers will beg and plead with you: HIRE ME! HIRE ME! HIRE ME!

I will even wash your car everyweek, if it gets me the job...

I will even write documentation.

...and do power point presentations for the sales dept.  ...Well, then again, I would rather sell coffee at Starbucks. Lots of perks..

--
ee

eclectic_echidna
Wednesday, September 10, 2003

I third it.  There's a big difference between aesthetics and usability. 

For example, locate the order total and customer address on each, or figure out how to move through the order records in sequence on each.  These seem like fairly basic things, but I don't see any of them on the pretty one.  Also, it appears that the "bad" one supports drop-downs on the item type and description whereas the pretty one either requires you to type these in or supports some other method that isn't obvious.

The apparent flaws on the "bad" one might not be flaws depending on how this application needs to be used.  I imagine an application like this might be used by people who aren't sitting in a chair and focusing on only the PC.  If you need quick acquisition of information, it's pretty easy to look for the teal, or look for the light blue, or look for the red buttons.  If you need frequent access to all of the items displayed, it would probably be annoying to have to go through tabs to get to them (once again, the person using this might be glancing at the screen rather than holding on to the mouse).  Obviously this UI is designed for a very specific use so the cryptic abbreviations aren't too bad.  I'd rather have something like ActWt as a column name than to have a column that needs to be wide enough to fit "Actual Weight" or truncated to "Act...".

SomeBody
Wednesday, September 10, 2003

UI Designer,

Nice post, but I think this an unfair comparison. 

The first screenshot looks like some lone wolf programmer created it using Microsoft Access or VB.  The second screenshot is taken from a commercial application.  I am pretty confident that ERP giant SAP has a lot more cash and resources at its disposal than the lone wolf programmer and his unknown client does.  My guess is the unknown client was probably cash poor and hired whomever was the cheapest.

One Programmer's Opinion
Wednesday, September 10, 2003

The single screenshot comparison was intended to illustrate the kind of work that we interaction designers can perform. As someone mentioned, it is impossible to tell how effective either one is without knowing more about the users and their goals. Maybe the first one was designed for a single user in a shipping dept - but what happens if the guy calls in sick one day and the temp from the agency can't figure it out to do todays shipping?

Some disclosure: The second screen was designed by Alan Coopers' company in collaboration with SAP for their B2B initiative. Read all about it at
http://www.sapdesignguild.org/editions/philosophy_articles/cooper.asp

No, I am not connected with Cooper in any way. I've no idea who did the first one.

UI Designer
Thursday, September 11, 2003

Anybody with a bit of experience can maintain and even enhance a GUI (say adding a Tab), but it is tougher to understand/maintain the backend of a reasonably complicated distributed system even it is well documented.

So guess what people want to write...

ignatius
Thursday, September 11, 2003

"Anybody with a bit of experience can maintain and even enhance a GUI (say adding a Tab)"

This is what everyone *thinks*. They're wrong.

If you have the luxury of contact with your user base, then iterative UI design takes a lot of politics, expertise, and patience. Lots and lots and lots of patience.

Let's take, for example, my old friend the autonumber. Put one on a form. Now welcome to "why are there gaps in the numbers" hell.

Philo

Philo
Thursday, September 11, 2003

It takes a good developer/designer to *take away* a tab - and an absolutely brilliant one to design an interface that

(a) has no tabs, because
(b) it has everything the user wants right in front of them - and nothing they don't want there at all.

LesC
Thursday, September 11, 2003

[It takes a good developer/designer to *take away* a tab - and an absolutely brilliant one to design an interface that
(a) has no tabs, because
(b) it has everything the user wants right in front of them - and nothing they don't want there at all. ]

Ding! Ding! Ding! We have a winner!

Absolutely. So many of the funky widgets developers love to use in an interface are really only there as a last resort. Using them is an admission you couldn't figure out a better way to organize the information in the interface.

anon
Thursday, September 11, 2003

Are UI developers important ? Yes .
Are they more important than the core domain skilled guys ? No.
Guess who is valueable to a database company like Oracle . The database experts of course.
Who is valueable to a networking company like Cisco.
The network guys i guess.
Does that explain why everybody wants to pick up the core domain skills ? UI might be the most important to the user . But that is for the manger responsible for the whole product to worry about. For programmers trying to become more valueable to their company , GUI skill is a secondary skill.
What is more difficult and challenging ? Putting widgets on a form , or developing a high performance,  fault-tolerant , multi - threaded backend with all the cool algorithms .

joe programmer
Thursday, September 11, 2003

Looking at the screenshots that UI Designer linked to - the first looked (in organization) a lot like the UI the customer service people (i.e. order takers) used at a company I worked at (except it was a green-screen AS/400 app).

When I first saw it, I thought it was one of the worst screens that I'd ever seen - then I talked to the users. The Customer Service people loved it, it presented almost everything they needed on a single screen - they didn't have to wait for information while changing screens or use multiple screens when entering information.

I talked to the guy that did the initial design and he said that he based it on the same concepts as the airlines did for their reservation screens. Those screens are even more complex with few labels and lots of cryptic abbreviations - but it works for them.

The same company decided to migrate to SAP and, when the Customer Service people where shown the multiple screens (with tabs) that they'd have to use, they nearly rebelled. It was only when the IS department agreed to build an add-on that gave them back the functionality of their original single-screen that they agreed to go to SAP.

RocketJeff
Thursday, September 11, 2003

".. I should have clarifed this first. The boss has let the dynamics of the team to solve this problem !! So the one who is daring will refuse to do the UI and get away. The meekest one , or the one who is most risk averse , will probably end up doing it. I am wondering which type should i be. How does this get resolved in other software teams without disturbing the team harmony.  .."

So your boss weaseled out. It was his decision to make and he fluffed it. He could have made some clever decisions on how to handle the UI dirty work.

UI work under such an environment (a place that doesn't care about UI) is *not* risk averse. Any bug that leaks up from the back end modules is your bug until you prove otherwise. You also learn precious little - it is bad for your career and skill development. UI coders get all of the stupid change requests, the little tweaks that turn your code on its head, and you get no respect for your effort from superiours.

What I would do: the UI 'Janitor' gets to pull rank. He can dictate the quality criteria and interface standards for any UI work that he must do for a backend component. Backend components must not squelch errors. Back end developers are not more elite than the UI grunt. Back end developer needs to understand the UI code being created for him to the point that he can take it over and maintain it later.

UI coder gets rotated out after 6 months, at any point in time there should be a supporting UI coder who will be able to take over.

Finally fix the mentality of UI work being somehow filthy.

Richard
Thursday, September 11, 2003

---Are they more important than the core domain skilled guys ? No.
Guess who is valueable to a database company like Oracle . The database experts of course.
Who is valueable to a networking company like Cisco.
The network guys i guess. ---


bzzzzt.  The salespeople, is the correct answer.

dead horse
Thursday, September 11, 2003

[What is more difficult and challenging ? Putting widgets on a form , or developing a high performance,  fault-tolerant , multi - threaded backend with all the cool algorithms . ]

That's easy. The UI is FAR more difficult and challenging.

To write the backend you just have to make sure you have your sh*t together. To write the UI you have to get inside the brain of your intended user.

anon
Thursday, September 11, 2003

[Does that explain why everybody wants to pick up the core domain skills ? UI might be the most important to the user . But that is for the manger responsible for the whole product to worry about. For programmers trying to become more valueable to their company , GUI skill is a secondary skill. ]

Please, please, please let my mutual funds not have any stock in your company.  You guys aren't long for this world.

anon
Thursday, September 11, 2003

"Guess who is valueable to a database company like Oracle . The database experts of course."

Joe, right now Oracle is losing market share hand over fist. Why? Because Microsoft's database guys are as good as Oracle's, and their GUI guys kick Oracle's ass.

Philo

Philo
Thursday, September 11, 2003

>> fix the mentality of UI work being somehow filthy

Amen. I *hate* (in a figurative way) geeks who label some technical activity demeaning or lowly. They usually transfer this bias off on whomever has to do that work. Very unprofessional and immature.

I was saddled in this way years ago. I worked at a company that did computer communications software. I was tasked with developing a printer utility to handle and batch and queue incoming print jobs - for DOS.

Harder than f***ing hell to develop, and I was also painted the schmuck of the department because of a "eewww, printers!" attitude. The "glamor boys" who did the terminal emulator (and who lacked the real-time skills that I possessed to get things right in that area w/o a lot of hacking) did much better politically.

This kind of attitude is childish and unprofessional. The management of this company sounds completely screwed up and is probably stuck in a headuptheass "engineering is God" mentality. I second the notion that they deserve to fail...

Bored Bystander
Thursday, September 11, 2003

"Let's take, for example, my old friend the autonumber. Put one on a form. Now welcome to "why are there gaps in the numbers" hell."

Philo: just tell them that you'll change it when it looks like the system will run out of numbers ... =-)

Alyosha`
Thursday, September 11, 2003

A professional?

The UI *is* the program in the user's eyes.

Would Ford sell many cars if the engineering was fantastic, but you had to sit on a orange crate? The car is the comfort of the interior, the body styling... I could go on.  Nobody has every said to me 'bloody awful to drive, but the engine is sooo well built!'...

Programs are the same - the neatest most brilliant engineering will be ignored if the user was expecting to see the button bottom centered, but you've put the thing top right.

Hope you weren't planning to sell this software.

Raddy Echt
Friday, September 12, 2003

It absolutely blows my mind that you've built all the backend stuff without a UI.  In nearly every project I've worked on, the UI prototype was the very first thing built.  The reason why is simple.  It's the easiest way to find out what's wrong with your requirements spec.  When you have a UI prototype, you can sit down with the end users and walk through the workflow and they can tell you, "That's not going to work because what I really need to do is XYZ."  You learn about all the little things that absolutely have to be done but that nobody mentioned before because they're so fundamental to the process that it was inconceivable that you could possibly not know about them.  Note that this will fail miserably if you are demonstrating the interface for the suits that commissioned the system to be built rather than the real end users.  You should get their perspective too, but not to the exclusion of the perspective obtained from the people who are going to use the software daily.

Back to the question at hand, since everyone in your development team truly dreads doing UI design, it would be a terrible mistake to have any of them do it for the following reasons:

1) People don't tend to do a good job working on projects that they hate and you'll likely end up with a miserable front end on an otherwise solid piece of software.
2) You risk losing good talent in the long run.  The guy/gal that gets stuck with this task isn't going to like it.  When the economy picks up again and everybody in the biz is hiring, they may decide the grass is greener elsewhere.
3) Your developers are experts at writing code, not UI design.  You don't have your accountant design the company webpage, do you?  Then why would you have a novice build your UI?
4) Because of economic circumstances, you, right now, have the opportunity to hire some brilliantly talented, smart, experienced UI designer who recently joined the unemployment line for no greater reason than having had the bad luck to be working for the wrong company at the wrong time.

Matt Latourette
Friday, September 12, 2003

Matt, I agree with you and would add that if the prototype is done using paper and/or whiteboards the process will go a whole lot faster. This is NOT the same as sketching out a few diagrams of what you think the UI should look like and then go ahead and build it. You absolutely must involve real, actual users, incorporate their feedback and iterate, iterate, iterate.

In her book 'Designing from both sides of the screen', Ellen Issacs points out that "The UI is very much part of the functionality of the application, so you need to know what it is before designing the architecture to support that functionality".

UI Designer
Saturday, September 13, 2003

*  Recent Topics

*  Fog Creek Home