I’ve seen a lot of projects reach a point where someone says “this user experience is awful, can we bring someone in to fix it?”. Typically what these projects actually want is a UI Designer who can go in and make things look nice. And for many projects that would help – especially if it’s web based and the designer is good with HTML/CSS.
Instead a lot of projects think that what they want is UX Designer. Ultimately this tends to frustrate both the project and the designer. This happens because the designer starts noticing problems with the system that need large amounts of re-work and often development and many people are instead looking for “quick wins”.
The later you bring a UX consultant into a project the more expensive it will be to develop a good user experience.
A better time to bring UX into a project is during requirements gathering. Here it’s about how a UX Architecture interacts with the Business Analysts. Take this potential requirement for a university system:
During enrollment the student MUST update their personal details (address, phone number…)
This isn’t a requirement but a solution. Worse it’s a solution to an unspecified problem. The requirement should be:
The university MUST make sure that students keep their personal details up-to-date
Now a UX Architect can work on solutions to this problem – ideally with user research. Not just research that involves speaking to users (which is a must) but also quantitative data analysis if it’s possible.
And not just end-users but also staff that interact with those users. Especially if there is functionality designed on the admin side for staff to use – giving them a better user experience makes their job easier and makes serving your customer easier.
After requirements gathering a UX Architect should interact with the Solutions Architect to work out how the technology platform can accommodate the user centred design. If the project isn’t mature enough to have a Solutions Architect I’d argue it’s not mature enough to have a UX Architect.
On some projects the research during requirements gathering might be done by a different kind of UX professional to the UX Architecture work done in collaboration with the Solutions Architect. On some projects the next step involving the design process would be done by a separate UX Designer. And on many projects this tends to be done with a “UX team of one”.
The key fact here is that UX design is a separate step from the UX architecture. The architecture involves things like user flows, communication methods, strategy (including social, mobile, cloud), information architecture, analytics implementation, etc. The design component focuses on things like usability, affordance, consistency, interactivity, etc.
Sometimes you are fortunate enough to find a UX Designer that’s also very good at UI design and/or front-end development. This is a rare combination of skills that shouldn’t be relied upon as it tends to stretch the person thin and leave some part of the design lacking. Obviously the size of the project and budgets tend to dictate these things.
The important thing is that UX Designers either prototype extensively before development or work very closely with developers to do rapid prototypes in code. Having a UX Designer that can code can be an incredibly useful asset on agile projects that deliver production ready code every sprint.
Of course, simply having sprints doesn’t make a project agile – nor does having a tight deadline. If the project follows a waterfall (requirements -> solution -> development -> testing) then wireframes are as valuable as any other documentation.
Some UX professionals have broad skills that stretch from research to front end development. Others are incredibly specialised, such as those that focus on interaction design or on usability testing. The key thing is getting the right type of UX person at the right part of the project.
If a project is already well underway then getting a UX Architect or UX Designer isn’t likely to be helpful. The kinds of research methods and improvements they suggest are likely to lead to big changes to existing code. At later stages of a project it’s better to find either (or both) a UI Designer who is good at HTML/CSS or a UX Researcher who can test the UI with actual end-users and give suggestions on how to make it better.
As a final note, the best time to get UX involved is during ideation. This means spending time talking to users and understanding their needs before embarking on a project. When you consider the end-user early enough in your process it can fundamentally alter the approach.