Who should have the most input into software redesigns?

All redesign work should go through the UI/UX folks responding to the users' needs.

I strongly believe that form follows function, but without real consideration to how users will be using the software the user interface can seriously impede the actual function. Some engineers can be downright sadistic in their UI designs.

The only correct answer is "it depends."

What is changing?

Is it a UI/UX redesign? Then users and UI/UX experts.

Not user visible? Then the engineers building it.

New feature? Users and marketers but the engineers need input into the schedule/impact.

Managers if any, allocating resources and schedules are always involved.

There can be software architecture redesign, view redesign (user interface), Model redesign, ect.... In each case it really depends. Is it software architecture? Then let the software engineers make the call, is it a user interface issue? Let the designers make the call, is it a Database issue? Let the database guys handle it.

If I'd listened to what the users *said* they wanted, I'd have a pile of self-contradicting systems, dozens of near-identical hardcoded reports, and a UI with more menu items than some restaurants.

If I'd listened to marketing, the front page would have more widgets and dials than a Formula 1 car, and we'd interoperate with every possible system, dating back to the 80s, and we'd have yet more repeated systems.

As it is, I have to creatively "forget" the stuff that management insists on that serves no purpose, and half of our features end up cut because they tell the site guys one thing, and the core guys another.

Oh, and because our UI guys never *use* the site, I end up able to design a better UI than they do. We started a complete redesign of the reports system, with some rather major changes, and the comp the UI guy came up with was basically the old comp with a few more fields (ironic, as one of the biggest complaints was that there were too many fields, many of which were not always needed).

What you do is *listen* to the users, then give them what they want instead of what they say they want. Placate marketing by making one of the new features more fancy-looking, with graphs or some shit.

They may be utter idiots and other pointless, but if it can sell, it's worthwhile. Maybe it really is the marketers we should be pandering to.

that shit for the next 10 years.

with the Homer
https://www.youtube.com/watch?v=CpPuYGPcvD4 [youtube.com]

Only HP Lovecraft's Cthulhu has input. I thought it was self-evident.

Replacement of legacy h/w, s/w? That would be the engineers responsibility.
Regulatory compliance issues? Management and engineering.
Ease of use? Users, Internet whiners and UI designers.
Marketing can serve to pass user/customer requirements as they affect demand for the product. But once a need has been identified by them, its really the users who are calling for change.

There are times (I've been involved with a few) that some new technology arises (the Web in the mid '90s) which engineers are familiar with. So, as customers struggle with ancient command line interfaces, engineering can take the initiative to show them a better way to do their job. So users and management don't have the 'big picture' necessary to drive change.

I'm missing the most important option: The one with the money paying for the software.

That's the one the vendors need to court, because he has the power to put money into the till. All the others are secondary. And this is also the reason, why I like open-source software so much. The mutual back-scratching between salespeople and purchase departments is disrupted by developer doing whatever they feel useful. Sometimes for very good effects, sometimes less so.

On the programs I built and then later rebuilt (was fortunate enough to work in a place where I was able to build and maintain systems over a long period), I probably put a lot more time and research in improving systems than the users had.

If it was left up to the users they would prefer the same thing with maybe a few new entries and features, because that's all they are accustomed to, not that is bad, but its not basis for good innovation.

As the developer I knew what limitations I had when I first developed it (and maintained it) as well as a list of 'if I was able to rewrite it' pet peeves. Also I knew intimately how the system works so I also knew what processes can be expanded with new technologies and have learned better ways to solve problems I had in the past.

So user input is important - but it should be tied in with expert developer knowledge. Marketing is also a good minor factor, the first early databases I built were called Foxbase. because that what name the users saw on the DB engine startup. The later one was named WANDA, it gave it more an identity, a personality, which I think helped adoption - probably better than just calling it the "Web Database" which would probably had become its name without branding.

System APIs: Software Architects, not coding monkeys.

Feature Set and Release Schedule: Managers

UI: Users (see also "people whining about it on the interwebs") and engineers (with minor help from UI/UX "experts")

Advertising: Marketing

This is a trick question.

The users drive the software; their use defines it and their input is the most important.

However, the users are their own worst enemy. They have trouble translating the effects they want into the designs that are required in the software.

Thus I think the users need the most input, but that needs to be filtered through developers, the smart managers (1-2% on any job), and the user experience folks.

That is, if you want functional software. Users are their own worst enemy and are self-defeating; if you just want to make some bucks quickly, the marketers are the most important as they'll go flatter the users and come back with a list of buzz-words and then make sure the software has those features, even if in barely functional form. But you'll sell more product in the first cycle.

...Developers aren't the only software engineers on the team. Everyone forgets the test analysts. Input from the test team can improve design for testability considerably, making everything from unit tests to migrations and BI much more straightforward. A lot of developers tend to see testing as a sleight on their prowess and completed documentation as a tedious imposition. I have a tendency to believe that developers with that attitude typically have no prowess worth mentioning.

Yes, I'm fully aware that my discipline is infested with scammers, charlatans, and the completely inept. But there are also good testers out there who know their way practically every type of system an enterprise will deploy.

This isn't a simple question.

It depends on the purpose for the redesign. The engineers probably have the best insight into correcting code & data inefficiencies.

Many people should probably have input on usability & functionality redesign. The UI and engineering people need a deep understanding of both how the app is currently used and what the goals of the app are in order to make the flow efficient. Most people resist change that will add efficiency -- accelerators in GUIs, changing the keyboard layout to something that allows faster typing, etc. Therefore asking the users won't necessarily yield answers that really improve the app, although the users are going to find at least the most glaring process issues, and sometimes a user will have a real insight. It typically takes asking the right questions after gaining a deep understanding the purpose of the app to sort out what are legitimate improvements as opposed to personal preferences (although accommodating those can improve efficiency too). Then the testing process can reveal whether something intended to improve the process actually does so.

A business application is a lot like a shovel. It's a tool to speed up a job. Yet as simple as the shovel is there are multiple interfaces (shovel shapes). This is because some of them are more efficient for some tasks. Even after all this time we see new iterations, such as the snow shovel with the funky handle that claims to relieve back stress. So make sure that you have someone with the skill of asking the right questions about the redesign, regardless of what group that person is currently assigned to.

Who is in control would depend on why the design is being done.

Not cpu efficient, put th engineers in charge.
Not usable, put the UI people in charge (real UI people).
Not selling, put the users in charge.

Never put managers in charge. Never put marketing charge.

Are your current customers satisfied, but too small a base to turn a profit? Did your research team screw the pooch on their last market analysis? Did your engineers uncover a fatal flaw in the design? Is it a rebranding redesign or are you addressing fundamental problems?

Need more input!

I don't like the question because it's too vague.

Same code (few tweaks) but new LOOK? A GOOD UI/UX person who actually has spent time reading the millions of dollars of research done by big companies like apple, MS, motorola, nike, etc ... creates a design based on original user feedback ... and then gets feedback from a good random sample of users to tweak the new design.

New Code (Aka: Re-Engineer) - Engineers should have first dibs to create a list of current features, outdated features, new technologies, and new capabilities. They should then put their thoughts on paper with basic UI recommendations to show how new features work. THEN and only then should the UI/UX person come in to play and work with the engineers to simplify what the engineers came up with, along with original user feedback, and clean up all the ideas. THEN get the random sample of users for their thoughts on the new design.

Good luck finding a company who does all of that correctly. Most project budgets and timelines won't allow of all of the correct steps.

Users: What?
Engineers: How?
Managers : Who?

UI: What colour?
Marketers: How much?

Whingers: The above is totally wrong.