Freelancing

as net artists we’re concerned w/the cultural, political && aesthetic possibilities of the Internet + related technologies (namely the wwweb). we approach the technology critically + playfully, we prioritize experimentation && our work raises questions more than it cares to answer them. for wwwweb designers, developers and other creative technologists it's a bit different. a creative technologist’s job is in fact to answer questions + to solve problems. it’s about lending ur skillz + perspective towards helping realize someone else's vision (or a collective vision). it can be a humbling transition for a solo-artist coming from a fine art practice.

working with+for a client can be frustrating && it’s easy to think that they “don't’ get it”. keep in mind that their area of expertise is likely something other than the Interent/Web or creative technology (otherwise they wouldn’t be talking to u). when u’re forced to give up some creative agency + work on things u wouldn’t normally work on + in ways u wouldn’t normally work + for an audience u normally don’t think about + in a context u’ve never considered… lots can happen. these inter-disciplinary collaborations can be extreamly rewarding. u end up collaborating w/folx from worlds u would never have imagined working w/before. even the most frustrating client experiences can end up informing ur studio practice in important ways in the long run. it’s important to approach each client project w/an open mind + a humble attitude.

these days u can do almost anything on the wwweb && as a freelance creative technologist u might be asked to make all kinds of stuff from simple portfolio pages to complicated web apps and interactive installations. different sorts of projects might require different sorts of considerations, while the process² i'm articulating below applies to almost any freelance/commercial creative technology project, i'm using the example of a "portfolio site" (custom website for a client/brand) as well as a general checklist of things most projects like this should consider. the process can be broken up into the following four stages:

1. Proposal
2. Planning
3. Design
4. Development

first things first, u gotta meet w/the client, make sure they’re someone u can see urself working w/ + make sure u’ve got the skillz to do what it is they want. we’ll assume that they’re looking for a website for their “brand” (maybe they’re a fine art photographer looking for something more than a squarespace, or maybe they’re an indie-music label, or a local startup, etc.). we’ll also assume they’ve already got some kind of identity.³ that said, there’s a few things u’ll need to know about them before u can give them a quote+contract: get a clear idea of the scope of the project, besides a splash page⁴ what else do they want on their site? how many pages is it going to be in total? what’s going to be on those pages? get a sense of their audience, who’s going to be visiting the site? what will they be looking for? get a sense of their timeline, do they have a deadline in mind? && most important, be clear about exactly what it is u plan on giving them (ur deliverables). someone unfamiliar w/creative technology might think u’re also a copywriter⁵ or a photographer or hosting provider (more on this in a bit). Once u know everything u need to know say, “it was great meeting w/u, i’ll send u a quote w/in a week”.

the quote is an outline of what it is u plan to do for them, how much each of it costs && what the grand total is going to be. this is often also accompanied w/some kind of contract. the contract is less about lawyers +lawsuits⁶ && mostly for managing expectations. there are lots of sample web design +/or web development contracts online u can use. below i’ve listed out a few things u should make sure to include:

as for the terms && conditions, for many this is the wordiest part of the contract && is usually a load of legalease they copy+pasted from an online template (there’s nothing wrong w/that, everyone does it). but it doesn’t necessarily have to be. u might want to find some language online regarding intellectual property⁷ && liability⁸ but u could write the rest in layman's terms (folx appreciate that), the contract killer is a nice example of that. a few things u should likely include in ur terms && conditions include:

cancellation: what happens if they cancel halfway? u should probably send ‘em a prorated invoice (&& explain it'll include any unpaid expenses incurred, like maybe u had agreed to pre-purchase 3yrs of hosting for 'em)

revisions: even though u’ll have this detailed in the project outline it’s wise to stress this point, specify what the max amount of revisions per step are && how much time they have to get back to u w/their feedback or approval (u can of course do more, but should explain this will come w/an additional cost)

maintenance: like i said up top, it’s very likely that someone notices something wrong after everything is done && paid for, u’ll get an email w/the subject line “small edit to the site”... sometimes it wont’ be small && sometimes it won’t be the only email w/that subject line. b/c this is so common it’s a good idea to include a few hrs for maintenance in the quote (this also helps address the fact that hrs worked after launch aren’t free), some clients might want to sign a “retainer” w/u (which is a year or so contract where u agree to give them a certain amount of maintenance hrs a month && they agree to pay every month… but proceed w/caution. here again setting expectations is key)

browser/device support: it’s a good idea to detail specifically which browser versions u’re going to support (do a caniuse search for something like border radius, that’ll give u a good idea for what’s reasonable).

before u start designing anything there’s a list of things u should do, this might seem excessive but i promise it’ll save u lots of time in the long run. the first thing u want to do is have ur client fill out a questionnaire so u can better understand their goals && audience. then it’s ur turn to do some research, using their responses to the questionnaire as a guide. then u’ll put together three more documents: a creative brief, a site map && a timeline. u’ll set up another meeting w/ur client to look it all over. if they approve then (&& only then) u start the design process.

in my opinion the questions re:the target audience are among the most important in this questionnaire. there are some clients who may think their site is for “everyone”, but that’s very unlikely to be true. if this is the case, help them narrow down who that target audience is: ask them what their age ranges might be? how do they identify (gender identity, racial identity, etc)? What country? city? neighborhoods? income level? education level? marital/family status? occupations? how often do they use the web? what devices to they access it on? ...not all these questions might end up being useful, but it’ll help narrow the answer down a bit from “everyone.” ⁹ once u have a solid idea of who the target audience is, it’s also important to know/ask why folx visit this site && what they’re trying to achieve. what are they key motivations for coming here? what are their goals? it’s important to get this all down in writing in ur questionnaire && have both u && ur client sign off on it (no room for ambiguity w/this section)

in addition to asking them to list out websites they find inspiring, it can also be helpful to ask them to make a mood board, which is a collection/collage of media (usually images) that collectively represent a particular style. this is a technique designers often use to get a feel for the style their client’s want.

once the wireframes have been approved (likely after a couple rounds of revisions) u can open up photoshop¹¹ && start designing. web design && web development are two separate disciplines, these roles are often filled by two different individuals (or groups of folx) in any given web project. that said, for freelance web folx it’s not uncommon to tackle both. there do exist creative technologists who are trained+talented in both graphic design && development/coding (but these are rare, in the industry they’re referred to as unicorns). seeing as how we’re fine-artists-in-training w/in a new-media department, mayhaps we’ve got some unicorn blood in us.

hosting isn’t ur job. it’s tempting to think “i can host their site on my server && charge a little extra”, but after a few clients u’ll find urself stuck w/doing all kinds of tech support stuff that well exceed what u ended up charging them for hosting. hosting is another business all together, it’s best to leave that to them. if they already have hosting ask them for their FTP info (credentials for accessing their server) && set up a "dev" directory/folder for urself to work in before the site goes live¹² (never develop on the root directory, nothing should go "live" until launch time). if this is their first site u can offer to help them get set up w/hosting (ie. guide them through the process of setting up an account on namecheap or somewhere else) but make sure they understand that has more to do w/them than it does w/u.

testing¹³ doesn’t mean that u made sure it worx, the creative technologist is the worst person to “test” a site, b/c u know exactly how it works, u know where all the buttons are, u never have to think about any of it (the client also isn’t the best tester, for similar reasons). testing means u ask folx (ideally the target audience) to interact w/ur site, u stay quiet, sit back && take notes. it’s too easy to get caught up debating w/a client about where a button should go, in the end the best thing to do is test it. this can be a humbling process, something u thought was obvious can be missed by everyone who tests ur page. as they say "test early" (one tester early on can be as valuable as a dozen testers later on) && "test often" (testing isn’t something u do once, it should be an iterative process built into ur timeline).

testing can be as simple as asking a few folx (again, target audience) to let u watch them interact w/ur page for a few minutes, but there are also lots of tools/techniques specifically developed to optimize the testing process. a tool we like to use is usertesting.com, where u can pay a group of users (from ur target demographic) to use ur site, while they screen record their interactions && speak aloud what their thinking. another technique is spit testing (or a/b testing), usually deployed once a site is live, what u do is show half ur users one version of the site && the other half a different version of ur site && compare the results to see which version performed better.