Do you have a process in place for UX design? Most of us have certain techniques and approaches that we favour. To over simplify the process we engage in research, design a prototype, present it to our clients, get feedback, and alter our designs accordingly.
We’ll examine some of the challenges that are faced by UX designers and how they can be overcome. These techniques can be applied to your UX process to resolve some common problems.
With relatively small projects, you can probably proceed straight to wireframe creation and produce an interactive prototype relatively quickly to present your design concepts to your client.
In scenarios where the design is more complex, many designers will create a map of user journeys and define user personas prior to creating a wireframe.
However, what will you do when your user journeys are so complex, and there are so many paths the user can take, that the project’s feasibility is dubious?
There may be numerous workflows in a web application that are applicable to users with numerous roles. However, although some portions of the process may be very complex, we can identify portions of it that are feasible. In other words, you can identify the primary user pathways and follow them.
When creating your wireframe, it’s a good idea to follow the journey of your users from the landing page all the way through to their final goal. Before, examining all the alternate pathways that can be followed, determine if the main pathways are feasible.
Determining whether a reasonable UX can be designed is important. If you find out later in the course of the project that your goals were overly optimistic, then you may have wasted a significant amount of effort and time.
During the initial phase of the project, determine which parts of your UI are the most problematic and create wireframes for them. This will fit in well with the UX practice of mapping the various types of users and their journeys.
By examining these UI challenges at the outset, your design process will proceed more quickly and you’ll begin to get an approximation of the amount of development time that will be required.
Although the issue of feasibility can be hard to quantify in large projects, we can determine more rapidly if we create wireframes for the most problematic parts of the UI right at the outset.
This issue is an off-shoot of our initial solution. How can we account for the gaps that are left after we produce our initial wireframes? In order to validate our work, we need to show it to our client and their users. We must get all the stakeholders involved to ensure they agree with our solution.
Rather than having a long process that shows the navigation in all of the less important user journeys, begin your meeting by showing the solution you propose for the primary navigation paths. By showing these primary pathways, we get our clients’ attention and avoid being side-tracked.
It’s common to become side-tracked in wireframe presentation meetings. Avoid getting stuck in user journeys that are not of prime importance. Get feedback on the primary journeys you have designed for and attempt to fill in the gaps on less important user journeys.
Tell the user a story that coincides with the wireframes you’ve designed and solicit feedback on how you can fill in the gaps for user journeys that are incomplete.
How much detail can you show in your wireframe? A lot of web apps have subtle interactions and rich animations that few wireframes can simulate.
Additionally, state cannot be maintained in wireframes. For instance, is there a change in layout for administrators? On e-commerce sites, what is the appearance of empty and full shopping carts? It may be a good idea to simulate these states in a prototype.
In the absence of state, most applications are of no use, and wireframe software is unable to effectively simulate state.
At the outset of a project, determine the degree of complexity that user interaction will have. Is it possible to convey your design concepts using static wireframes? If this doesn’t appear feasible, then you’re likely to need a prototype that is higher-fidelity.
Doing this at the outset may seem like a lot of extra effort, but it has several benefits. In a project that consists of complex user interactions each keystroke and mouse click can involve details that have a large impact on the overall user experience. A prototype that’s animated will be easier to give to developers so that they will know precisely how the site should function.
This higher-fidelity prototype will also convey your design more clearly to stakeholders and users. You may want to consider one of the following.
An animated prototype is a great way to convey your concepts. While Adobe Flash is outdated for use in a website, it’s still good tool to use for rapid animation. Certainly other tools can also be used such as Adobe InDesign or Microsoft Sketchflow.
Animations can help with issues related to interactivity, and the use of annotations can provide further information on the state of an application. This is a relatively simple solution, however, it is effective in a lot of scenarios. Just ensure that you have informed your development team of your annotation format.
After you have created your prototypes, along with animated wireframes, and annotations to convey the state of your application, there may still be some questions in the minds of your developers, particularly if you are working with a large team.
Therefore, you may have to go a bit further to ensure that everyone involved has an understanding of user behaviour.
Solution: User Behaviour Guide
A lot of projects make use of style guides, however a user behaviour guide may be necessary in conjunction with your wireframes and prototypes.
Your behaviour guide may describe things like:
This is a description of the position, interactivity, and style of elements like success messages and error dialogues.
Describe the behaviour of components such as form fields, modal dialogues, and navigation. You may also want to provide guidance on pagination and lazy loading as well.
In an ideal scenario, your client will have a huge budget, and deviation from the norm would be acceptable. Nevertheless, this is usually not what occurs. The reality is that your client has a limited budget against which the cost of the project has been estimated.
We’ve presented some concepts that won’t necessarily coincide with a type UX design process. Therefore, how can they be detailed when you’re arriving at a project estimate?
As with many design projects, there has to be some flexibility built-in to the process. Your client has to have trust that while a specific action plan has been identified, issues may arise. You need to be honest in the way you deal with your client and the way your contract is written.
Therefore, in order to cover uncertain scenarios, your project estimates should be given as a range. Rather than saying a particular task will take one month, say that it may take between 25 and 40 days. This will give you the flexibility you require.
In large projects this can create a large variation in the total cost of the project, which may make your client apprehensive. Yet, this estimation method will give them a scenario for the best and worst-case, to help them to manage their budget more effectively.
We haven’t outlined a complete list of the essential UX tasks you should use. However, many of the things we’ve described can be useful. Projects will differ, and the same process may not work on every project. You need to tailor your process to suit the unique issues you face with each project.