How we work (and sometimes skip some steps)
Aug 4, 2009 In Process By Tim Aidlinwhat about those of us who's teams are very small and deadlines very tight? Those of us who can't afford the headcount or the hours to have multiple rounds of internal and external back and forth approving wireframes, comps, and working sites? Is there a way to manage the current standards of meetings and workflow
Battling with the developer/designer workflow is one problem I consistently hear about from fellow designers and developers, as well as experience consistenly. For years I’ve worked with different systems, whether simple organic naming conventions and shared folders, or mega-custom CMS systems that managed a nationwide network of offices. Depending on your situation, you may be at either end of the spectrum. Most of the time, however, I find many small agencies and freelancers could benefit from some simple source-control and some workflow tricks that can make the relationship between developers and designers and clients a bit more effective.
Oftentimes creative assets, whether they be visual comps or individual assets, are "handed over the fence" to the development team who then is responsible for building the site and incorporating the stylesheet and visual aesthetic (not to mention the possible interactive aspects or animations). There are a lot of great developers out there, and they can take visual comps and assets and build out a solid, valid, functional site. We all know,however,that no site is built and immediately published. The designer — not to mention the client — always requires changes. And what about those of us who’s teams are very small and deadlines very tight? Those of us who can’t afford the headcount or the hours to have multiple rounds of internal and external back and forth approving wireframes, comps, and working sites? Is there a way to manage the current standards of meetings and workflow?
The below is entirely influenced by the folks over at 37Signals. I was able to take a workshop and see their session at The Future of Web Design Conference in New York last year. I totally “drank the Kool Aid,” and found that the methodology — used correctly — can save time and effort for websites or applications that are small to medium in complexity. Now, I’m not going to go into the "discovery" phase of the project; that is to say, what you do before you have collected all your research, met with the client, defined the scope of the project, etc … Rather, let’s start when you’ve rolled up your sleeves and are staring at a blank sheet of paper.
Or, perhaps, whiteboard.
Whiteboarding and Sketching
We generally start out in a conference room in front of a wall of whiteboards, markers in hands, laptops fired up, and ready to roll. At this point we’ll generally use one whiteboard to write down and brainstorm features, then translate that featureset into a set of *crude* wireframes, thrown up in blue, red, green, and black. Of course, the complexity of the problem we’re trying to solve may require a few rounds of this, but at that point, we simply pull out a digital camera and take a photograph of what we’ve worked out. Then we start again with the next problem we have to solve, continuing to do this until we have enough to at least start trying to build out the framework of the site or application we’re working on.
Source Control and Project Management
Next we’ll generally set up a project in Team Foundation Server (TFS). For those unfamiliar with TFS:
Microsoft Visual Studio Team System 2008 Team Foundation Server is a team collaboration platform that combines team portal, version control, work-item tracking, build management, process guidance, and business intelligence into a unified server.
For most of the projects I work on, the developer — whether web-dev for working on an application — is working in Visual Studio. For me, now that Expression Web 3 and Microsoft Expression Blend 3 include the ability to access source-control (at least using TFS, if not others) there’s rarely a case where I have to operate in Visual Studio, which runs TFS. There are lots of different software available used for source-control, all easily found on the web. For those who are used to checking files in and out, I’m sure you can sympathize with those who don’t. Being able to work simultaneously with others on the same project and maintain locks on files, a history of changes and versions of documents is invaluable.
Project Management: SCRUM
When we first decide on a project, we set up a standing weekly meeting of an hour with the whole team. During this meeting we go through a short demo of where we are with the project, address open issues from the previous week, and open new issues and suggestions. Additionally, we’ve found it very useful to also schedule a *daily* meeting with just the key players (in our case, usually the one designer and one developer working on the project) to show what they’ve done in the last twenty-four hours, and raise any blocking issues. As you can imagine the combination of competition to see who can get the most done, coupled with the daily meeting to get problems out of the way, is very conducive to quick results.
Functional Wireframes — skip some steps
When I worked at agencies, and often with those I engage now, the next step usually leads to Adobe Illustrator or Photoshop and wireframes. From these static wireframes, often the resulting images are rolled up into an Adobe Acrobat .pdf; and they’re sometimes terribly artifacted during the compression process. The progression usually went: Static composites (comps) created in Adobe Photoshop or Illustrator, those comps turned into discreet assets and redlines created to callout margins, padding, font-sizes, etc … From there, we as designers / Creative Directors would throw it over to dev and trust that that team could get it done, which, of course, they generally did a decent job of. Yay for talented web developers.
What I’ve been doing lately, though, is moving directly from the whiteboard into wireframing up the site directly in HTML and CSS. For this, I find the 1kb CSS Grid very useful. Nishant wrote a great Opinion on this in June. Using this set of CSS styles, it’s very easy to lay out a useable, skinable, HTML + CSS site, that not only conveys the structure and flow of the site to your client, but provides actual usable code to the development team that’s waiting to begin building the site. As an example:
Not only do the wireframes generally look like the usual structural wireframes we present to clients at the initial stages, but they can be semi-interactive (they’re not in this quick example, though), which helps clients understand the flow of the site. I often find that this is where clients provide the most revisions, and, by making important links working links, by making navigation working navigation, the client and developers are able to understand the user-experience better, and either (hopefully) buy off on the functional-wireframes, or see problems at this stage, which can be addressed before major development or creative assets need to be changed. Additionally, a benefit of this methodology is that, so far, nothing is thrown away – there are no Illustrator files that are simply archived and never touched. No Photoshop comps that need to be revised again and again, only discreet pieces or content. When text is laid into the content structure, it looks *exactly* as it will when it’s converted from image to HTML, because it never was an image to begin with. If you’re going to lay in Lorem Ipsum, might as well make it optimally editable, right?
I also find this methodology works well when creating applications using Silverlight or WPF using Blend 3. Why go through the hassle of creating wireframes in Illustrator and Photoshop, only to export those into another application, which requires an export of your work to a new file-type in the best of situations, or a redo of your work most of the time. Why not simply start out working in Blend and create your wireframes there? Take a screenshot the XAML wireframes and create your visual assets in Expression Design or Photoshop, and return to Blend to build your site. I go through this in more depth in an earlier post.
Once the wireframes are approved, the site can then – generally – move into two different, parallel tracks in development of the site: aesthetics and functionality. We’ve been using TFS or some other source-control up until this point, so all we have to do now is give our developer access to the html and CSS we’ve been working with, and from there they can do the build of the site using whatever technology has been agreed upon. This helps significantly, too, with the normal “translation” from a visual comp to a working framework. No longer does the visual designer have to provide redlines showing the margins between columns and layout — that information has already been delievered by virtue of the stylesheet.
While the visual design is being adapted, refined, and approved by the client, the development team can be working in parallel to get the functional structure of the site built and ready for the creative to be delivered and put into place. I think of this very similarly to figuring out the finishes and fixtures on the house, while the (of course, very talented) construction crew builds the framework. There’s really no reason the two phases can’t work in tandem.
While in the examples the wireframes and comps are very rudimentary, you’ll see how if we work with an agreed-upon structure, development can build the framework on which the designers can create the aesthetic. As well, working in tandem helps with interactivity, as well. Collaborating closely on issues such as animations, click-behaviour, colors, and the like, helps avoid re-work down the road.
Thanks, by the way, to Worktank for letting me use in the examples above their visual comps for the PDC09 site.
Follow the Conversation
4 comments so far. You should leave one, too.
I no longer find the need for wireframes, although getting photoshop comps are still a nice inspiration to start from. I like to start right in with html, css and jquery then go from there.
I would also caution not mixing the ux portion with the scrum dev process. I''ve discovered unless you have the bulk of the ux work ramped up or near done prior to scrum dev sprints that it puts additional pressure on your developer to change things too often thus causing cost overruns.
Hi, Adolfo. I do agree that mixing the UX portion with dev can be dangerous. I generally try to have the majority of the UX thinking reflected in the wireframes, which is when we split into design and dev in parallel.
And, again, I also try to stay away from traditional "static" wireframes and move into HTML + CSS early in the process. I''m glad to hear that this methodology is being used more and more in the wild.
Cheers!
A bit random in my thoughts here, but this was an inspiring post, Tim, to read. Atop my post below, I''m a big fan of team brainstorming, internally, to assure that my project team really got it right. Let others within the org critique and barrage your app, but just be sure that you moderate this as a PM since this can get out of control quickly. Keep the noise down, but allow the feedback to flow in and take account for the good, the bad, and the ugly feedback. Lastly, be sure that your allocated team addressess the recomendations, too. It''s not fair for the team to get feedback and not be allowed to act on it. A round just before delivery can assure that the fit/finish/polish is there, too. Many times in .Net 3+ there are so many easy wins that could be overlooked, so take advantage of this, too.
http://paultheprojman.blogspot.com/2009/08/designer-developer-workflow.html
Hi, Paul. Thanks for your comment, and the great follow-up blog post on your site. I think you provide some really good added insight and exposition on some of the ideas presented in the above, and I appreciate the shout-out and kind words.
I also think your assessment of how new workflows translate well into the "Microsoft Expression stack" in a pretty seamless manner, allowing us to tackle problems in the most efficient way possible for the given situation (final deliverable, timeline, client requirements and expectations, etc ...).
Cheers. Hope to see you back at MIX Online soon. Be sure to follow us on Twitter at @mixonline ...