Designers and Developers have long sought the holy grail: a seamless workflow between both disciplines that allow each to stretch their creative legs and at the same time, not step on each others toes.
However, such a workflow does not yet exist and both disciplines have struggled to keep projects on time, under budget, and keep the other happy along the way. Software, such as Adobe’s Creative Suite, can help alleviate many of the pain points by creating workflows between products. However, tools can only solve part of the problem.
Designers and developers need to work together to create their own workflows that provide an environment that allows for parallel design and development. In this session we will examine one such workflow called the ‘Designer and Developer Contract’. This workflow will focus on wireframes as the contract between both disciplines and explore how a single document can be used by everyone on the project team.
AWS Community Day CPH - Three problems of Terraform
Exploring a Designer and Developer Workflow
1. Exploring a Designer and Developer Workflow James Polanco Aaron Pedersenwww.developmentarc.comflash and the city 2011
2. Who are we? James Polanco Aaron Pedersen Web Application ArchitectsFlex, Flash, AIR, Ajax... Getting into Scala and Lift (James is a nerd) Founders of DevelopmentArcconsulting and development firm focusing on web applications Authors of“Adobe Flash Platform Start to Finish: Working Collaboratively using Adobe Creative Suite 5” – Adobe Press “Understanding Flex 4 Component Development” – Lulu.com Developers of Maque cross-platform tool for all your mocking needs.
3. What is this session about Introduce the design and developer workflow What is a workflow What is a designer and developer workflow A look at different type of workflows Examine issues of the workflows Look at the challenges we deal with on a daily basis interacting with each discipline An in depth look at a particular workflow A favorite of DevelopmentArc and one we practice with most projects
5. Introduce the design and developer workflow What are the common types of workflows? Between tools Between team members Between companies and divisions Between disciplines
6. Introduce the design and developer workflow Between tools... Photoshop -> Flash Catalyst -> Flash Builder InDesign -> Illustrator -> Flash Professional Photoshop -> Fireworks (production assets) IDE -> Source Control Source Control -> Deployment Environments (your builds!) Customer Service Platform -> Issue Tracking -> Source Control
7. Introduce the design and developer workflow Between team members... Project Manager -> Executives Client -> Management -> Development Development -> QA -> Client
8. Introduce the design and developer workflow Between companies and divisions... Design Agency -> Design Agency Design Agency -> Development House -> Deployment Services Design Agency -> Production House -> Development House Executive Team -> Design Team -> Development Team –> Deployment Team
9. Introduce the design and developer workflow Between disciplines... Architect -> Lead Developer -> Junior Developer Creative Director -> UX Lead -> Designer Designer -> Developer
10. Introduce the design and developer workflow What are the common roles of a designer? Creative briefs, style guides, informational wireframes, detailed wireframes, designs comps, asset creation, other UX focuses What are the common roles of a developer? Architecture planning, UML diagrams, framework development/integration, component development, data management, unit testing, and lots of code How do designers and developers work together? Assets and designs are provided to the developer and the developer is responsible for implementing
11. Examine issues of the workflows Every workflow has it’s issues. Common ones include To much focus on the touch point Feedback is reactive Pitfalls of planning
12. Examine issues of the workflows To much focus on the touch point We to often see each other working in silos with little communication with each discipline When we do work with each other it’s at handoff This creates tension and competition with each other
13. Examine issues of the workflows Feedback is reactive Communication and feedback is usually post completion of the other’s work Feedback is usually perceived as negative Finger pointing and blame become focal points
14. Examine issues of the workflows Pitfalls of (not) planning The first shortcut we as a team take is reducing planning Often disciplines are left out of the planning process Misinterpretations of workflows lead to bad planning
15. An in depth look at a particular workflow Introduction to the designer and developer contract The importance of wireframing during planning Executing the contract A theoretical workflow
16. An in depth look at a particular workflow What is the designer and developer contract A process of discovering and defining common goals within the current project An open communication workflow between designers and developers A process that requires mutual respect between disciplines (beers for everyone)
17. An in depth look at a particular workflow Why is it important Defines a common syntax that both designers and developers can communicate with Allows for a more parallel workflow between designers and developers Creates a mutual understanding of features, functionality and use cases for current goals of the project This can be the application, iteration, or even an individual component being developed This helps prevent unnecessary refactoring and re-design due to miscommunication and reactive feedback
18. The importance of wireframing during planning Wireframing is the visual planning of the application Helps provide a visual representation of the application’s features Wireframing should involve development Wireframes become the basis for the contract
23. An in depth look at a particular workflow Executing the contract Wireframes are the foundation of the contract Break down the user interface into manageable sections Each section represents a element that can be further broken down into parts and states
24. Executing the contract (divide and conquer) Defining parts Designers think: a group of design elements, such as files, layers, groups Developers think: a class, movieclips, divs, and components (Flash/Flex) Defining states Designers think: layers, groups, css, states (Fireworks, Flash Catalyst) Developers think: css, component states, other code that effects layout
25. Executing the contract (divide and conquer) Designers create designs based on wireframes and the contract Wireframes can be used as a template for design in tools such as InDesign allowing you to use the assets as a start point in Illustrator Design should be created in an application that provides easier translation into projects For Flash and Flex applications Illustrator easier integration into Flash Platform tools Fireworks helps HTML integration with Dreamweaver or other HTML development tools
26. Executing the contract (divide and conquer) Developers build applications based on wireframes and the contract Business logic can be constructed to meet the contract Basic UI and layout components can be constructed The ui elements can use a simple look and feel until designs are finalized
28. A theoretical workflow Start with wireframes Remember, wireframes are part of the planning process and require input from the entire team Wireframes kick off the designer and developer workflow
29. A theoretical workflow Review wireframes Developers and project managers help provide crucial input and gain insight from a visual representation of the application’s features Establish the designer and developer contract based on wireframes
31. A theoretical workflow Both design and development start in parallel Both teams work in their silos with awareness of each others goals Communication channels are open and are welcome
32. A theoretical workflow Designers create designs based on contract Designs are based on wireframes and the contract Styles guides are created Production assets are started
34. A theoretical workflow Development creates a functional reference application 99% of the business logic can be created The layout and UI can be created with design and logic separation in mind A fully operational application can be completed based on wireframes and the contract
36. A theoretical workflow Feedback Design assets are shared with the entire project team Functional reference application is demoed with the entire project team Time is allowed for cross-review and feedback by each team Feedback is not an end goal. It’s continued through iterations and deadlines
37. A theoretical workflow Integration Designs can be integrated into the functional reference code base by refactoring the UI skin of the application
39. The wrap up Workflows come in various forms Workflows are a series of steps to complete a task They can between tools, companies, divisions, team members, and disciplines Workflows have various pitfalls Workflows are often misunderstood by management Planning is lacking from many project’s primary goals Bad or missing workflows can create tension between team members The designer and developer contract Contract is based on wireframes Wireframes are part of the planning process and include all teams Contract provides clear and common goals for both disciplines Communication is paramount between design and development
40. More about workflows... We love workflows and will be speaking again at D2WC in Kansas City July 14 – 16
41. Thank you... Any Questions? Any questions? Ask them if you got them... James and Aaron Twitter: @jamespolanco, @aaronpedersen Email: info@developmentarc.com Website: http://www.developmentarc.com Maque (Get the beta now!) Twitter: @maqueapp Email: beta@maqueapp.com Website: http://www.maqueapp.com