Application designers and software developers come from different mindsets. They’re often different personality types. To create a successful product, they have to overcome their differences and work together.
The designer is concerned with an application’s appearance and the user experience. The developer creates the application itself, using layouts and graphic elements from the designer.
The designer may give instructions to the developer, the developer to the designer, or a manager to both. Regardless, they have to work together as a team. In the developer’s eyes, the designer often proposes wild, impractical ideas that will set the schedule back six months. If the process turns into one of constant conflict, it isn’t good for the project.
Cooperation From the Beginning
After they have the requirements, the designer and developer need to work together on the specification. It isn’t necessary or reasonable to nail down every detail, but the spec needs to establish the scope of the project and the kind of technology it will use. The team needs to minimize the chance that major changes will be necessary later.
The designer can and should have ambitious ideas about the user interface. The developer might react in shock to some of them. The right response isn’t to say, “That’s impossible!” (unless it literally is) but “This is what it will take to do it.” What it will take includes not just development time but impact on performance and on the minimum configuration. When the cost is high, developers should look for ways to meet the requirements more economically and suggest them.
The designer needs to take the lead not just on graphic elements, but the whole user experience. How should each screen be laid out, and how does the user go through a task? Should there be an undo capability? Should it support multiple levels? The developer’s job on these points is to make sure everything is clearly specified before trying to code it.
The spec should reflect everyone’s agreement on the scope and design of the project before the coding starts. It won’t be the last word, but it establishes a baseline.
The Coding Begins
As development work starts, the designer has to provide graphic elements, such as icons and images. The final versions don’t have to be available right away, but something with the right dimensions and file type needs to be available early. Exact colors aren’t important in the early stages, but the layout is.
The developer should aim for a demonstrable prototype as early as possible. It doesn’t have to do anything usable, but it needs to show some of the user interface. The purpose is to get feedback from the designer and other stakeholders. What looked good in a mockup may need changes when people see it in action. The prototype serves two other purposes: making sure that the developer understood the spec correctly, and discovering any major implementation difficulties early in the development cycle.
This is the point where the designer might say, “That’s great! But wouldn’t it look even better if…” The developer’s first reaction may be to put a head-shaped dent in the wall, but it’s necessary at least to consider the idea. The right answer might be, “We already talked about this when drawing up the spec.” Or it might be, “It’s possible, but we’ll have to re-examine the schedule.”
But the best first response is to think about it. It may turn out, after a little thought, that there’s a way to do it. Looking more closely at the capabilities of the software libraries or searching Stack Overflow can turn up ways to make it possible. Shooting down impossible ideas is prudent, but turning them into possibilities makes a software hero.
Dealing With Change
There will be changes as the project proceeds. Some changes don’t affect the user interface, so the developer can go ahead with them. When the changes significantly affect the software’s features, everyone on the team has to accept them. This can force the developer to wait for design revisions. The only thing to do is to keep moving where the work isn’t blocked. There are always bugs to fix or performance issues to address.
An issue tracking system which everyone uses is essential for keeping the process sane. Some issues naturally take a long time, requiring discussions before deciding on how to resolve them. Without a record of the discussion, progress can grind to a halt. When the participants see what’s been discussed already, they can move on to new approaches or suggested changes that can make previous suggestions more workable.
Success as a Team
A project succeeds when all the members of the team have good communication and focus on the same goals. Managers, designers, and developers all have different perspectives, and no one of them can create a good product by itself. Constant communication and mutual respect lead to the best results.
