exploring the relationship between social science and software development methodologies: a blog by Pascal Belouin

I am currently working on a medium-size web development project for a public organisation: the project is implemented by a small, agile team of developers external to the organisation (rather talented I must say!) on the basis of specifications written by myself and my colleague. These specs mostly consist on word documents as well as rather detailed GUI (Graphical User Interface) mock-ups, designed on the basis of our interaction with test users. We have catch-up meetings with the development team once a week, where we have a look at the progress of the project and go over the specifications and how they could be implemented.

As the Information Systems manager for the organisation, I have been responsible for managing the project, but since I am also an interface designer I started producing a lot of front-end code. Things are going quite well, and I think both the team and ourselves are rather happy about the way things have come along so far. However, I am starting to wonder if things couldn’t even be better; let me explain what I mean!

Basically I’m starting to wonder if we’re not wasting time and energy constantly revising the UI mock-ups as we are refining the specifications. Since most of time most of the mock-ups need to be revised due to the change of sometimes one single word, a lot of effort is going into something which at the end of the day doesn’t really add a lot of business value. Thus, it would seem to make sense to write these mock-ups directly as static HTML: These would be kept constantly up to date, and it would be a breeze to connect the business logic code to the mock-ups as the development work goes further. In addition, test users can see straight away something that will look a lot like the end-product, the only difference being that the HTML prototype would only feature dummy data. I have been following this strategy during previous projects, and I didn’t see any major drawbacks. The various versions of the UI can be explored using the versioning system used by the team, and the mock-ups are directly available ‘in context’.

Therefore, I think I am going to adopt such a strategy for all my future projects, and I will let you know how it goes! I would love comments from people who actually use this approach, or who tried it but weren’t satisfied by it for some reason.

Related posts:

  1. Interface Design and Information Architecture for Enterprise Web Applications: Four Simple Principles
  2. A Short, Practical Example of User Experience and Interface Design for an Online Drink Ordering Service
  3. Architecture against Interface Design?
  4. The (sadly) important impact of politics on enterprise software development: a developer’s lament
  5. Social science for software developers – Using tools from social science to inform software design: should software developers also be social scientists?

3 Comments to “Outside-in Web Application Development: The advantages of building production-ready static html prototypes as interface mock-ups”

  1. Pascal,

    This is the whole premise behind prototyping software like iRise. As far as I know there is no open source alternative except for what you are doing with the production ready html UI. With static html, How would you exercise all the user interaction scenarios when all you have is a limited set of dummy data? How would the UI design reflect optimized paths of interaction based on user efficiency goals and priorities without an opportunity for the user to explore those paths?
    -Dennis

  2. Hi Dennis,

    Thank you for taking the time to comment this article, this makes a lot of sense! Thank you as well for introducing iRise to me, I didn’t know about this product.

    I think you basically highlighted a potential weakness of such an approach: interaction between users (for example) would be rather difficult (not to say impossible ) to mimic using a static prototype for the reason you highlighted.

    However, I would argue that this makes the creation of static html prototypes one of the first step of the development lifecycle, the next one being ‘plugging’ the front-end designed in such a way to the actual business logic, and take it from there:

    Thus, we would end up with a process where the front-end code gets developed before the actual business logic, business logic that is necessary to test a particular functionality is developed to make the prototype behave in the way that needs to be tested, and once the implemented functionalities are fully tested and signed off we start again.

    Therefore, maybe the solution to this is to use a front-end that is a mix of static and functional stuff, branching between different prototype versions may also be a way to test alternative designs?

    I hope this makes some sort of sense and that I am not blabbering too much!

    Pascal

  3. Arnoud says:

    We’re using this approach as well:
    Step 1: paper mockups
    Step 2: wireframes
    Step 3: PSDs
    Step 4: HTML templates, ready for exact handover to implementation team (i.e. fully tested & validated code)
    Step 5: implementation on beta server with real data
    Step 6: release on live server

    Each step has a review/test before the design moves to the next stage and all steps (except 1) are put in a versioning system. If it doesn’t work, it’s killed early without too much impact. The later it’s killed, the more impact it has. Sometimes a step is skipped (particularly step 2 or 5), but that’s usually in low risk scenarios.

    This is working really well for us. We started working this way almost a year ago.

Leave a Reply