I’ve found that most of the educational materials on user experience design gives the impression that UX design projects will always be a “from scratch, develop a new product or application” effort. In my experience, that’s rarely the case.
While it is great to work on a “blue sky” “anything goes” project – and if you get a job in UX you will get to do those type of projects – the typical design project in my experience is usually focused on tweaking something that already exists. Be it a site or app, it’s an existing offering that has some history… and, unfortunately, some baggage.
When doing this type of project, there are some important steps you should take in the early days of such an effort. They are:
Learn all that is learnable
Interview stakeholders and other members of the team to find out the history… why is the design the way it is today? You’ll find out a lot about not only the decisions that brought the design to where it is now, but also get a sense of the team’s attitude about the design. This is very valuable “intelligence” that can help you avoids mistakes that were made before.
Also, take the time to “learn” the legacy design. Step through it, doing the tasks and end-user would. Identify the workflows that exist and understand what the key scenarios are. Study any research and information that informed the final design.
Be objective (and hold your tongue)
Don’t go off half-cocked and say, “this sucks” to a stakeholder as a first impression… First off, it may not “suck”, you just may not be familiar with the UI conventions, workflows and terminology to understand it at first glance. It may align with the mental models of the end users quite well – it just doesn’t make sense to YOU yet. Also, that stakeholder may LOVE the design… and any flippant “this sucks” response could close off a potential ally.
Do a heuristic review against best practices and design standards
There are some great best practices in UX and UI designs out there – some will be detailed later on in UX101 – and you can easily take them and form a review “checklist” to apply to the existing design. I personally like Jakob Nielsen’s 10 usability heuristics, because they are easy to understand and communicate to team members.
Identify contributing factors
Why is the design the way it is? It may not have just been the results of the previous design team’s efforts… it’s likely technical or platform limitations may have had something to do with it. For example, if a dashboard looks a little “thin” in the content department, it may be because the back-end architecture isn’t robust enough to serve up any more data. Talk to the developers about the technology used and any constraints they have, and this will prevent you from making recommendations that simply can’t be done.
Don’t go crazy (and redesign everything)
If you propose to drastic a change, you run the risk of alienating everyone on the team – “That’ll take too long! That’ll confuse our existing users!” The end result of such a conversation is almost always that nothing happens, which benefits no one. Be strategic, and identify “low hanging fruit”… aspects of the design and the experience that can be tweaked with minimal effort.
Build to the big changes gradually, and try and make a difference as much as you can as you go.