I've recently been challenged with a very hefty redesign for a major financial tool. Most everything about this application is a mess. (They've been building it for the last 10 years, and I'm the first designer they've hired.)

The logic is very complex, nothing is organized, and nothing is standardized. There are so many problems to fix, it's hard picking the worst one. (There's no help system, no navigation system, and there are a TON of ugly/unusable forms.)

So, my question is this: for large / complex redesigns, where do you start? Any useful tips for planning a major redesign?


Edit: For my specific case, end users are out of my reach. (I work in banking -- security issues...) I'd prefer to keep answers general, but it would also be helpful to touch on what you guys would do if you couldn't access users directly. Also, this is a back end system -- not a consumer facing website. It's only used by high-profile companies / bank account managers.

  • 1
    I'm not sure if one designer alone is able to manage this. I'd recommend to look for "allies" among the development team. Are there anyone except for coders? It can be hard to argument alone against a group of "we always did it that way". Commented Sep 6, 2012 at 14:09
  • Do they understand the value of a good UX or do you still need to sell this? What did they ask you to do? An entire redesign or just make it a bit nicer? Do you have insights into the business numbers, like what area/product is successful or not? Commented Sep 6, 2012 at 14:15
  • agree with @AlexejFroehlich you need to get people on board. You won't have all the answers.
    – Wander
    Commented Sep 6, 2012 at 14:20
  • Would you consider the users 'expert'? as in they spend a large amount of time using the tool?
    – Wander
    Commented Sep 6, 2012 at 14:25
  • Everyone here is pretty on board with the UX redesign. Everyone here is support. (All the coding is done offshore...) I've been talking with staff to get a sense of what's valuable, but unfortunately numbers are out of my reach. Some users are experts, others very beginner. There are about 15 major personas I've found and about 10 minor ones. Commented Sep 6, 2012 at 15:30

8 Answers 8


In my primary day job such projects are usual. And they are really the mess, and the experience is worth a book :) But I'll try to be short.

At first accept in your mind that huge projects can't be perfect when you are alone warrior struggling. This will save your spirit from depression and months of nightmares with ugly controls and prototypes (I had). But you can make it a lot better.

Then try to get as much information about subject of matter as possible. Read books, ask experts and so on. For some projects it took more than month of immersion. Parallely, try to understand how the application works, sometimes even non-task-based documentation can give info about application tasks. Try to read between lines — why it was implemented? which goals it helps to reach?.

Write every supposition. Try to organize all your thoughts to structure and discuss it with participants. Tech support usually can tell you a lot — not in direct way (all feedback will require interpretation), but you may get info about user's requests and reclamations.

Usually huge projects suffer in taxonomy, integrity and local (concrete interfaces) solutions. This is where you can do a lot even without information about priorities and conceptual disadvantages of the system. So recombine, unify all interfaces, make simple solutions, hide all complex and individual solutions. It is possible to make concrete form implementation and navigation model better and simpler.

Also it is very important to make good relations with the team. If they are good enough, you may ask sales (or tech support) department to send to clients short questionaire with open questions about application.

One important feature of huge professional projects is that they are function-based, not scenario-based. It is normal — MS Word is used by almost all users— and it is not possible to find personas and scenarios for all groups of them. And MS Word is not bad (but not ideal). So most of your attention should be payed to make any task as easy and automative, as possible, and navigation through all functions — as obvious as possible. But it doesn't mean that there are no vital scenarios — try to search for them and you'll find them. But don't try to describe every – it is unreal.

Pay attention to competitor projects if they exist. If there are no subject matter straight competitors — there always do exist unobvious analogues similar in complexity and approach.

So, in sum, be detective — research unobvious, make suppositions, simplify & unify — and iterate, iterate, iterate.

  • Awesome -- thanks for the advice. It's so good to hear that I'm not the only one! Commented Sep 6, 2012 at 17:08
  • 1
    +1 for "One important feature of huge professional projects is that they are function-based, not scenario-based."
    – Wander
    Commented Sep 7, 2012 at 8:20

If possible, start with user research. Develop personas, scenarios and other artifacts first. This will help you discover which areas are the highest prioirty.

Take a look at About Face 3 by Cooper et al. (ISBN 0-4700-8411-1) Cooper's Goal Directed design works pretty well to tackle user interaction and design projects.

Also, take a look at "process" on the IxD forums, here on ux.se, and on sites like UIE Brain Sparks.


Before you start to work on a solution, you need to fully understand the system and truly what the issues are. There will be users with years of experience it would be worth getting their input. I would take some time to immerse yourself in the program. Perhaps get someone to give you some scenarios?

I would recommend you create a survey which a large amount of users can complete easily. Look for patterns in the results. You could do more specific usability testing too. Do a heuristic evaluation of the current system, both from a page level and flow level. Try to establish use cases and types of users. From there I would create some personas and design around these.

You may find you actually have to changes incrementally, by the sounds of it you won't be able to just release a new version that is totally different, it doesn't work like that.

  • Thanks -- good call on the survey. I think I'll try that. And yes, It'll probably be an incremental release over the next couple years. Commented Sep 6, 2012 at 15:37

Is it possible to redesign in smaller chunks. Rather than risking everything on one large redesign pick off the a quick win and get some runs on the board.

It is always critical to start getting some runs on the board. If you can start showing some value being returned to the business you may be able to start pushing for extra resources and even the hallowed ground of user testing!

I understand you don't have access to users at present but if you can start showing progress you may be able to soften the ground.

It will be critical to evaluate each chunk being redesigned and weighup it's value in a business sense and a user sense. The only wayto really ascertain user value is by knowing your users.

  • Thanks Corbijn, that's basically the approach I've taken. Showing value is important -- I think this is good advice. +1 Commented Sep 13, 2012 at 13:22
  • It can be hard being a "team" of one, but always keeping an eye on value can certainly help build support. Good luck!
    – corbijn
    Commented Sep 14, 2012 at 10:44

Agree with the rest of the answers. One benefit you have with redesign is that you have and existing user base you can work with to figure out what user needs are, what they like/hate in the current system.

We worked on a big redesign project and started with interviews and observing users using existing system. Observations were extremely useful since it gives you a true picture of how users address a problem. Observation allows you to find opportunities for design improvements and shows you things that would be hard to get from interviews ( e.g. users were copying information from our site and pasted it in another system; we learned that our site should support easy copying).

After you do the research you can create a list of task that users need to accomplish using the system. Then you and your team can priorities the list and tackle what you believe will give you the biggest ux wins.

  • I totally agree with your answer, but unfortunately I can't access my end users for security reasons... (I made an edit that points this out.) How would you suggest I go about this without actually talking with users? Commented Sep 6, 2012 at 15:44
  • Do you gather any usage statistics? Are there any logs? That could give you ideas which features are used by users and how often. If you have any tech support employees that worked with the users you may want to talk to them to gain some knowledge. Commented Sep 6, 2012 at 17:15
  • Unfortunately, nothing has been logged. I would love some usage data, but nothing is in place to track it... And yes, I'm talking with them now.. Commented Sep 6, 2012 at 17:16

I guess your only problem is big system and no one to talk to.

  • Create a list of big screens
  • One screen at a time, I would break it down into 3 parts (Information, Input and Interaction). Make small post-it notes. Top left corner screen it came from, Top right corner categorize it as Input/Information/Interaction (or use different color post-it's)
  • I would collect all the Information, Input and Interaction from all the screens.
  • Study the post-it's that I dont understand a bit more

While you do this exercise, you will just understand the entire system. If you get more out of this exercise, then good :). But invest 1 hour atleast on this undisturbed. Drink a lot of water and the more you try to club post-it's together to form your new screen the better. Find different combinations of new screens that you can build.

Since its complex, just focus on understanding the system. Ask questions, discuss, make sure that the person who is answering your questions is being helpful, not taking it personally and crying like a baby :). Talk to 1 person at a time.


How is talking with them a security issue? I can understand not being able to shoulder surf when they're using it with real data, but not being able to talk to/email them is a recipe for disaster. The odds of being able to get requirements good enough that your redesign doesn't end up breaking one or more typical work flows without any communication is near zero.

If it truly is impossible for you to communicate with users I'd strongly advise against making any changes that remove data on forms or navigation routes between them. Make the styling consistent, fix layout problems, add a new navigation system on top of whatever the current ad-hock mess is; but trying to do anything more will end up blowing up in your face eventually.

  • 1
    Talking with a user is not an ideal way improve UX. Far superior is to watch users. Watching real users (via metrics, video camera, etc.) is unlikely to be permissible in the case of a banking website, even if done in aggregate.
    – Brian
    Commented Sep 6, 2012 at 18:00
  • @Brian agree. But it's better than nothing and I can't think of any rational reason why that should be prohibited; while shoulder surfing has legitimate concerns. Some form of communication is absolutely needed and talk/email is the lowest common denominator. Commented Sep 6, 2012 at 18:16
  • I'm asking the same questions -- this has been the biggest battle so far. It's still early in the process though, and they may loosen up once I've been here a while. Also, this isn't a website -- it's a back end system. Commented Sep 6, 2012 at 19:14

I had wrote this post for a website redesign question, But i think it can be useful to you too.

Application design and or redesign is an interactive creative process that could not be very systematic. But a procedure to follow could be very very impressive to organize our process workflow. This a systematic approach to design or redesign a product. And we could run this in field of web design too.

  1. First of all, create a list of problems with current design: This problems could be gathered from website owners, users (in this case you have not access to them), and other analyses about technical issues, UX, and system logs and etc.
  2. Find root casuals: In this step we try to find root casuals of step 1 problem list. For each problem we try to extract the appropriate root casual. This could be done by using standard methods like 5 whys. May be some root casual overlap each other, so we combine them.
  3. Finding potential causes for each root casuals: In this step we try to extract potential forces that influenced the root casuals. Usually we use Fishbone (Ishikawa) diagram. A good example of Fishbone diagram for "low website traffic" is demonstrated here:enter image description here

  4. Create Not-To-Do list: based on information acquired from step 3, we know what parameters caused the problems an now we could have a big vision on what specification and abilities, our web site should have and should not have. We do this step by writing a list of to do and a list of not to do. This step give us a clear underlying understand about old version problems that we should not repeat and new version good specifications that we should apply to new design.

  5. Extend Design specification: In this step we usually use Five Ws + H method to extend and clarifying our design by asking Who was involved? What happened? When did it take place? Where did it take place? Why did that happen? and How did it happen? through scenario making.
  6. Developing product specification: In this step we develop detailed specification of the overall design in following aspects: Aesthetics, Function, Cost, Material (in term of web design in could be graphic libraries, code libraries, technologies and etc), Environment (mobile, desktop, local culture and etc). This step create the base plan for starting visual expression of the design.

  7. Draw Wire-frames: Yes we draw them but not just based on imagination. This step will be done based on the last 6 steps. Now we have a good understanding on what exactly we want and we start to draw several wire frame for what our website visual design could be. And then we pic top 3 design to next step. Never select more than 3 one.

  8. Rendering the selected wire-frames to prototype: We add colors and motions to our wire-frame in this step and we make them alive. The most important thing in this step is that we choose colors and motions based on our last knowledge and experiences and off course the last steps especially Aesthetic specification, and we don't choose based on personal opinion!!!

  9. Present to employer: In this step we present the final three prototype to our employer. we should well explain all parts with detail to him and persuade him that all parts done based on strongly formed knowledge and not based on personal opinion. Finally the employer will choose one of them (most of times modification will be asked) and we go for implementation.

  10. Finally, implementation: After doing all this steps, it's time to start implementation front-end and back-end of the website don't forget to apply last steps to implementation phase.

Don't forget that design is teamwork in it's genius and you should use group work and brain storm and interactive argument in almost all the steps.

[Added] Most peoples start by screening and creating wire frame and etc. But for sure you need to understand the underlying context of that system even better than developers whom had wroten that. Only in this case you can redesign a big complex system to nice integrated simple one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.