Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In some software company, who should be responsible for the UI design:
User
Designer
Manager
Boss
Depends on company size
etc.
In UI design I mean not only colors and images, but also control's layout, count, size, style, may be text user see.
In a small company, the answer is "whoever is good at it". Some of our best graphics were designed by a technical author who happened to have a flair for graphic design. Don't assume that someone has to have the right job title to do a creative job - innate talent trumps a job title any day!
Most companies have GUI experts and who design the front end. Some even have altogether different person(s) in team for interface layer programming, leading to tools like Expression which are supposed to draw a line between both jobs.
It however depends completely on company/person developing the application.
Well, UI design should be a collaborative effort. You as a developer should provide technical suggestions as you know the system from the inside. Your boss does provide the final answer, but he/she can provide a different opinion that you may not have realized.
Usually though, the business partner decides the final UI. They have have the practical experience with whatever your program is going to solve. They sometimes know for a fact what the user wants and expects from a solution. The UI would be a lot friendlier if the developer and business partner collaborated on the design.
A dedicated UI person is valuable to a development team, but several roles should have involvement in UI development. Ideally a UI person should be able to bridge between designers and programmers, so that the final design can be implemented with minimal technical problems. UI should be reviewed with programmers to make sure it can be translated to the web (or whatever platform you're working on) and with business analysts to make sure all the requirements were accurately represented. Users should also be involved in the design process, since they can provide feedback on usability. Sometimes what you think is a great UI will fall flat because users don't understand certain features. I've never had a project manager get involved in UI, but every team is different.
As far as the skills of the person developing the UI - It's not unusual to find a graphic/web designer who has development experience, so they will be able to create the designs and integrate them into the application. Depending on the project size you may have different UI roles. One project I worked on had a graphic designer, a usability / 508 expert, and a "UI integrator" (basically a front end developer). If there is no money for UI people, I guess the task would fall to a developer. I've worked with programmers who claim they "don't do UI" and they won't even touch presentation code, but I think any programmer who works on a platform that has UI needs to be able to do front end work.
This is for the User Experience Team. They should have tested a design, copy (text) and all of the other stuff well before you see the design or final layout.
Depending on the technology, the UI will be designed either by a programmer or a graphical designer or both, based on scetches of the program owner, a product manager or the end user.
It will always be the user that accepts or declines and therefore decides on a user interface. Hopefully not after shipping by just ignoring the application or solution.
Ideally, someone with formal training in interface and interaction design should be the one designing the UI. Nowadays, this is a discipline in its own right, with its basis in (graphic) design, psychology, ergonomics, communication sciences, perhaps even software engineering, etc. This does not mean that this person is the only one that deals with the user interface, as various stakeholders may have influences:
The boss may enforce some decisions based on strategic choices or financial considerations
Marketing may enforce some decisions based on product management
The customer may have peculiar wishes that he demands get implemented
The developers may have a certain style or preference
Common UI element, specific icons, logos, etc. may be designed by a graphic designer
But ultimately, it should be the UI expert that combines all these inputs and designs the UI.
Of course in practice, it depends very much on the size of the software company. A very large company can have their own department for user interface / user experience issues, whereas in a small company, the task usually goes to whoever is deemed best at it.
In any size company, you can take the chain of command and move up, to see who has the last say, and the reverse holds true for who will do it.
In an ideal world the Presentation layer is the responsibility of the analysis and design team. There are a lot of theoretical and practical uses to a UI, which a simple designer may have never been taught. That does not go to say that a designer with a brain - or experience - will not generate more than adequate results.
Bottom line: there is no right answer for a design. Even if you have a checklist of things that a good UI should include, there is always the aesthetic aspect of it, which is not really quantitative.
No better approach than trial and error. Even Google Adsense/Analytics encourages you to make multiple designs, and alternate between them while collecting statistics which are quantitative.
Given your question, I am guessing you do not work in a large company, otherwise your job description would have been well defined.
So: Stop whining and just do it!
UI design is a joint responisbility. UI Design is not just a flair for graphic design
It involves the clients, users, some with flair for graphic design and developers. You even review the UI which is done by someone other than the designer & asking stack overflow users' thoughts on a specific design brings us into the equation.
Generally, all people are responsible and one or a couple of people should be involved in the process from first contact with the client to final delivery on the system.
communication skills, flair for design (lo-fi or hi-fi), objectivity, being able to take criticism and analytical ability are all required.
The extent of applying these skills will vary by company & project size.
Graphic design flair means you could possibly get a great looking UI that is not usable.
I agree that UI design is a collaborative effort. In my experience graphic designers or user interaction experts create great mockups which ultimately get bastardized by managers and developers. If you have a UI concept that you want to get added, make sure to justify every aspect of your design.
Here is a basic idea of how the UI evolves in my MASSIVE software company.
Managers dictate a 1 or 2 sentence requirement.
Dev team develops feature
Graphic designer comes up with UI based on managers crappy description
Dev team bastardizes the graphic designers UI
Management completely changes their mind
Repeat step 2-5 at least three times
Release a Beta
Beta users and product reviewers feedback drive the final UI
Do not underestimate a good beta. You could make all the graphic or user interaction designers in the world happy; ultimately it's the consumers that buy your product.
How a UI looks should be guided by the user interface design guidelines. If your organization doesn't have guidelines lines it would be great to start on one.
The UI Guidelines ideally should be put together by a Visual designer (Theme) with help from an Interaction designer (behavior). So the answer is what colors should be there are answered by the Visual designer and what it should/ shouldn't not do by an interaction designer.
In real world all kinds of roles have a say in the interface. What we call stakeholders. From strategy guys, to marketing people, down to project management people. The nest to quite them all is to prepare guidelines that direct.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Programmers often serves as a designer of user interfaces. You could argue whether it is good or not. However, especially in small companies, it is a reality that does not change.
What do you think personally as a programmer, is it our work to design UI? Personally I think that not, especially when you are going to work on Web Applications, where they made you to design UI also.
****Correct me if I am wrong.****
In an ideal world there should be a UI designer, just as there should be a DB designer, etc.
However, this would mean that even the shortest projects run by the smallest companies would need a team of at least 3 (or more) people. Because of the cost that this would incur it's never going to happen.
On small projects you are going to have to double up job functions in fewer people. It's a fact of life.
From a pragmatic point of view I think that all programmers should have an understanding of the basics of UI design, if only to be able to spot a bad one and do something about it. I also think that programmers should have an understanding of DB design as well.
You should look on this as an extra skill set you have which will give you more options when looking for new career opportunities in the future.
A GUI designer should design user interfaces. This is a different skill set. Of course, there's no reason why you shouldn't have someone in your team capable of performing both roles well, but it is important to recognise that the roles, and skills required, are different.
Should a programmer design User
Interfaces?
Only, If you're working in a small company or freelancer - one man army with limited team-size, where you often have to wear different hats of a programmer, tester, QC and the UI designer. This would not be the case for larger companies, where teams are large and responsibilities are divided horizontally or vertically.
Personally, I prefer working on projects where I have a view of the full application stack, so, for a web app, I'd hope to work on the UI, presentation, business and persistence layers.
I like to fully develop a 'feature', rather than a layer - it makes the work feel more real; but then I'd say that I'm probably not typical in that regard.
Also, I've found on projects where the work is divided by layers that there's (necessarily) a much bigger overhead in agreeing on the interfaces between different developers work. Arguably, of course, that's a good thing, because extra up-front design can only improve things, but I found that huge amounts of time were wasted with people waiting for others, and fixing thing that broke from a seemingly innocuous change.
Of course, there is a very different skill set, so you either need good all-rounders (who are probably less good at the minute detail of individual areas), or strong leaders for each technology. But I think the payback is fewer integration issues where everyone's code works perfectly, just not all together!
Some Web Application requires some good designs, you are right at that point. Thats because there are designers. For example, I am really bad at design. A programmer should have own Design Patterns on coding :). Of course, if you have a good idea on how to design, it should be good for you. You can both write & design your UI however you want. Be pro on coding, let designers design your UI :)
Good Luck
You have answered your own question i think, i have worked in companies where i would not be doing this and also companies where i would.
If you work on line of business apps the UI may not be a top priority and therefore a programmer is usually capable of this task.
I think a programmer can design UI well given the correct training. My university had UI classes, and there are short seminars / training classes out there today that hash over the basics of good UI Design. The important thing is to know your customer well, and the real use of your website - keep in mind that this may differ from your intended use. I.E. you may have intended one type of user to use your site in a very basic way, but it turns out it has become a favorite of expert users, so the UI needs to support that.
Often times your buying customer, if you are offering "solutions" rather than "products", will dictate large portions of the interface, right or wrong, so the affect of your design expertise is limited anyway. The important skill to have here is communicating the whys of your interface, and the why not's of theirs.
Programmers, generally, design horrible UIs.
I think the ideal here is a UI designer with some programming knowledge. While they will focus on the user's experience, they'll also know how certain UI decisions may have a big impact on the underlying implementation.
It depends. In a small company, of necessity programmers will also be designing UIs, so yes, it is your job. In a larger company, there may be others on the team whose job is to design the UI, so then no, it isn't your job.
The question here isn't "should programmers be responsible for designing UIs". In some jobs they will be, in others they won't. Some programmers enjoy designing UIs and are good at it, others don't. If you personally do not like designing UIs, then you should take jobs where you are responsible solely for writing code and not designing UIs. If you are currently in a job where you are being asked to design UIs and you don't want to do that, time to talk to your boss to see if there is someone else who could do that function. Say you don't feel UI design is a strength of yours and you want the company's product to be as good as possible, therefore is there someone else who could help design the UI? If there isn't, start looking for another job that better fits your skills and inclinations.
The team I work in is very small so we are all involved with the full software lifecycle, although we do have a dedicated QA team too.
Ideally not, but it's mostly better than the client designing the UI.
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are currently starting a bigger project. What're your suggestions for best practices of workflow?
We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?
We are planning to do it in the following order:
"Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
Integrate the designs with the product prototype
Work out the rough edges together with the designer team to finalize the product
Release a beta product for the customer to test
Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?
While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.
Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.
Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.
I like your workflow. It should lead to a decent result.
A few ideas here:
Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.
Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.
If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.
I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".
Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
Based upon these design start to fill in the functionality behind the GUI
Release betas throughout the process of adding functionality to select users who can help guide future development
The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Web development is a mess.
This is because we have to interact with a lot of people.
Businness, Designers, Developpers, Leads, etc...
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
So, the question is, how do you work to make all those people understand themselves, interact together.
How could I decompose the severals steps leading to a website ?
Because a lot of enterprise sales a design at first, how could you then add the right functionnalities ?
For example, we can decompose a project like this :
Functional scopes (CRUD, Resources, ACL)
Designing the interface
Start development
Write xhtml/css according to the interface with the functionnal requirements
I may have forgotten steps, or disordered them.
EDIT :
For example, here is how I do :
I write a short overview about the project, what is the main goal ?
I try to know which resources (users, articles, products, etc..) are involved.
I write a short CRUD list for each resources which help me to have an overview about the features
I start to design the database (with mysql Workbench for example)
That done, i try to know if there are roles and privileges to rely them with the resources
I start development (+ testing)
Then i insert xhmtml code to respect W3C & web semantic.
I start to insert visual design with CSS
So what about you ? what are you steps to be efficient ?
I would say:
Overall Site Intent
User Analysis (Determine site/application Demographics, User Groups, etc.)
Conceptual Design
Graphic Design
Functional Scope
Interface Design (Prototype, Wireframes, etc.)
Interface Mockups
Development/Unit Testing
User Acceptance Testing
...pick and choose the parts you need. Doing all of them may be overkill, but probably not if you're working on a large team with many groups giving their input. Making sure you don't miss steps gives a chance for everybody to give their input and decide on a course of action.
Web development is different from other types of software development because frequently
there aren't any users among the development personnel. For example, "users" are absent from your list of people involved.
The users exist as a notional bunch of faceless people who are out there (we hope, because that's what the business plan is predicated on). Requirements are gathered and design decisions taken on the basis of assumptions about what the putative users might like or want.
So in many ways web development more resembles opening a restaurant or launching a new political party than rolling out an ERP system.
I don't think there's actually anything unique about web-development here compared to regular software development (with the exception of seo, which is just another technical challenge). I don't think there's anything inherently more "messy" about web-development. Read through the terms in your question again - do any of the terms (excluding seo as mentioned) not apply to general software development (substitute "xhtml/css" for "frontend development")?
Personally, I think any software engineering methodology which you've found works for your team-size/work environment/colleagues/etc is applicable to web-development.
There's nothing magical about the fact that the end-product runs in a browser.
XP and Agile methodologies look at creating teams whose members have all the skills needed for the project, such as Project Manager, developer, business anylist, designer, tester etc.
Having teams means there is better comunication between everyone involed including the client.
The subject is massive so do some google searches on XP, agie, scrum, kanban.
Yup dear you are right, there are several steps in developing a dynamic website however you want to develop a static site then its easy.
the only designing is needed for it and some functionality is added by a designer like email and so on.
but if you are going to develop a dynamic website then its accomplished by these steps.
1. First you make sure about the requirement.
2. Then you decide about its interface and layout.
3. Designer designed all the Form the are needed
4. Then the developer./ programmers will add functionality on froms .
5. After Completing the coding part the project goes to Testing for erros.
6.if any error occurs then it rectified by programmer again it goes to testing this process will going on until all error has not been removed.
7. Finally the web site publishes and then hosted on a server.
A website is a mixture of a lot of skills which involves programmers, designers, seo experts, business persons, ergonomists, etc...
If you're really lucky you will have a team of talented multidisciplinarians who can take on more than one role.
That's when you tend to get the best web products.
Design by committee, which you will always get if everyone only gets to 'wear one hat', rarely produces kick-arse products.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We are looking at hiring a software development project manager. His job is going to be concerned with running multiple dedicated project teams focused on delivery of software for external customers. He will also need to provide support to our business development unit and oversee post-implementations support of the aforementioned software. What level of hands on development experience should we expect from the applicants? Successful candidate is not expected to do any coding.
Not important. We should be focused on proven project management experience in software area.
None.
Some experience, exact technology does not matter.
Heavy experience, exact technology does not matter.
Some experience involving same acronyms as we use daily over here.
Heavy experience involving same acronyms as we use daily over here.
Some experience, mostly with technologies we do not use.
Heavy experience, mostly with technologies we do not use.
This question is regarding the best level and quality of required technical experience and is not concerned with any other skills and qualifications of a software project manager. Many thanks.
As with any position, you need to assess first and foremost what skills and experience you need on the team for you to be successful. Then hire to fill the gap for the skills that you do not already have on your team.
If you already have a team with strong technical and technical leadership skills then you don't need to hire someone who is likely to compete with the people you already have. If you are missing this, you probably want to hire a technical manager with some project planning and tracking skills.
Great project managers are those that are multidisciplinary - they are most successful where they can bridge the divide between the various stakeholders and team. The primary role of the project manager is to manage risk and facilitate communication and collaboration. As a minimum, you should look for someone that has proven experience in either your industry or with the technology space that you are playing in, otherwise they will be unable to gain the respect of the rest of the team and perform their primary role.
Which brings me to something else you should consider carefully - what is your culture? For example in a previous job, we had development leads that were very strong technically and wilful. Project managers were always relegated to second chair, and pretty much ended up as glorified MS Project admin. assistants. Anyone good did not stay long. What do you need to do to allow the type of skills you want to acquire for the team to flourish?
Most of our project managers have zero technical experience, so I'm guessing the skill sets are different enough that it's not necessary. However, they have to be bright enough to grasp/learn the concepts involved in development -- just not the implementation.
That's not to say that a technical background would be a bad thing -- it could be a "nice to have". Then again, it could possibly get in the way and they could try to control the implementation.
In my experience the very best technical managers I've had had very strong technical backgrounds (and usually were a little reluctant to trade herding code for herding coders). The worst were the the ones that were merely average programmers at best and had more of a management background.
The tentative conclusion I've drawn from this is that while not all programmers are management material, all good technical managers started out as good programmers.
Note that this answer is coming more from the perspective of hiring an engineering lead. For a project manager - someone whose job is to interface between the technical people and the customer - technical acuity is probably less of a requirement.
Some technical skill would be nice, but far more important is that they understand the functional area your company exists in. So if you sell an OS, then you probably want stronger technical skills than if you're writing banking software, for example.
Go with point 1. "Not important. We should be focused on proven project management experience in software area."
Edit: (after re-reading your intro-para) Seems what you want is a product-manager, and in support you need team-leaders on the diverse teams to handle and report on the technical issues. (Also since customer-contact is involved: a little marketing experience won't hurt!)
As an aside:
You are focusing on the wrong skill-set. You want proven administrative skill; proven organizational skill; and above all: proven people skills - (s)he must be able to communicate without antagonizing or patronizing the audience. The technical staff and programming staff will have all the necessary experience in development. (S)He must be able to manage and control these staff members effectitively.
The manager has to be able to communicate with developers. This either requires a decent technical background, although not necessarily with the same technology, or enough humility to know when the developers know more about something than the manager. I've seen both work well.
I think what I'm saying is that having respect for the developers is important, and there's two paths to it: understanding what they do, or understanding that you don't understand what they do.
Answer is "4".
Heavy experience with some technology is critical. I know the mindset is "project manager does not have to understand technology, he just manages people".
Well no, PM does not manage people: he manages project that is supposed to produce some deliverable that is acceptable at least across some desired aspects (capability, performance, reliability, security, maintainability, etc). If he can't understand technology, he's lost. Of course, he does not have to be an expert in peculiar technologies used in a project: but he has to be able to filter BS away, to question programmer's estimates (we know how those go), to feel at least technical risk here or there, to be able to formulate business ramifications of particular technologies.
In some ways I think that PM's challenges re technology are even bigger than those of programmer: he has to be genuinely interested in technology, yet he can't / should not have any technology bigotry, to be actually fair towards them (what they are actually good for and what they are actually not good for).
Read "In search of stupidity" for evidence how non-technical managers drove many tech companies into the ground.
This is excellent summary by Spolsky: http://www.joelonsoftware.com/articles/Stupidity.html
Now, the small print #1: not every programmer will make a good PM, of course. In short, control freaks, toxic personalities, egomaniacs, people who are good at coding but not at negotiating, people who are good at coding but yield to pressure too easily -- will FUBR their projects.
Small print #2: It might be possible that people with very good analytical skills might make up for lack of experience with technology. I've worked with people who were excellent business process and procedure designers, who instinctively understood how UI should be organized and what the software should be doing in this particular place and why and who could detect BS quickly even when served by domain experts but who could not program if their life depended on it.
Most has been answered already, but I'll add this:
Keep the same mindset that you would have when hiring an office manager. While the technology knowledge is important, you'll find that ambition, a will to learn, coupled with a team leader attitude will get you a better manager than looking at mostly technology knowledge. Most projects have some company/industry-specific skills that are involved and a quick learner / great leader will bridge that gap quickly.