I try and follow a few number of simple principles when I develop the front-end of enterprise web applications (that is to say web applications which aim is to support the processes of a particular organisation), both to inform design decisions and to avoid scope creep. The main approach I tend to follow and advocate could be summed up in one sentence: “keep it simple, and communicate!”: I’m sure that a lot of people will agree with me on that one!
First principle: know the domain
Although contact with users is important, one of the main advantages of using user-centric design methodologies is that they allow developers to gain an extensive knowledge of the domain in which the system they are developing will inscribe itself into. Indeed, this is a crucial point that is sometimes overlooked by developers and even interface designers (this is understandable, as it is sometimes not that easy to gain access to end users and domain experts). However, a good knowledge of the domain allows developers to use domain vocabulary in the application as much as possible. It’s quite easy for developers to very quickly develop notions that make sense to them, but have no meaning for the users out of the context of the application: when new concepts or notions need to be created, it is often very helpful to make sure these make sense to domain experts. Defining such notions is also a great way to start thinking about architecture and about the various processes that will be handled by the system.
Second principle: identify the main objects that need to be represented by the system
Once you know the domain, it becomes possible to identify the main objects that are supposed to be represented by the system. Identifying the common operations that need to be performed by users on these objects should allow developers to start and put together the general structure of the front-end, and guide most of the preliminary design decisions they will be taking in the beginning of the project.
Third principle: consider the structure of the front-end
The structure of the front-end will often follow the architecture of the actual code base of the application: this is certainly true with Model-View-Controller frameworks. However, as I tried to illustrate in a previous post, interface design, which main goal is to providing users with the easiest way possible to perform particular tasks, relies on different principles than software architecture: It is interesting to notice for example that web application frameworks such as Rails or CodeIgniter are designed in such a way as to provide the most intuitive way for developers to build applications, and have some very elegant features such as restfulness and meaningful urls. Although most of the time it makes sense to follow the inherent structure provided by such frameworks, most of the time discrepancies will arise between a coherent and elegant architecture and “what makes sense for the users”. A well-defined and meaningful structure will also have the advantage of providing a strong basis for a clear, easy to learn navigation scheme.
Fourth principle: keep a tight grip on the rudder!
As Derrida told us, meaning is slippery: that is certainly true in the framework of web application development (corny). Indeed, as the objects and processes represented by the system become more and more detailed and complex, an increasing number of design decisions needs to be made to accommodate this new level of complexity. I found it is particularly important to keep on top of these, and to make sure important decisions are made in full knowledge of their implications in regards to the domain: the importance of good communication between developers, end users and domain experts becomes particularly salient!
Related posts:
- Architecture against Interface Design?
- Outside-in Web Application Development: The advantages of building production-ready static html prototypes as interface mock-ups
- A Short, Practical Example of User Experience and Interface Design for an Online Drink Ordering Service
- The (sadly) important impact of politics on enterprise software development: a developer’s lament
- Social science for software developers – Using tools from social science to inform software design: should software developers also be social scientists?