Internal Server Error
what the voices in my head tell me to write
Saturday, December 12, 2009
Towards a more unified way of developing sites
The division between designers and developers has existed almost from the birth of the printed word. Technologies have been produced to make information more rich and interesting from more complex layouts, pictures, and now video, sound and all kinds of interaction.
There is always some form of either a technological development being exploited by designers or a technology being developed to meet a design based need. In most cases it is likely to be a combination of the two.
The problem lies that designers and developers do not always see eye to eye on many levels. There is often a level of resentment in the relationship between the two. Developers view designers as head in the clouds types with no idea of how things get really done. Designers view developers as stick in the mud types resistant to change. They both talk about teamwork, Agile methodologies and co-operation but often the creation of a site ends up as a basically two stage process. The designers create a plan of how they want the site to look and work and hand it over to the developers. Then they may double check things at the end of the project or iteration etc.
This is just a waterfall process by another name. The designers "hand over" their wireframes etc to the developers and say "get on with it". They might have used Agile to develop the wireframes and the developers might use Agile to make the actual site but there is still a massive discontinuity between the two parts of the work.
Often the designers and developers are in separate teams and entirely separated in different offices etc. Even in my current job the designers are at one end of the office and developers are in the other end. Often the designers can be in a separate company to the developers.
I personally believe having worked as both a designer and a developer in different roles that close communication between designers and developers is vital. Communication is all about the exchange of ideas and more communication means more ideas. Maybe not better ideas but there are still more ideas than there were.
Designers and developers should be involved at every stage of the entire process of creating a site from its conception right through to its on-going use by real people. Database developers need can help plan the basic functions of the site. It will make their job of developing a schema easier and they might well be able to say "if you want it to do XYZ to make things easier" and create something entirely new that the designers had no idea could happen. That is only one example. The opposite of course can happen as well. A designer can come up with a requirement that a developer would have never have thought of.
At the moment the process is one way. Designers design and developers develop. When either group crosses the boundaries into the others territory then conflict occurs. There needs to be a breaking down of barriers to some extent. Of course there have to be specialists. Its crazy to expect a graphic designer to be a DBA as well.
Processes like SCRUM and Agile help with this to some extent as they should get people working together. However this does not always work for the reasons outlined above.
I think that there are enough similarities between different roles to implement a sort of eXtreme Programing technique combining developers and designers. This is based in part on my experience several years ago. I was working for a small college as a web developer working with a designer to create all kinds of material based around HTML content.
We quite often worked on interface elements of a project at least as an XP team. I would be working in Dreamweaver, Photoshop or the like with the designer sat in the "co-pilots" chair and between us we came up with a solution for a problem. At the time it could be hell and led to some quite spectacular arguments and I am not advocating this exact approach but it is a good starting point for a discussion.
What I am proposing is a kind of buddy system. There is enough common ground between several types of jobs in both the design and development fields to make this work. For instance a information architect designing the high level specifications for the site could work alongside a database developer who models how the site is represented in a database. They are both concerned with how the site is organised and that gives them common ground.
The obvious team up wit the UX and front end developer working closely with each other. The developer can advise the designer on what is possible but the designer can come up with new ideas that the developer might have missed.
The problem lies with who to team back end developers with. They are not a natural fit with graphic designers. They may have to be involved with some aspects of UI development but they often avoid this sort of work. There seems to be more correlation between the sorts of structures and organizations that an information architect creates and object orientated design than anything else. Taxonomies, Labelling schemes and metadata all have their place in the object orientated world.
Some other functions a site may be expected to have may be very interdisciplinary. Search for example will involve aspects of information architecture, user experience design, front end development, back end development and database design. If any one of these is omitted the function is likely to be less useful to the end users.
A personal example is a good way to illustrate this. Recently I was asked to provide a series of wireframes and other UX documents to a recruitment company for a site that its candidates could use to look for positions, clients could use to look for candidates and its consultants can use to match candidates with vacancies. By co-incidence the first real commercial website I produced was for a different recruitment company nearly 10 years ago now. Back then I looked at the companies paper based forms and processes to create a database schema to store the information they used and built the site from the back to the front so to speak. This time round I evaluated the companies existing site and interviewed its staff and also some candidates and clients about the site to conduct a basic usability study and expose some new features that would be useful on the site. These data were then turned into personas, sitemaps, wireframes and other documents which were turned over to the clients developers to implement.
Essentially the same process took part this time round as 10 years ago however. The difference in the two is 10 years ago I was more of a developer and understood more about databases that information architecture and user experience design. Now I understand far more about the design side of creating a site than the back end development of a site, certainly I know more about usability than SQL now. What occurred in both cases was that I modeled the users needs and requirements. I just used two totally different methods to do so. However this time round I could apply the knowledge I gained 10 years ago when designing a database to model a recruitment company to my current design problem.
The key area of the site as with many others is search. Candidates want to find jobs, consultants want to find clients for candidates and vice versa. Clients want to see a good pool of candidates. All of this when you get down to the real nitty gritty is a well designed and executed database schema and set of queries to interrogate it. However it is down to the user experience designer and information architect to make the search as easy to use as possible. No one wants to type in SQL queries to get their data out. (apart from real DB geeks) Users demand power and flexibility. They want to choose from a small list of options and sprinkle a few keywords to find their dream job. It shouldn't take long and it shouldn't be difficult.
This is where good design comes in. Both the DBA and IA have to accurately model the users needs. They are both using different forms of design to achieve that end. The DBA has to work out a schema that is both accessible in terms of the ease in constructing SQL queries to interrogate the data within it and also usable in terms being performant in returning data quickly. The IA/UX designer has to model the users needs into in effect a web form that generates the SQL queries that the DBA uses to interrogate the database. This has to be accessible in terms of ease of use and performant in terms of enabling a user to get the results they requested.
Its not implausible that the IA/UX designer may model some user behaviour that the DBA had not thought of. Similarly the DBA may be able to spot and model some user behaviour that the IA missed. What is often overlooked is that when two experts work together on a common problem from different angles they are able to collaborate to gain insights that they would not otherwise have come up with independently. It might be possible to discover a new way of requesting data that might have been overlooked. A unique selling point perhaps or certainly a competitive advantage. If the "designers design then hand it over to the developers" model was followed in this case they this synergistic process would be missed out on.
Teamwork is the core to all of this. Maybe not the extremes of XP or lesser peaks of Agile but good communication and the sharing of ideas and concepts cannot be a bad thing. When people share they create something they would not be able to do individually.
Permanent link and Comments posted by Rob Cornelius @ Saturday, December 12, 2009
