Building a Bridge Between Designers and Developers
How different job roles effectively facilitate communication between developers and designers.
Join the DZone community and get the full member experience.Join For Free
Back in the day, when the enterprise was a place of grey dull tools that users were pretty much forced to use against their will, application development practices were pretty simple.
A consultant or business analyst might appear one day to gather requirements. If you were lucky they would consult actual end users, rather than just those paying for the project. These requirements would be documented in-depth, in ‘Functional Specifications’ with word counts north of 10,000. Graphic designers would be handed this document and expected to develop a UI that worked for every use case. They might talk to the consultant from time to time, but they certainly wouldn’t interact with the client.
Wireframes and graphic designs would then be added to the 10,000 word document, bulking it out further, before it was handed to the development team. Working in a darkened room away from anyone remotely described as a user or stakeholder, this team would build the app. Something like twelve months would elapse, before a completed application would be foisted upon an unsuspecting user base.
The results of this waterfall model of application development could be disastrous. Requirements and use cases not tested properly, leading to a disconnect when it came to UI and UX, and ultimately developers building an unusable product. Each cog in the process tries to do a good job, but the disconnects ultimately mean the project will fail.
A Better Way
There had to be a better approach, and indeed the Agile software development movement brought with it new and smarter ways of working. Suddenly requirements reflected users wishes, developers talked to designers, and UX and UI was connected to functionality.
But with the changing methodologies came a few other very interesting developments. Chief amongst this was the blurring of roles between designers, UX, UI, and developers. What has happened over the last few years is a bridge that has been built between the three disciples. The result? Better UX, better apps and happier users.
Let us look at some real job roles that neatly demonstrate this bridge:
The bridge: Once the UX designer would have stayed in Photoshop, now they are happy testing out animations using CSS3 transitions.
A UX designer is interested in the overall feel of an application. A UI designer is much more focused on specific elements of interaction - buttons, forms, widgets, and controls. Like the UX designer this person often comes from a design background. But these days they are very much expected to understand how their UI will be built. They might even build bits of it themselves. The days of roughing up a design and letting a dev build it alone are gone. So a good UI designer might work with pre-built controls like our own jQuery and HTML5 controls and weave those into a product development.
The final role we will look at is arguably the most technical. This is person who is ultimately responsible for building an apps interface. They create the ‘front-end’ that the user interacts with. More often or not this person comes from a traditional development background, and now specializes in things like jQuery, HTML5 and CSS, maybe even languages like C#. They will use tools like our own HTML5 Designer. But this person is no average developer. This person needs to have an eye for design, and whilst they might not create visual designs themselves they will certainly need to appreciate pixel perfection.
The bridge: An expert in web technologies with a good eye for design
It is no coincidence that as the lines between traditional designer and developer roles have been blurred, enterprise apps have undergone somewhat of a revolution. Take our own SharePlus. It takes the best of SharePoint and Office 365 and wraps it in a beautifully designed and functional mobile app. It makes mobile working a reality, and this in itself is only possible because of the bridge between the various application team disciplines.
Published at DZone with permission of Josh Anderson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.