|
A bit similar in our case. For the UI, the developer does it. When it comes to graphics, icons, ... our technical writer becomes the expert as he has some talents there.
|
|
|
|
|
Sometimes they propose designs that are very expensive to develop so developers' input is also required, but I am very happy I don't have to design icons or pick colors
|
|
|
|
|
Hi there
in all organization there is either UI Designer or the developer/programmer itself design the UI
but believe really it needs a Good environment, Good thinking
because user/client don't see what u code but see what u design and how it looks ??
the design/UI shows the Quality of our product...
so i think it is much difficult task....
cheers for UI Designer...
No doubt the applicaiton is TEAM WORK in which all Designer/Progrmmer/QC's and all releated person make good contribute.
- regards
If the message is useful for U then please Rate This message...
Be a good listener...Because Opprtunity knoughts softly...N-Joy
|
|
|
|
|
and UI design is a big difference job to graphic and skin design. It shows the way how a product and user will interact
|
|
|
|
|
... and it's me. Whenever we're redesigning part of our web application, I bring in my MacBook Pro with Adobe Photoshop and I do everything myself. We used to have a graphics design person here years ago, but they were laid off... and the position was never filled.
|
|
|
|
|
When a new project arises, I employ what I hope is a common practice, by meeting with the users. The ultimate outcome of this is that I created a two-page manual (for managers) on 'how to specify software.'
One the key notions I attempt to convey is to not specify what you want, but what you need. Pretty much giving the blank-check of application design is much like giving yelling free beer at a frat party. They cannot help but over indulge.
Once the basic requirements are specified by the group's manager (or some other allegedly responsible party), I go into their trenches so that I can design a GUI that actually follows the work flow of real users. In addition, many of the apps are stared at all day by the hapless users, so I try to make it eye-friendly (both by color choices and larger fonts). Rarely a consideration from the customer side.
The above is by no means a display of any particularly enlightenment, but rather a consequence of the same path of live-and-learn that many, or even most, of us have trod. With yet another one of my broad sweeping statements, I think it's safe to say that users don't really know what they want - so it becomes an unwritten part of our job description to do it for them.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
Balboos wrote: I created a two-page manual
Now theres an article I would love to read.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
even me
|
|
|
|
|
Here's a Draft I Found - converted so it's readable as a post.
Feel free to pirate or pan.
<big>SOFTWARE SPECIFICATION AND DESIGN CONSUMER CONSIDERATIONS</big><br />
S. Miller - First Draft: June 6, 2007, Second Draft: June 11, 2007<br />
<br />
Converting the software needs of the consumer into an effective application is, as many of you have experienced, not without its difficulties. These arise from a number of causes. Amongst the commonest of these causes which both parties typically finger-point is that the users and developers have different understandings of the entire computer experience, and apparently don’t speak the same language. That particular issue is not the one to be address here.<br />
<br />
Given carte-blanche for their software requirements, a user must give very careful consideration as to what their minimum requirements really are. To take an extreme example, a specification such as "I need an application to enter my data" doesn’t help at all in design. Going to the other extreme, and specifying an entry option for every piece of data that is generated by their work flow will, if implemented, generally come back to bite all involved.<br />
<br />
Both of these extremes scenarios, if brought to life, result in unusable software and a long, arduous, and frankly aggravating cycle of modifications . . . or even software that never gets used at all.<br />
<br />
The key to avoiding this is giving a long hard think about what it is you really need to do – not simply what you have always done. To merely translate your manual tasks (or older applications) into a new version of the same fails to take advantage of the value-added potential of custom-designed software.<br />
<br />
The following items ought to be given some consideration:<br />
<br />
The Medium:<br />
Although you me be comfortable, at present, with a certain style of input design (such as a spread-sheet), it may have only been initially chosen as an ad-hoc solution, or perhaps because it was the only game in town at the time. At ATIC, the developers are rather well equipped to create exactly what is needed for any job.<br />
<br />
Work Flow:<br />
How can an application most smoothly match your true work-flow? Try to take into account, as best you can, not only the perfect scenario, but how you’ll handle the most common errors. <br />
<br />
Exceptions:<br />
We all make mistakes. Some of these can be preempted with the software design, such as by using lists instead of type-in-text, for data entry. "Imaginative" data is prevented – but at the cost of flexibility.<br />
<br />
Data Selection:<br />
"What data do you want to collect?" vs. "What do you need to collect?" This must take into account that someone has to actually enter this data. The programmer slugs through a ton of entry fields just once: you’ll have to do it all day, and every day.<br />
<br />
User Interface:<br />
An application should be eye-friendly. By now, most of you have worked with applications which do it all in one place – and boast a small enough font to prove it. Can your work be broken down into discreet segments, instead, which could be put on separate "tabs"? Can these be arranged so the user can reach one or more stopping points (i.e., valid times to Save current work) along the way, reflecting their workflow? Breaking down their unit of work to more easily digestible bites further allows for future division of labor when appropriate, or clean modifications to a specific work unit without impacting any of the others.<br />
<br />
Freedom:<br />
You should consider carefully how to seek a balance between flexibility, and the opportunities flexibility affords for ambiguity and user-errors. What data must be entered, at a minimum prior to any type of save?<br />
<br />
Audit Trail:<br />
All work, particularly in a business such as ours, should maintain a chain of custody. Normally, a programmer will create some degree of this via data logging. This, however, can be their viewpoint of best practices for data management and rather hit-and-miss as to whether it meets your needs. <br />
<br />
<br />
The above criteria, naturally, have varying degrees of applicability for your specific needs. Their importance lies in getting you to think about what it will be like actually working with your new application. Like swimming, simply writing about how you think it’s done will likely result in a future drowning.<br />
<br />
The goal, however elusive, is getting it right the first time.<br />
<br />
Sure – there is almost certainly going to be a short cycle of adjustment – but it can be reduced to a pleasant tune-up, and, after a break-in period, some tweaks.<br />
<br />
If you take into account the developer’s time, and even more so, the user-training cycle, born with the introduction of new software, it can be a costly enterprise. It is done because, when done well, your work is easier and the product of is better – and all agree it is worthwhile.<br />
<br />
<br />
There’s a wise philosophy that seems to apply:<br />
If you can’t find time to do it right the first time,
How are you going to find time to do it again?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"As far as we know, our computer has never had an undetected error." - Weisert
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
I still reckon you should turn it into an article (without having read it yet). I'll probably leave this lying around in a number of strategic places. Thanks.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I work with an in-house graphical designer. The results are awesome! We are good at coding but that doesn't mean that we are good combining colors, etc. I invite you all to visit our web site (www.berex.com.ar) and take a look at the products section. This is not a showcase, it's just to show you the difference between a UI designed by coders and a UI designed by a graphical designer. I must warn you, the page is in Spanish because we are from Argentina.
|
|
|
|
|
I don't dispute the value of a designer doing a professional job, but you are working on a public facing solution and therefore you SHOULD have a designer, I do dispute that a designer is required for in house apps.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Those numbers don't surprise me in the least, the only place I could justify a designer is if the application was public facing or a commercial product.
When internal apps (winforms/WPF) need a designer to finish them off is when we are all in trouble, the barbarians (marketing) will be at the gate.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Here almost all projects are treated as "code-for-hire" projects. Our IT stance is to treat all other departments as paying customers. (Which they technically are, considering how budgeting works.)
That being said, I didn't answer the poll, because around here it's on a project-by-project basis. We have a group that does UI design (they did on my last project), but on my current project the UI design is being done by a WPF developer on the project team.
Grim
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
(0 row(s) affected)
|
|
|
|
|
Grimolfr wrote: other departments as paying customers
As do most IT shops, but to you it is all about the data, to a commercial shop it is often all about the presentation. So considering 40%- have designers available then that probably represents the % of commercial vs internal people here. And yes there is always the aberrant that has a designer for in house work.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
"the barbarians (marketing)" -> LOL
GSoC 2009 student for SMW!
---
My little forums: http://code.bn2vs.com
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|