There are great answers here already.
I'd like to provide a slightly different perspective on the topic, which is more process-based.
Test driven development
From the different strategies for software development, Test Driven Development (TDD) is one of the most popular ones nowadays.
It asserts that you should write tests before writing any code. But the paradigm goes way further, as many see the tests as the pivotal piece of documentation, requirements and specifications of a system.
Tests should capture:
- Use cases, including alternative paths.
- Expected feedback for various user actions.
- The business logic.
- etc.
Much of this is defined by the work of the UXer.
Tests may be written in a fairly natural language (see Cucumber), or using a programming language in (hopefully) a format that is understood by non-programmers; something like this:
describe( "distance converter", function () {
it("converts inches to centimeters", function () {
expect(Convert(12, "in").to("cm")).toEqual(30.48);
});
it("converts centimeters to yards", function () {
expect(Convert(2000, "cm").to("yards")).toEqual(21.87);
});
});
Human-centred TDD
The combination of human-centred design (meaning UX drives the design of the system and thus also its implementation) with TDD is becoming ever more widespread.
The process looks roughly like this (a lot has been omitted for sake of clarity and focus on the key message):
What's important to notice is that tests serve as the bridge between design and implementation. The argument often revolves around who should write the test, with the options being:
- The UX designer - we need to document many of what the tests cover anyway, so rather than writing something in one place that is then converted into a test, it pays to actually only write it twice in a syntax that can be easily converted into a test.
- The QA person
- The developer - developers often have to write additional tests for internal code units anyway, and are most proficient with the syntax.
My argument is that if one considers round-trip engineering, UXers should be the ones writing the tests that capture much of their work.
What does it mean for developers?
- First, good tests provide well outlined specifications.
- Tests save developers a lot of time since the code is tested automatically rather than the developer having to test all previous behaviours with each change (to give one example, a structured date entry field I've designed involved 64 tests, most represent atomic use cases like "if the user is on the day partial and presses TAB the selection should move to the month partial"; if the developer was to test manually each use case after implementing it together with all previous use cases, there would be 2080 tests to be run)
- Tests reduce bugs.
- Tests allow developers to write better code since they can improve the code without fear of it breaking.
OK, so for all of this to happen what is needed? Developers shall write code against well specified requirements in the form of tests.
Does this mean 'being told what to do?'. Well, in a way yes. But consider the alternatives - just giving a short sentence of a required feature and hope the developer will do a proper design job and write the tests?
I'd argue that developers will be happier to be part of an HCID/TTD process, than any strategy that omits either or both of these components.
Of course, this still doesn't mean we shall not get them involved in the design process, but you should remember that both their persona and perspective on the system is understandably different from that of users or UX designers.
