The divide between UX and Web development can be stifling. Bridging UX and Web Development prepares you to break down those walls by teaching you how to integrate with your team’s developers. You examine the process from their perspective, discovering tools and coding principles that will help you bridge the gap between design and implementation. With these tried and true approaches, you’ll be able to capitalize on a more productive work environment. Whether you’re a novice UX professional finding your place in the software industry and looking to nail down your technical skills, or a seasoned UI designer looking for practical information on how to integrate your team with development, this is the must-have resource for your UX library.
With a BFA in Graphic Design from West Virginia University and a Masters in Interaction Design from Carnegie Mellon, Jack has been designing web, desktop, and mobile applications for over 15 years. He has worked in both research and industry environments and has been teaching design part-time for a decade at WVU.
As Senior Interaction Designer at Inmedius, a Boeing Company, Jack’s responsibilities cover the gamut from initial user research and product conceptualization through to implementation and testing. As such, his skill set includes visual design, information design, and front-end implementation. He has designed software tools for Lockheed Martin, Shell, DaimlerChrysler, Eaton, and many organizations within the U.S. military, including Joint Service Explosive Ordnance Disposal, Naval Reactors, and NCIS.
Jack has spoken at conferences and led workshops to teach designers how to integrate with their development teams and participate in implementation. He is the author of Bridging UX & Web Development, and he writes about design on designaday.tumblr.com.
I would recommend this book to teams that are having trouble. Could be they are moving between waterfall and agile. I don't work on web software but am deep in the problems address by author on a government Enterprise Content Management project.
Of course, I can still identify as a designer who is also a developer and the team personas mentioned. On the team I a a developer, working on an agile team where a single SharePoint developer sees no reason for design documentation.
As you can imagine, I would likely look for another job if the same communication problems persist in the second Sprint. The authors advice in this situation is to pick your battles and realize that the implementation won't reflect the best the team could do.
In my situation, all I can do is fail the test cases and explain to the project that if test cases are written to the design, but the developer does what they want, you will have a bunch of failed test cases.
If this sounds familiar, the Kindle version at $5 at least soothed my conscience to allow an imperfect product to be delivered. It's done all the time. This book at least tells designers how to get out of the way and not be part of the problem.