If you gave different designers the same business requirements and the same technical constraints, what are the chances that they would come up with a similar design?
Partner organisations who work with Metrici Advisor are impressed with its flexibility and analysis capabilities, but suggest we need to do more work on the user interface.
I have been wondering why our software has this combination of strengths and weaknesses. Why did we design the software the way we did? Why does anyone design software in one way rather than another?
Consider two approaches to the design of a web-based system such as ours.
This is a highly interactive system, which requires a sophisticated user interface. It should be designed with a rich GUI, using libraries of standard GUI components to ensure a consistent look and feel. The majority of the design will involve a richly interactive environments such as Flash or Ajax, using calls to the back end to manage data persistence.
This system holds data on the server in complicated data structures. The integrity of the data is paramount, and must be managed within well-controlled back-end services. To deliver over the web, the most effective user interface will be pseudoconversational, in which a stateless client receives whole pages from the server. The majority of the design will involve the back-end database and services. The user interface can be built using relatively simple server-based scripting such as ASP or JSP.
Approach 1 is the PC programmer's approach. It focuses on user interaction, at the expense of not fully understanding the back-end implications.
Approach 2 is the mainframe programmer's approach. It focuses on managing complicated data in a multi-user environment, and uses a method of interaction which works well technically with the web, at the expense of user interactivity.
Metrici Advisor follows design approach 2. I could make a spirited defence of why this is the better approach, but if I am honest, the real reasons for this is that my background was as a mainframe programmer. From the start of my career, my mind has been programmed in a particular way. Complicated data structures, multi-user systems and pseudoconversational programming are second nature, and so I designed the solution around what I know.
We could have built it another way, and we would have traded one set of benefits and problems for another set of benefits and problems. We are now improving the user interface; if we had started on the user interface, we would now be working on making the back end effective.
The IT solution you get will depends hugely on the background and experience of the individuals involved. Significant applications will require more experiences and skills than can be in one person's head. When building a team, consider where there are holes in their experience, and strengthen the team to ensure it has covers all the required areas. This will bring conflict, as different minds bring their preferences and experiences to the same problems, but it is better to resolve these conflicts during design than after the users get their hands on the system.