|
There's a reason why most mainframe systems today are called ‘legacy'. Distributed processing is now so in-built into our way of life that large number crunching mainframes are somewhat of an anachronism. Having said that, the retail financial services sector needs massive processing capability to deal with many millions of transactions per day. I want to talk about design because I have strong views on the subject, influenced by my background in marketing. In my experience, design of user interfaces in any deployment has two limiting factors:
1. The limited availability of flexible solutions for interfaces and
2. The limited view and non-inclusion of marketing in the design process
Many believe that marketing has no place in most deployments because they are not usually customer-facing. The reality is that the marketing function is usually the only function that has any skill set that includes psychology. After all, their job is to create environments in which people will be manipulated to do things they either wouldn't normally do or to do things they would do, only quicker and in a particular way. To achieve this they have to have, even at only a practical level, an understanding of why people do things. To this extent they are best placed to provide a semiindependent view for most technology deployments that will help people use systems more effectively. Some examples of questions rarely asked in a technology deployment but which can have material effect on their success and/or useability. Proportion of females in the user population. This has an effect because females have a different approach to technology than males in a number of ways. First, females approach technology, successfully, when it is designed in a more rounded, emotive form. They also have very different visual cortex processing - they react differently to colours than men do. If the population of users has a large female element, it is incumbent on the management function to recognise this and adapt the system design accordingly. This might either be a deployment designed for the majority or a deployment where the interface can be adjusted to suit the psychological profile of the user on a gender basis. Women also navigate systems differently. The old cliché abut women and map reading is a good example. Brains are ‘wired' differently. Any competent manager of a technology deployment should have user acceptance testing (UAT) groups that represent the different elements of the full user population and should include sufficient psychological knowledge to understand why a particular sub-group within the UAT group takes a particular viewpoint and associate that with the appropriate weighting.
Age profile of the user population. In a way similar to the gender-based approach, age is a differentiator in how people successfully use technology. Younger users tend to be able to deal with a much greater number of variables at once, whereas older people can deal with a much smaller number of data elements on a screen. Of course, if the operating system, for example Windows or OSX, allows it users can to a limited extent, vary their own experience of any given interface, but this, in a build environment is a ‘cop out'. The operating system's ability to provide flexibility is severely limited because it has to average out the population. Most users given the opportunity, do not change visual settings from those established as default settings. Yet, in many, many technology deployments, I have seen attention to such details rarely. The build scenario is particularly relevant here because there is a better opportunity to affect change. In bought systems, the user interface is most often designed by men and had no real analysis performed on it for useability. The opportunity to get a 5% improvement in employee loyalty and productivity by including such subtle design activities, and communicating the process to users, has a disproportionate effect on the ultimate delivery success and user response.
Localisation is the term usually used for creating a technology deployment that is to be used or accessed across different national or cultural boundaries. It is strange that technology managers do think about localisation, but rarely take the concept to its logical conclusion. Localisation is most obvious in the availability of a technology deployment in multiple languages. Often, especially in the back offices of banks, staff have English as a second language - if you're lucky - and many will have no English at all. The difficulty for technology managers is the degree to which localisation is ‘paralleled'. In other words, if the only users of a system are, let us say Italian, then clearly an Italian language system is fine. However if users are global, then every screen implementation must be localised to its user audience. This creates additional cost, opportunity for errors in translation and added maintenance and upgrade headaches as every localised version will need to be checked every time code or user interface changes. Language also has impact on screen design The length of words varies depending on language. German for example is 33% longer than English. So what might fit nicely on one screen inEnglish will not on a German langauage screen leading to fundamental screen view differences. As people, are more and more mobile, the time taken by people to adapt to the same system when implemented in different countries using a localisation methodology can cause productivity drops, if not basic errors. Similarly syntax and grammar can have an effect. Typically in Europe, the decimal differentiator is the comma whereas in the United Kingdom and United States it is the period.
These are only a few of the factors involved. They are not intended to be an exhaustive list of factors. They are intended to highlight the fact that in managing technology in financial services and elsewhere, it is all too easy to focus on the general issues and miss out the issues which are more subtle, but which actually differentiate a good technology deployment from a great one. In my experience, best practice within the design phase of managing technology should:
1. include a statistically relevant sample of the user population in the specification and UAT teams;
2. provide for sub-groups comprising the major types (gender, age etc.) and then allow for cross-disciplinary groups to conduct peer reviews.
If you're going to spend potentially millions of dollars on a deployment, the least you can do is spend some on the ergonomics and have some method of knowing whether what you are doing is having an effect.
Ergonomic Fit (Ef) measures the degree to which the different variables in the deployment have been factored in. Since there is a degree of judgement involved here, the measure uses the results of sub-group pre- and postdeployment analyses to provide an indication of both absolute fit and relative fit, that is in the latter case, the degree to which the spend on ergonomics has delivered value. where p is a result score generated from a questionnaire given to a focus group post-deployment, q is the result score generated from a questionnaire to the same focus group pre-deployment and n is the number of groups SCALE
As can be seen, one of the biggest issues is that the sheer scale of build solutions combined with the long development and test cycles involved mean that firms choosing to build their own solutions are faced with a fast moving competitive environment and tools that are not suited to it. Even smaller-scale builds suffer from the same disadvantages. Buildyour- own solutions are rapidly falling out of favour simply because the firms involved, although they have the size and resources to accomplish a build, fail to understand that the sheer scale of such projects distracts the organisation from its core purpose.