UX vs Strong personalities — #2 The self-assured architect
Working in larger projects or big organizations you might encounter a systems (solutions/enterprise) architect. That person is responsible for defining an architectural vision to ensure the system is fit for its intended purpose and plays a crucial role in making the systems come together. Often, the architect has a value focused perspective, but some take a more technical view and that is when it all can go wrong. In that case you, as an UX:er, will have to do what you can to bring them around to a more value and user perspective.
The role and experience of an architect is invaluable. It is one of the key factors when constructing larger systems and one that enables fast development and changes. But it can also be the one that makes life difficult for an UX:er that tries to put the users in focus. Most of the architects are value driven but some have a problem to see where the user fits in the value equation. Working with UX we know that values are only created when a user is using the system. That is something an architect has to grasp to see the complete picture. Technology without users is just dumb technology.
Working with a bigot architect can make the end-result a nightmare for the users. When technology is designed for the sake of technology the users always suffer. The users are forced to understand the underlying system model in order to do his/her job which can lead to frustration, stress and lots of errors. This was prevalent in the 90’s but still occurs when UX is not present or overridden.
I once worked with an architect that had been developing systems for a long time. He told me he was so proficient so he already knew how to design new systems, even the interaction design, and questioned my presence. When I did paper prototype testing with users on the architect’s original design a lot of issues were identified. As you all know, issues always emerge during testing, but the architect reacted with both misbelief on the test results and explanations why he already knew his design was flawed and how he was going to address that. I had a hard time making him listen to users rather than his own ego.
Another architect I have crossed paths with was obsessed with technical accuracy and bit perfection. Due to technical limitations he proposed forcing users to convert their documents to PDF on their own, as automated conversion could not be made 100% accurate. He showed no understanding what so ever that that actually could be a big challenge for the target group. All information in his system had to be 100% correct. He could not explain what could go wrong and under what circumstances so there was hard to have a constructive discussion to come up with a user-centered solution.
A couple of years ago, I was employed at a company where the architects (about a dozen) had severely limited the system due to security issues, ruining the UX. They were paranoid that a single system user could access several subsystems simultaneously and wreak havoc with the business and had therefore restricted the access. This decision made the users blind, handcuffed and stressed-out. The system was undeniably secure, but at a cost that made it almost unusable.
An experienced, stubborn and self-assured architect is a hard nut to crack. They have been working with delivering systems for a decade or more and are accustomed to work in a specific way. Prestige and pride can also be factors to take into account when understanding them. To make them come around and start seeing things from a user’s perspective you need to shake them up a bit, to get them to drop their usual behavior and ways of thinking. They must understand that users are more important than technology.
One way of doing this is to make them feel what the users feel when using a system — frustration, pressure, joy, relief and more. Bring the architect to meet and listen to users, let them sit in on user testing, let them hear users struggle or express gratitude. It will be an eye-opener for the architect when emotions are shown over seemingly trivial issues, realizing that those issues really matter for the users.
Another important thing to do is to involve the architect early in the design process. If the architect understands what you are designing for and why, it’s easier to create a system design that supports that. And the architect might even come up with suggestions for a better design — make them feel involved and important.
An architect usually has a lot of say and you need to make them your friend. You don’t want your design to fail due to technical reasons and you also want to understand the real technical limitations. You cannot force a specific design to be implemented if it would take an unreasonable amount of resources. You will have to know facts so you can create alternative solutions.
A systems architect makes a great ally. They can make your design come alive using technology in a user-centered way. However, some architects have a technical way of looking at the world and can severely limit your opportunity to create a great user experience. Use the advice above to convert them using technology for the sake of people, not machines.
