There is a lot of overlap between understanding a company, writing specifications, and user experience (UX). Design and UX define how the user interacts with the product, and this greatly impacts what the product is and how it is built. It is not something you just bolt on at the end, it is something you work on right from the point of starting to understand the customer’s needs.
If you’re not developing your UX alongside specifications and prototypes then you are doing something very wrong. But in the same vein if you are jumping straight in and trying to design the UX before fully understanding the customer and their domain, you are also going down the wrong path by leading the solution without a full understanding of the problem.
In a simplistic sense UX is where the button is and what the button does. User interface (UI) is what colour that button is.
There is often an odd disconnect in that while UI is vastly important, customers tend to place an unduly large focus on it compared to the actual functional value the application should be generating.
We pride ourselves on excellent visual design and implementation of beautiful and modern interfaces. That said, it is undeniable that in most large and complex projects this design element is only a very small part of the total workload.
We try to work on UI iteratively. Delivering it gradually as part of the continuous delivery process means that as we keep working on a product, it will change in appearance as it matures.
It is important to include customers in this process. There is a large temptation with design work to hold off presenting it until it is ‘final’. We prefer ‘good enough’ combined with ‘setting expectations’.
Once feedback has been collected and functional ideas are proved to work, we add final touches to take the design through to finished.
User testing & feedback
User testing should aim to observe users ‘doing’ actions you want them to achieve in the application.
It should not aim to ask questions like ‘is this button in the right place’ as that means very little without context. It should ask users to complete ‘business tasks’ then observe how they go about using the software to try and achieve that task. This will highlight pitfalls, misunderstandings, and successes along their journey. For example, one observation might be that they could not find the right button or that they were looking for the wrong button altogether.
You should use preformed questionnaires so you can follow a standard format with everyone tested. Do not ask leading questions. Do not ask for advice (e.g. what do you think we should do to X?)
Find real users. 5 real users are worth 50 random people found who have no real connection to your product beyond the fact that they are roughly the right age and demographic. How you define ‘real users’ will vary wildly depending upon the project and so this has to be tackled on a per-project basis. Sometimes, it may be as simple as using the employees who will be using the final system.