Figure out what problem you are trying to solve first. Seeing where the different users are failing would be a good place to start that. Once you understand the problem, you will have a better sense how complex it might be to solve. This will help guide you on whether you should a)tweak the existing features or b)design a solution that solves the overall user scenario (regardless of whatever you have right now) Keep in mind that if you go down path (b) consider if users have grown accustomed to the bad way and the switching cost of going to the new solution.

You say "time is tight" but you cannot blame that on an Agile methodology. Agile merely means that you have to break your Big Design into pieces or deliverables that are sprint-sized or iteration-sized (or whatever your Agile team calls its work period). It can take a little getting used to, delivering a big design in pieces. You also have to show some trust in your iteration coordinator or development manager; When they say "we'll do this piece now, and that piece next iteration," and so on, accept it and work with the team to help them meet their Agile goal: some working software at the end of each sprint or iteration.

Work with them implies give and take. It does your users no good if Agile developers wag the dog, any more than users would benefit if Waterfall developers wag the dog. That's because making good software takes input from a number of the following disciplines: product management or business analysis, customer involvement, user-experience design and usability analysis, quality assurance, technical communication, marketing, plus the various flavours of development, from architecture to code-monkey programming. I've probably overlooked one or two disciplines.

Take heart! With so many disciplines on a project, you're bound to have some allies. Find them and use them, to benefit the product's customers and users, and your portfolio. ;)

I can hardly believe that there is a general answer to your question. It depends.

Sometimes the feature is designed so terrible and the fix is so obvious that you really don't need testing. But keep in mind the complexity of work needed to implement your fix (how much time will developers need to implement your new design?). And sometimes a simple usability research may give you clues to find a better elegant solution.

If there is doubt you may also show your ideas to some experts (or even just experienced colleagues) - it is probably the fastest way to recieve useful feedback.

Personally i wouldn't start from scratch, although i would keep the big picture in mind. Essentially this has more to do with development process then UX design.

The problem from a development stance is that if you start from scratch there is the likely hood that you will miss some aspect of the feature that is essential but not obvious. This will lead to frustration, much refactoring and could compromise the solution and the overall user experience.

As you're working in an agile methodology could you phase the implementation of the ideal solution across multiple development periods.

This would keep the core code intact but would evolve the user experience closer to what you would really like to see. It also give you the change to test the solution as it's delivered to see if you initial idea matches the user's expectation.

Matt

If you don't know what is wrong with it and all customers have problems with it I would suggest you start from scratch and make sure that you are prepared to measure.

Hi Janel,

I think with so many constraints and requirements, it may be best to take the long term approach and defer "starting from scratch", although I understand things would be better off if everyone took a step back to assess the real situation.

When I'm in a situation like this, I usually observe the following in order to determine the best approach:

1. Politics/Power

I usually try to understand where the requirement is coming from, who is in control of executing that, who made the request, and why that request is necessary. Many times, features are introduced with good intentions, and it's also the UX person's job to understand that over and above the user's needs. Knowing the source of this helps me to understand what is at stake, and how I should communicate the best approach to the appropriate stakeholders.

1. Technical and Time Constraints

The main unmovables involve a balance between time and technical constraints. There is also an element of the dev team's preference on how they want to design and implement the solution. With two sides - e.g. marketing/sales and dev/design, it can already get messy, not to mention getting another side involved (UX).

1. Users

This is one area I struggle a lot because I don't have that as much experience working with users, and certainly non-UX people will have all sorts of questions like why? how? should we even talk to users? etc. In my experience, while it's valuable to speak to users, getting that data to convince my team to change is another ballgame.

The combination of these three factors are really what's at stake when any implementation is introduced, and whenever I have a desire to get devs/sales/marketing/etc. to "do it differently". I find that if I can't resolve these three main areas, I'd be better off doing something smaller and to take smaller steps to work towards addressing these three areas.