Why do teams still separate design and development? It’s 2015 and this is a giant problem and prolific within larger organizations. Design and development should not work in silos in order to make a mobile product come to life. This is an old “waterfall” software development practice. Great mobile products are built with integrated design and development teams, usually in an agile environment.

Old method (waterfall):

Business Analyst creates very specific requirements.

Requirements are passed to design.

Design creates end-to-end high fidelity designs.

Design passes these to development.

Development can’t build full designs so developers change the designs.

Software is delivered to business side of the house.

Users get frustrated and request feature changes.

Design redesigns and passes to development, development can’t do designs but tries and passes to business.

Rinse and Repeat.

New method (agile):

Business side of house creates high level requirements/goals with user experience and development input.

Design and development work hand in hand to create features that are both technically feasible and deliver value to users.

These features are divided into user stories, and each user story is designed with development input.

Designers hand over designs as they finish. Development builds designs with design oversight/input.

To build great mobile products, product teams need to have design and development integrated together. team working on a project

They are not mutually exclusive teams. Design can solve problems visually, but if the designs aren’t possible on the technical side, or if there isn’t a budget large enough to deliver a certain experience (most of the time), then design needs to figure out a different solution. This method isn’t possible unless design and development are working hand-in-hand.

Integrate your product teams to create valuable mobile products. Design should have development input and development should have design input. Separating these functions is the Mobile Product Building Mistake #2.

This is one part of a series called 9 Mobile Product Building Mistakes. Stay tuned for next time’s Mobile Product Building Mistake #3: Trying to do “too much” in a release.