molly.com
Thursday 6 November 2008
Clarifying a Web Standards Workflow
During a session this week at the fantastic MexicoWeb2.0, an attendee asked me if I had any recommended process for working with Web standards.
Workflow and process has been a particularly difficult area to address, mostly because every company or organization has a different culture. Sometimes you have designers and developers working together, sometimes they exist on opposite ends of an enormous corporate campus. And sometimes it’s just a small shop that has to be agile and responsive to a wide range of client demands.
I had to express my frustration at the fact that after years of trying different workflow options, I still don’t know the magic answer to this question! Working with others in the field, I have promoted a number of ideas, none of which seem to fit broader needs. Clearly, each of these ideas have fabulous merit and insight, and much is to be learned from them.
Existing Process Ideas
Examining the problem early on, Eric Meyer suggested using markup and CSS for the wireframe process. This was an idea that intrigued me and we both promoted it for some time via workshops together and apart (oops, that’s a pun!) Later, when working with Andy Clarke on the inspirational book “Transcending CSS” the idea of an interactive prototype emerged. Essentially, this is a maturing of the workflow process originally described by Eric and others but built to include interaction design.
The big disconnect that I keep finding in these models is the integration of the prototype visual design, the wireframe, and the interaction design. In today’s application-hungry Web environment, interaction plays an enormous role, but is often left until after the design is sliced n’ diced n’ marked n’ styled. And we all know that using graphic prototypes to define interaction can be ridiculously time consuming. This is especially true in large institutions with separation between designers, interaction designers, and front end developers.
Find the Missing Puzzle Piece
So where’s the missing piece? One best practice that has emerged is that we start at the beginning of a project with all the issues: Usability, accessibility, media targeting (screen, print, handheld, etc.), information architecture and so on. This is really the process of discovery, which is well-established in media and graphic design workflows. After that, in the ideal, we move on to actual development: designers design prototypes, this goes to either a graphic or markup-based wireframe, and interaction is added at some point in the process.
The general ideas we toy with in Web Standards workflows of this nature are intriguing, but rarely practical. How many times do we really come into a project in nascent form? Most Web workers are fixing what’s broken or adding to existing infrastructure, although in the area of Web application development we do see some opportunity to begin the beguine, as it were.
Clarifying Workflow Concerns
I’m very interested in how different folks address the workflow issue, and if in fact anyone feels they have developed a process that might be considered a global best practice (even if it’s modified for a given situation). Some specific questions I would like to clarify include:
- Should graphic prototyping be the first step after discovery?
- How do we introduce interaction design into a wireframe early and conveniently?
- How do we cleanly move between graphic design and code requirements (a big question, I think!)
- Is it even possible to think there’s a meta-process available, or should we create each process based on each situation?
And of course, most importantly, your thoughts and experiences on this topic in general will be very helpful.
Filed under: molly asks you, professional, standards, web design and development
Posted by: Molly | 11:15 | Comments (42)
This is usually the point where I use css/js frameworks. A lot, even CMS-es. Basically I build a semi-functional site not paying attention to bloat, SEO, xbrowsing, load speed or anything, once it’s accepted, I start again from a blank slate.
I’ve been looking into this for a while myself. I would recommend you peak at nGen Work’s workflow process (http://www.ngenworks.com/files/nGen_Works_Client_Guide.pdf). They ultimately place the client into a CMS, but use standards and best practices throughout. I recently used it with a client and it went very well.
nGen Work’s web site: http://www.ngenworks.com/approach
I’m not plugging them because I know them well, rather, I respect how they do their work.
I don’t think there is one good global approach to workflow, but there are probably some good architypes being investigated or practiced out there. The nGen Works approach is designed for clients whom are willing to engage in the development of their web site and its interaction with their customer. The approach seems to scale well and follows your thoughts on discovery.
I believe nGen Works also made a t-shirt with you on it?
If I’m managing the project (instead of just coding someone else’s design), my workflow goes like this:
Content FIRST – what is the content? (Get copywriter working on SEO based content/copy)
Interaction Design and Wireframes next – what’s the flow through the page/the site? (Includes discovery and planning for all user devices)
Visual Design is created from the wireframes
(Backend development starts from wireframes as well)
THEN, I slice/dice/code the page keeping accessibility for all user agents in mind from the outset.
That’s integrated with the backend at some point of the process…
That’s the jist of it… It’s a mistake in my opinion to work on visiuals before you have the wireframes. I did a video for Pearson/New Riders that outlines all this (coming soon I suppose)…
BTW, for the Fireworks users (or those with FW that don’t use it) — it’s got some pretty good prototyping abilities these days… including the ability to share layers across pages (headers/footers) and to export some down and dirty CSS to quickly show the client the site. I wouldn’t keep that code to go live, but it does allow foreground/background images and CSS styling to be created very quickly. Just an FYI…
Skip the comps and wireframes — they’re a total waste of time.
Form follows function: start building a working “gray-scale” prototype right away, so you can map and test the interaction immediately (and with real users).
If you’re using a decent framework for your prototype there should be relatively little code wastage evolving to the production version. Worst case, the prototype (and tests, if you’re using TDD/BDD) becomes the requirements documentation.
Paint, chrome, slipcovers — all that stuff comes last.
@hassan: Wow. I actually think that’s very compelling. But how does that address a client site? They want to see the visuals first!
@Hassan, I completely agree.
Working for an e-commerce platform we follow a 2 step build process:
- building the required functionality on top of a generic site for client testing.
- adding the design bits (CSS, images, etc) to the site and another round of testing.
Clients sometime find it hard at first to get used to testing functionality when it doesn’t look how they want, with some gentile massaging we manage to get them over that hump.
We’re BIG fans of the discovery process. While we have our own general workflow, the specifics are usually honed during the discovery process with our clients.
Fundamentally, we move from discovery (identify strategy) to info architecture (site map) to wireframe (functional design as a co-op effort with our tech development team) to creative design (front-end layouts) to development, QA, beta testing, etc.
With that being said, workflow still varies depending on client need. Working with many marketing and IT directors, they usually have their own stakeholders to satisfy, so providing them with tools that demonstrate progress is typically the order of the day. Not every decision-maker appreciates the need for functional/interaction design in a wireframe and would much rather know when can they see the creative design…or worse, “when can we see it move” or “so when can we launch?”
Outside of convincing clients that scoping out functionality is a good thing, whether done with wireframes, working prototypes or both (and then getting them to pay for it), it is absolutely necessary for our internal teams to be on the same page. As a start, we’ve hired designers and developers that think across disciplines. The designer may not be able to write the necessary code to deal with the “messy wires” behind the design, but they’ll certainly be thinking about it when moving those shapes and colors around in Photoshop. The programmer may not be able to pick complimentary colors to save their life, but they’ll make it a point to work with the designer on the UX.
So basically, we’ve managed to overcome many of the workflow potholes with lots of multidisciplinary thinking, constant communication, and a good sense of humor. It’s not 100% consistent and by no means perfect, but in a field that is constantly evolving, it has certainly helped us.
@molly — granted, there is usually client education involved in taking this approach. Discuss the number of sites that look *fabulous* — but are totally frustrating to actually use. Everyone’s got at least one of those stories
And a graphics designer can certainly work with the client on defining a general site “feel” (e.g. edgy, calm, confidence-inspiring) and developing associated elements — color and font palettes, icons, logo if needed — without actually doing “comps” and risking locking in bad interaction models.
Hassan, I see your point, but if the design comp is built after the interaction has been decided, it doesn’t lock anything in. I see no reason it can’t be *fabulous* AND have great interaction. JM2c…
BTW, Fireworks will allow you to create a working prototype (yes, with or without the design – with clickable hotspots and interaction) … It exports as a jpg with hotspots and looks to the client like a site — or a wireframe — depends on how you prefer to do it.
I totally agree that “attractive” and “functional” are not mutually exclusive
The problem I’m referencing is that of showing a “comp” first — which too often is immediately presumed to represent the final deliverable in the client’s mind, allowing no changes. “But you said it would look like…” That’s just bad.
Re’ alternatives to HTML: I realize there are tools that allow some degree of prototyped interactivity. My feeling is: why bother, if you can use the same technology that the solution will be delivered in? Especially if all or part of the prototype will be evolved into the production version? Which also eliminates errors or omissions in “translating” the preliminary medium to the final, not to mention saving time and effort.
Plus for user testing, a working HTML prototype can be installed on a server and accessed by testers from anywhere (which may or not be a compelling benefit, depending on your audience).
I like a lot of what Bill Buxton has to say about design… sketching and ideation phase, prototyping phase, and done.
In practical reality I’d translate that to scoping the business needs and requirements (and constraints), sketching and playing with ideas, looking at the information architecture (IA), some very quick grey box wireframes just to get concensus on layout (but not a religious sign off to the pixel, simply concept), then a quick stab over to the graphic designers for mockups… only they’re not the set in stone mockups one might think, but just a reasonable shot at what we might envision. Meanwhile the prototyping has begun at the signoff of grey box wireframes so we can start testing our ideas about interaction and IA with a loop back to the sketching and ideation phase. When the prototypes mature in that process they are pretty much going to be a finished(ish) product release. Usability and Accessibility should be present right back in the sketching ideation and IA phases throughout. Finally, measure success and iteratively adjust over time based on those measurements.
In practical reality what seems to happen where I’ve worked – non-web managers meet with graphic designer and a programmer and client. Spend half a day discussing and drawing a rough wireframe concept. Spend another day (or year) writing up detailed wireframes they sign off on to the letter. Then the graphic designer “designs” the website with no thought about interaction design or user behaviour / needs, and no thought to the business objectives. A non-web project manager signs off. It gets built as a pre-production version, loses momentum for a year or two, and finally releases over budget, over time, and under performing. Often the words “pretty” or “pop” are associated with the graphic design. But hey it works on three major browsers right?
So I feel your angst on this one Molly. Often the culture is also settled for mediocrity and people pressure you to underperform and just take the wage like a muppet. Which I find impossible, too. You hit the nail on the head right at the beginning – there needs to be a cultural change agent in the organisation willing and empowered to move the mountain a little. Just creating an idealised process never really achieves anything.
OH and many orgs need to fire the dead wood. Even if they’re popular. Even if they’re smart people. If they’re stonewalling or inhibiting quality solutions – exit stage left. Sorry for the rant, pet peeve over recent years.
You know, I wrote something that ran in ALA a couple of years ago addressing this very subject…
I was going to contribute my £0.0128069, but hey, Ben’s article pretty much nailed it for me.
Hey molly,
sorry, this ir really off topic, but I wondered what you think about Microsoft’s plan to implement an ‘Almost Standards Mode’ in Internet Explorer?
[...] Clarifying a Web Standards Workflow [...]
[...] Molly es una guru que derrama carisma y se ganó nuestro corazón cuando nos recordó que no hay que trabajar más para el IE6 porque sino ganan los terroristas. [...]
[...] Molly es una guru que derrama carisma y se ganó nuestro corazón cuando nos recordó que no hay que trabajar más para el IE6 porque sino ganan los terroristas. [...]
I agree with Stephanie.
Here, on Mídia Digital, we start with Information Architecture, where we define our goals and the basics for layouts. But it doesn’t mean that Designers have to do their layouts just applying colors to the “gray boxes”. So they can add their own personality to layouts…
After that, we go to HTML, coding all pages with semantic code and thinking on good accessibility. So, when we have all HTMLs, we code our CSS.
But, before our Designers finishes their layouts, we take a look at it and make some suggestions to make our work more easy, or not, if it’s unnecessary.
A buildings architect understands the stresses of materials though they’re not concerned with the day-to-day of bricklaying.
A web designer must also understand the stresses of materials though they may not be writing code. A designer who does not work with code is either very talented or very detached. Degrees of detachment cause avoidable workflow issues. These issues are multiplied by other detached cogs in the process.
Buildings architects go to university to learn their craft. Everyone should learn to read a bit of code.
[...] Clarifying a Web Standards Workflow [...]
[...] 相关链接：[professional][standards][web design and development][molly asks you]转载自：http://www.molly.com/2008/11/06/clarifying-a-web-standards-workflow/|作者：Molly [...]
Molly,
Hope that all is well – a colleague forwarded me this posting suggesting that what you describe is fundamental to the established definition of Web Engineering (see http://www.iswe-ev.de/). I tend to agree and it reinforces in my mind the need to get the Web development community involved in Web Engineering efforts.
zayıflamak, kilo verme, dogal, Zayıflama hapları, zayıflama, zayıflama, diyetle kilo verme , bitkisel zayıflama, zayıflama hapları , diyet ürünleri , rejim, diyet, zayıflam, diyet proğramı, diyetin, zayiflama hapi, zayiflama haplari, zayıflama hapları, zayiflama ilaçlari, zayiflama yöntemleri, zayıflama çayı, zayıflama yöntemleri, zayıflama ilacı, zayıflama diyetleri,
thank you…
thank you
adult
hikayeler
izlesene
thanks you molly
thank
thanks
thnk
veri nice thanks..
Hi, I liked very much this post. It was very useful to me, tanks. Have a nice day
thanks molly
thanks for all info
Thanks for the info.
That the great idea.
good post thanks molly
i totally agree with stephanie. you need a wireframe first before doing a screendesign. form follows function, not vice versa
Thanks…
hello totally selam agree with stephanie. you need a wireframe first before doing a screendesign.