Our Approach

We rarely have the time at Erskine to put a lot of hours into developing commercial ExpressionEngine add-ons, but we do accumulate a few bits and pieces that others might find useful, we’re now going to start pushing these out to the community as they arise – through the medium of GitHub. Documentation will be minimal but the usage examples in the code should suffice.

Currently on GitHub

ED ImageResizer – resizes, crops and caches images on the fly. Anyone at Jamie’s EECI conference workshop will have seen this. I think that there is another alternative out there already that does a similar thing but we’ve been using this for a while and it works well for us. See the plugin usage example for more.

ED Text – this has been kicking around for a while, it basically truncates text to a given length without breaking words -and strips html etc.

ED Conditionals – A simple plugin that takes weblog and category ID’s as parameters and then lets you use {if has_content} conditionals in your templates. The results are cached so using the plugin several times with the same parameters won’t keep blazing database queries.

Why use GitHub now, after all this time?..

We’ve been using the service Codebase for our code development/management needs and one of its new features is the ability to push updates to your Git repositories to a third-party (in our case GitHub). So through the magic of Codebase and GitHub, Erskine are now more likely to be making public the little things that make our ExpressionEngine lives easier.

I hope you find them useful. I will be converting the ImageResizer and conditionals plugin for EE2.0 – more here when that happens though.

This article is part one, and perhaps the most important, of the series: cash is king. Enjoy…

First, a couple of questions for all you web-business owners out there. Do you give 30 day payment terms to your clients? If so, have you thought about the logic of what you are doing?

A little history

The net-30 day term concept came from the days where invoices were sent by post, arriving at the clients post room then moved internally to the finance department.

Once there they would be sent up to the department who initiated the work and signed off by the project leader then to be sent down to finance again.

Here, the poor invoice languished in one of many ‘in trays’, until entered into the purchase ledger by rows of hapless clerks with quill pens.

They would then be scheduled for the ubiquitous ‘check run’ where the head of finance would go though the ledger, sign the cheque, then send it up to the Finance Director to countersign.

This boring, but extremely valuable, slip of paper was put in an envelope and sent down to the post room where it was posted, second class (remember we are talking about accounts departments here), where the supplier receives it in its own post room two days later.

The post room then sends said cheque down to the finance department where it is entered into the sales ledger, collated into the daily ‘takings’ through the bank ‘paying in book’.

Another hapless soul takes the cheques to the bank.

The bank then processes the cheque and three days later, ‘bingo’ the money is finally credited to the suppliers account. Tremendous…

I can see this process taking 30 days, but in this fast, electronic age does it take that long?

No, the stages are basically the same, but the use of purchase order numbers, electronic billing, BACS / CHAPS / SWIFT and ‘same day’ bill payments really streamlines the process. So why do we still offer 30-60 day terms?

Cash is king

If you have been in business long enough you will know providing credit is risky, eroding the company’s cash position and of course, offering trade credit to less-than-creditworthy clients results in bad debt.

I have seen loads of great firms go out of business due to poor cash management.

Accountants love profit and loss statements. I think they are good for forecasting / budgets but useless in the day to day running of the business.

A well constructed and accurate cash flow forecast is a thing of great beauty; the ‘Mona Lisa’ of the business owners tools.

Many people out there use credit reference agencies and long detailed credit application forms asking for references etc. In my opinion, these are a waste of time. It is much more effective to have short credit terms and use…

Advance and stage payments

We are design firm and we sell our creativity and technical know-how that basically equates to time. At the end of every month we pay salaries and overheads throughout the month/quarter. Cool.

So, we take on a new client, send them our contract that contains our standard terms of business. Here we specify the terms of payment that always involves an advance payment and further stage payments in advance of the work being completed.

Of course, we don’t start work until we receive an initial payment.

The result

The boot is now on the other foot. The client is the one who is taking the risk by paying us up front and in advance of time spent on their project; we have the cash in the bank to enable us to function efficiently. I have to say I prefer it that way :-)

In all the clients we have now worked for only three have not been able to agree to the seven day terms.

So, what are you all waiting for?

The previous part of this little series saw us fighting through some motivation/direction problems, and the realisation that even non-client projects need managing and scoping properly, right from the word go. We also found our ‘fuck yeah’ design direction (as I call it); a visual approach that would give us a decent platform from which to design the actual website pages effectively.

Now we needed to start designing our actual pages. As with most projects we work on (both internally and for clients) we started with some really simple wireframes to define content hierarchy. As you can see these are really simple; we knew what the site needed to do, and we knew we wanted it to achieve those goals in the simplest way possible.

After those wireframes had been through a repeating process of print, scribble, discuss, iterate, we began to think about the actual visuals of the pages.

You’ll notice in the following screenshots the absence of any navigation, branding or traditional footer areas – we wanted to get our content designed properly before getting hung up on any site-wide detail.

We started with the Projects section, as we thought this the most important part to get right in order to achieve our goals.

We spent quite a bit of time working on concepts like these; where the page was primarily focused on the case studies (which at the time were part of the same section) with a projects browse area below that attempted to appeal to everyone from everywhere by using Client, Industry and Type selector categories.

We even built a full EE prototype of this last one before realising it was asking too much of potential clients. As I’ve already mentioned we wanted things as simple as possible, so we ended up separating out the Case Studies into a new section (and creating relationships between Projects and Case Studies) and drastically simplifying the Projects main page into a more traditional see-like-click interface.

I should add as a slight aside that from the start we didn’t want to use screenshots of our work for this page. I’ve never seen a decent example of a 200 pixel wide screenshot that was able to effectively sell a project, so we created little ‘adverts’ for each project that ultimately are a lot more interesting, and would increase click-throughs to the project-detail page.

Knowing when to stop

This last screenshot brings me onto an important point. Because this was an internal project, there was effectively no time or cost limit, and as mentioned in my previous post, things can slip very easily. It’s therefore very important to know when to stop.

Take the above example of our Projects page for example. I wasn’t 100% happy with the layout and detail of the page, but I knew there was no way for me to spend weeks and weeks iterating it to a point where I was 100% happy. The hardest person for a designer to please is themselves, and often a designer must swallow personal irritations with their work in order to keep the project moving.

As I’ll talk about in a few articles time, there’s always opportunity to exercise your perfectionism after launch; such is the beauty of designing editable things like websites.

Until next time

That’s all for today folks, but as an almost-apology for delivering this installment so tardily, here’s a few bonus screenshots for your perusal. Hopefully they give a further idea of how the site developed visually over a period of time.

Following a direction to reach our goal

If everything has gone to plan throughout the process, then we’ll have arrived at a superbly functional system with strong visual design, arrived at in an iterative manner.

Many of you will agree that the days of offering up three or four polished designs are long gone, and frankly a waste of time. We can save money and work smarter here.

We educate our clients that a website will be designed along a specific path. Our research and processes equip us to follow a certain direction, offering up rough sketches, basic wireframes, more complex wireframes, a prototype and so on. We’d then do some colouring in as we evolve the suggested design. All the way through, we’re exploring a single, focused design path.

With a solid understanding of the intended audience, and as a result of a well-honed process, we should be confident enough to explore a single path and ultimately result in a successful, stunning product.

Deliverables sheets

We give the client a sheet linked to Basecamp that acts as an ongoing Table of Contents for the process. It’s a one-stop-shop for actual deliverables. The noise is all in Basecamp, whereas here what we have just the real signals; all are deliverables – pure output.

Move through each batch one-by-one and the process is clear. There is a narrative – a journey. The path page is proof of concept – it backs up all the promises we made to the client at the beginning.

The deliverables the sheet links to (sitemaps, wireframes, batches of comps or prototype files, experiments) are all in chronological order. There is a progression – a path. It is one single focused design path, and acts as a repeatable framework for future releases.

This is another tool we couldn’t be without. It’s just a few HTML files and links to the deliverables we upload, but this works very hard for us and provides a constant focus throughout the project cycle.

Conclusion

Over this and the other eight posts, I’ve outlined a number of tools and methods that we’ve twisted, and you can maybe twist even further. Along the way, we’ve explored tools that help create empathy, simplicity, flexibility, creativity, quality and relevancy.

So, you might be a designer, a developer, a creative director; a freelancer, or part of a team. Maybe you represent a communications team, or are looking to commission a major web project. Whatever your stake in the web, I’d hope that some of the ideas that I have presented give you some measurable value, and fresh ideas to take back to your colleagues and assist with devising your own flexible tools.

Most of the budgets we work with need to cover our responsible processes. These figures are often called into question by potential clients who might not initially appreciate the inherent value. Every time we explore and illustrate the merits of a good process we hopefully help those new to web commissioning understand why its so valuable.

And with that, I’m closing my toolbox.

Note: Slides designed by Gregory Wood.

Paper Prototyping

It’s fun and bloody useful to create rough sketches of screens and behaviours, developing these sketches gradually through collaboration and experiments. I’m a big fan of Clearleft and their myriad experiments with paper and pens. They make use of what is around them to try things out and understand relationships. They’ve even been known to use Lego for layout. These experiments can then feed directly into perhaps flat wireframes, or browser prototypes.

Wireframes in Photoshop, Fireworks etc.

We know that a wireframe is basically a lo-fi prototype of a web page or screen, used to identify the elements that will be displayed on the page or screen, such as navigation, content sections, imagery or media, form elements, and call to actions. It’s a map.

As wireframes are typically created in black and white or shades of grey, using placeholders for images, and do not get into specifics on visual design elements, they allow us to share ideas and collaborate together without anyone getting hung up on thoughts of exact proportions, colour, typography, or imagery.

To pluck out a suitable analogy, if we were designing a house, at this point in the process we’d be concerned with what rooms the house should consist of, how they should be positioned in relation to each other, and roughly how big they should be. We wouldn’t be worried immediately about precise measurements, wallpaper or whether the taps are brass, bronze or chrome.

This is an iterative process. We can start by rendering the solution only in enough detail to provoke engaged consideration without spending too much time or effort creating renderings that may well be modified or abandoned. Typically, this is happening in Photoshop, Fireworks, OmniGraffle or other more lightweight tools such as the idiosyncratic Balsamiq app.

Browser prototyping

So, many of us love building traditional wireframes, but why try and explain how something will work when you can mess with multiple approaches on the fly and then demonstrate how it will work instead? It isn’t always advisable to design and prototype in the browser – my colleague Gregory creates complex art-directed pages such as this gorgeous page that are better prepared elsewhere.

Still, for most projects browser prototyping is a great way of saving time and money. The prototype should ideally be on convention – perhaps using your equivalent of our Ultimate Package, building up from that new prototype towards a finished product through constant iteration and experimentation.

It also allows us to hook up the CMS at a much earlier stage and use some real data. After preliminary data modeling, we can set about creating relationships between sections and examine how information flows and is manipulated as a user moves through a site.

The browser prototype is also a test-bed for a variety of jQuery behavioural experiments, API data and so on, much of which might see it through to the final design. Other experiments can be evaluated and perhaps be ruled out rather quickly.

Be sure to take some time to read Andy Clarke’s Walls Come Tumbling Down transcript for greater depth about browser prototyping.

Focus Group Testing & Feedback

It’s essential to evaluate how well you’ve hit the mark by putting your ideas in front of actual users. In part three (Collaboration) I outlined methods in which the design team and the client can seek to engage with the intended audience at the earliest stages.

When you move as quickly as possible to bring a project to life in the browser, this often means requesting feedback as you build, so that you can iterate based on the results.

An extra set of eyes is always helpful, but not if you can’t gauge the response. Too often testing comes post-launch, so its good to identify some level of prototype feedback – at points you and the client can designate around build progress, probably with an assigned focus group. This additional round of testing helps ensure that as few stones as possible are left unturned in order to deliver a project that has been rigorously evaluated.

I’m a big fan of the dynamic feedback form. Something as simple as an expand/collapse feedback form on every page does the trick. It’s inserted as a CMS or PHP include, and we like to use a few variables to dynamically insert the page title and send any other vital developer information (OS, browser info, screen resolution, window-width etc) with the user’s comments – either to email or to the CMS. This feedback prior to launch is invaluable, and often very frank. Accompanying information manages their expectations, so if it’s a navigable grey-box wireframe site, we explain that, and ask them to look at something in particular. Focus groups are often much smarter than many give them credit for.

Other notable possibilities for prototype testing include more complex crowd-sourcing models, where users can provide on-page feedback by perhaps clicking from given options, multiple-choice responses, or filling in blanks by building real data.

I also like Andy Clarke’s method for implementing descriptive overlays with CSS positioning. This allows the developer to place notes on certain pages to put the prototype into context.

Note: Slides designed by Gregory Wood.

Quality Control & Assurance

It can be beneficial to identify members of the team who will be responsible for quality-controlling certain areas throughout the project – such as a CSS lead, a CMS lead etc. This puts responsibility in the hands of members of the team, and they then develop the ideas and establish agency-specific conventions. Naturally, any of us can contribute ideas or suggestions at any time, but it’s good to have someone fostering your CSS and making sure it’s as good as it can be prior to any releases.

On Convention

We all understand the importance of semantic naming conventions; of the stylesheet cascade, of JavaScript frameworks and unobtrusive implementation; of choosing a way of writing code and sticking to it. There are many different ways of doing many different things. My naming conventions might differ from yours, and my way of ordering my CSS might clash with your own.

This can be taken a step forward and given clarity by setting out a suite of files and resources that kick-start any build, whether final product, prototype etc. You can call it a framework if you wish, but I don’t. Anyway, there are good reasons for working in this way:

• Allows better collaboration within the team; the designer can jump into the developer’s code and vice-versa.
• Anyone who hasn’t even worked on a certain project can jump in and quickly solve problems because everything is on convention.
• Keeps output fresh and ensures use of best practices.
• Establishes a thoroughly connected layer of base files allowing for swift CSS and JavaScript implementation and other assets.

HTML and CSS examples

For example, in the head element of our web pages, we use comments to clearly define meta data and links to external files in a set order. We use conditional comments to always prepare for serving alternate CSS to IE versions. There are many conventions on view here.

In our main CSS file, we add a Table Of Contents as we build, making it easy for anyone to quickly find a chunk of CSS. That TOC is in place from the start, so the designer can simply begin adding to it. Note also that we import our own reset.css here – so we all know that browser defaults are turned off on all projects.

Finally, we all approach writing CSS in the same way, in our case single lines for each selector. Not everyone likes to do it the way we do, but we are happy. So, its become a convention, right down to the spaces between rules and brackets.

The Ultimate Package

Over the last two and a half years, we at Erskine have worked together to develop a base layer of rules and conventions that act as starting points for HTML, CSS, JavaScript and ExpressionEngine for our own projects. It’s a bumper compendium of cascading and connected CSS files, naming conventions, modules, plugins and library scripts that ensure any project led or worked on by any member(s) of the team will stay on convention, and be simpler for anyone else to step into and work with at any time. This includes:

• Basic HTML files & naming conventions
• CSS: Stylesheets, IE-specific, reset, scratch files.
• JavaScript: jquery, function file, transparency support
• PHP for basic templating prior to CMS integration.
• Other Assets such as set folder names for images and CMS stuff
• Essential CMS set-up procedures, plugins, modules etc

Constant iterations of the package are made – we’re currently on version 1.9 – and it’s available internally on our systems with a changelog, meaning anyone can use it as a starting point for both agency and personal projects.

We’re constantly considering HTML, CSS, browsers, JavaScript, naming conventions, CMS usage and any improvements in general methods or implementations. It isn’t publicly available because it is ours – bespoke, custom, built especially for our purposes suiting our needs. If you like the idea and general approach, you’d do worse than to build your own constantly evolving package.

Note: Slides designed by Gregory Wood. he is also responsible for the label Ultimate Package. Good work.

Organic, Collaborative Process

So, here’s another thing that I truly believe in. Organic, collaborative process. What does this mean?

Well, if a team work smartly through a rigorous process-driven route, and are collaborating as we’ve discussed, then surely any project with such a strong backbone can afford a great deal of creative vigour?

Armed with the facts, the aims, the objectives and the goals, a team will often labour meticulously to examine problems and produce wireframes, comps, or functioning prototypes etc, but before all of that (and yes, I will talk about prototyping in the browser in part eight) we can often advance a project dramatically simply by going for it here and there.

For example, either one person or a huddle of people might get ‘round a machine, fire up the apps and browsers, and just bloody go for it. Go mad. Trying stuff, throwing images in and out of Photoshop, layering stuff, messing with type, doing it all in Transmit hooked up to Textmate, testing it in browsers, iterating it, trashing it, fiddling with it etc. Intense, rewarding, blazing of problems has often produced phenomenal results for us. At the very least, its good to cut loose and just experiment.

There are lots of “yeah, try it” moments, rather than intense verbal debates over minutiae. You sometimes have to act with confidence and speed. Deal with minutiae later.

Some disagree, eager that we first work out the tiniest details before opening Photoshop. I agree with that, but I would also trust experienced designers to know when to be careful, and when to experiment. At least, a day of crazy creativity will result in many ideas, some of which will be seen through to fruition, others which might inspire or evolve with care. Either way, so long as there is a strong backbone to the process, we can surely afford to cut loose and see where it takes us.

Scrapbooking

Now, we’re making time for creativity in our process, but how do we inspire it? Sometimes it just flows, but often we might want to surround ourselves with ideas relevant to a project, or soak up inspiration in more subtle, ongoing ways.

Two years ago, Jon Hicks talked about being a “creative sponge“ at @Media. Much of what he discussed related to classic scrapbooking, and is still relevant.

Moodboards

If you’re thinking “moodboards”, let me revisit my on-stage rant for a second. I do think that there is an unclear distinction between scrapbooks and “moodboards”. For the curious attendees, I’ll reveal that I was referring to Bronwyn’s article. I respect Bronwyn a lot, but disagree with that post. I’d like to declare that the moodboard is NOT dead. Bronwyn described moodboarding as a “desperate” technique. She said that moodboards are “insulting to professionals”. I would never tell anyone that you should or should not use any specific methods, nor would I question the techniques or ideas you use yourselves if they benefit your processes.

If your moodboards have “absolutely no point of view whatsoever” then give them a point. Don’t make moodboards for the sake of it, but make moodboards because you have a clear problem to solve, and because you think some visual stimulus will help with that. You can still do some sketching, or play with Photoshop, or build an idea out of paper. Just because you used a moodboard doesn’t mean you are a flawed designer. End of rant.

Flickr Pools

Anyway, back to scrapbooking. I’ve long used Flickr pools to invite clients and guests to contribute to scrapbooking early in a project cycle. It’s another democratic approach to collaborative design, and it’s all broadly framed, so we never have to say “Ah, that is naff, what are you thinking?”. It’s more a case of getting inside a client’s mind and seeing how they tick visually. Sure, they may then reference something they uploaded and ask you to emulate it, but if we’re smart we can simply use this to gauge their expectations and do our own creative thing as a response.

Now, since Hicks spoke in 2007, there are a few new tools out there we can exploit for this purpose. Lets take a quick look at a couple.

LittleSnapper

LittleSnapper is a brilliant tool for grabbing images, screengrabs etc on the fly, within the nifty desktop app, or the online counterpart. The in-built browser assists with taking full-screen site grabs where a human interaction triggers a layer of behaviour – perhaps a JavaScript-based expand/collapse or other choice.

Dropbox

On the face of it, Dropbox is simple. All users will know that it allows you to manage files across several computers. Dropbox creates a folder on each machine that you simply drag or copy/paste files and folder into, and then syncs these to their storage servers.

I’m finding the sharing of Dropbox folders particularly useful. For example, I have a folder called “Colly and Greg”. Our Greg is also a Dropbox user, so I created a folder and then invited him to use it. He and I can now share images, ideas and inspirations by dragging them to that folder. It’s instant and encourages collaboration.

When you install Dropbox, it automatically creates a folder called “Photos”. Now, any folder you drag into there will become a gallery, and its contents will be browsable as usual via finder and Quicklook etc.

The cool thing here is that Dropbox will also create a set of galleries via its web interface too. So, I’ve archived loads of stuff old and new and have a smart menu of galleries at my disposal.

I can then select any gallery to view it’s contents via the web interface, or Finder on any machine. All my scraps in one place.

I’ve created a new photos folder called “scrapbooking”. As I trawl the web finding interesting ideas or images I can easily drag them directly to that folder’s alias. Or, I can screengrab an interesting idea and throw that in there too.

This takes seconds, and encourages me to keep scrapbooking. The beauty is that my scrapbook will be synced to all the computers I use, so the stuff I collect at home is also in my finder at work.

It works collaboratively too, as I can share any photo folder, and provide the public link with each gallery I view. So, all my colleagues can, if I desire it, have access to my scrapbook and download any images I have collected.

Mental Scrapbooks

Briefly, lets not forget how useful our brains are at storing ideas and inspiration. I, like many, have often cited the importance of seeking inspiration anywhere and everywhere we go. It sounds trite, but music, film, architecture, fashion, graphic design, newsagents – they can all have a contributory influence in how we create for the web.

If anything, perhaps the worst form of inspiration is other websites and interfaces! The real world and culture often have so much more to tell us about ourselves.

Then, bring it all together in your collective minds, and also into the…

Physical Project Space

You can’t do it all online or store everything in your noggin. Maybe use Flickr pools, iPhoto, Dropbox etc or some other kind of online scrapbooking, but ultimately a physical project space is a brilliant tool.

This is beyond the mere moodboard. This is a designated space in the office where we collate sketches, cut-outs, ideas, early wireframes, iterations, magazines and pretty much anything. It acts as one big physical scrapbook and a catalyst for discussion – a place to meet colleagues and drive the ideas forward. If you get stuck, or need inspiration, look up and there is all the progress or ideas so far, like a giant storyboard. We sometimes might lay out a whole site like a magazine publisher would pre-print. Oh, and by the way – it all looks bloody impressive to the visiting client.

Note: Slides designed by Gregory Wood.

Simplicity

I’ll begin with a couple of quotes from two renowned authors.

When writing, Elmore Leonard tried to “leave out the parts that people skip”.

George Orwell tried to write text that lets you see the subject without noticing the words that convey it. He called it “transparent writing”.

I am also one of those old web designers who always cites Steve Krug’s superb usability book “Don’t Make Me Think!” It fits so many conversations and situations, and it sums up the way people use the web.

In tandem with that, I adore those two quotes from Orwell and Leonard, and I try and think about them during key decision-making, whether regarding audience modeling, feature requests, requirements, content-authoring, IA etc – anything in the process. If something needs too much explanation, or requires the user to think rather than do, it probably doesn’t work. We can apply the advice of Orwell and Leonard in our roadmap.

It is key that we define a roadmap for a website’s development at the earliest stage. This will remain flexible, but needs to ensure both sides can identify what features will be implemented during which release, or added as additional functionality outside of an initial costed project. These principles contribute to our roadmap quite clearly.

Content Audit

As part of defining a roadmap, a Content Audit gets the client team working hard and really thinking about what they have and what they need – and what their audience needs.

• It measures scale, reach and sheer quantity of content with existing sites.
• It identifies pitfalls – sullied content, migration issues.
• It helps devise a Content Strategy.
• This strategy in turn identifies fresh copy requirements early on.
• We can collaborate to devise a re-write-for-web plan with the client team. This helps us squash the repurposing of press releases and horrid bloated copy from a website.
• We can identify the most important or most recent content to be included, with a plan for adding less important or older content running up to or after launch.

This kind of audit doesn’t have to be time-intensive. If anything, getting this right saves wasting time later on. It’s one of the most vital tools that we can use, and properly scoped out, it avoids those niggling disagreements later on about quality and quantity, and who’s uploading what etc. It saves us money to have a Content Strategy based on a Content Audit.

Features vs Requirements

It is a clear mistake in any project to jump on a feature and consider it a requirement without being careful to understand the problem and the expectations around a proposed solution.

Understanding this, and the impact it has upon what we create helps us better develop a successful website. We must prioritise requirements and only work on the highest priorities (based on key Goals) first.

We can also look to identify what is needed to begin with – what sections and features are key to the initial release, and what features might be held back or added through further releases. It may well be that everything goes in with the initial release, but this needs to be clearly defined in the roadmap. In essence, we’re talking about releasing features and tools simply, carefully and efficiently. We can then inspect and adapt the roadmap throughout a website’s lifecycle.

The roadmap is again something that might only be written when there is a true understanding of the intended audience and the weight of existing client collateral. It may be re-written, amended, scrapped, iterated after launch, before launch, anytime. The key is that it acts as a spec document to outline what features or tools might be implemented, and with which release of the product. But its broader than just a document – its a bit of a philosophy.

Iterating the roadmap can be done on the fly, but a good features roadmap is like a good business plan. If a client is involved, this is essential to building a long-term relationship, and managing expectations. When you are building a complex system, it pays to have a plan.

Note: Slides designed by Gregory Wood.

In an ideal world…

Here’s a contentious approach that doesn’t always work in the real world. We know that we must often agree a budget and deliverables before work begins, and therefore it is rare that a client will trust a web team to make major decisions about exacting methodologies and deliverables once the process is running. It requires both sides to take a leap of faith at the very start.

Client collaboration is again key here, and should be valued over laborious contract negotiations because all parties need to be working toward the same set of goals. Yes, contracts are necessary, but the terms and details in a contract can exert great influence on whether the different parties are embarking upon a collaborative or a competitive effort.

So, after we gain an understanding of a business and its audience, we are faced with considering how we will use this research data to come up with a successful website.

And what kind of methodology will we use? It’s my belief that this decision is difficult to make at the early research stage. Often, only once a deeper understanding of the overall goals, and the needs of the intended audience is attained, can we make a decision on exactly which methodology to work with.

Sometimes a project will start, and there will be deliverables along the way, then it will end. Occasionally, we’ll need to manage projects as a series of phases. Some phases depend on the outcomes of others and therefore are worked one after the other, while others can run in parallel. There are many possibilities.

Waterfall

Waterfall: Research, process, build, test, launch, pub.

This is the most traditional project management methodology, usually referred to as a “waterfall methodology”, and it would be divided into recognisable phases such as Specification, Design, Build, Test, and Launch, each dependent on the outcome of the one before. Its referred to as a waterfall because development is seen as flowing downwards through the phases. The problem is, its all well and good doing so much upfront planning in the Specification phase, but when you get to the Build or Test phase, what happens if you realise you’ve planned for the wrong outcomes, or that the design you’ve created doesn’t quite work now that the site is being built? Its very difficult to go back up the waterfall! Still, many often find themselves working this way.

Agile

Agile: Research, process, build, test, launch, pub. Learn, repeat, relaunch, pub. Learn, repeat, relaunch, pub…

“Agile” means many things to many different people. Most likely, it means working in short iterations rather than using major phases. It is important to collect early, frequent feedback on each release and the processes, and then iterate, repeating aspects of key processes, building upon what has been learned, and ultimately releasing a better and better website over a project’s lifecycle.

Agile methodology is a response to change because our focus is on delivering as much value as possible to the project’s client and users. Rarely will users know every detail of every feature they want. It is inevitable that users will come up with fresh ideas, and perhaps just as inevitable that they will decide that some features they want right now will become lower priorities later.

For example, maybe an initial simple site should form the first “release” with the base level of user interaction required to meet business goals and audience needs. Of course, even a simple release needs to be thought through carefully, and measurably effective – but with room to develop and grow through further releases. With an Agile approach, everything remains open.

Sprint

Sprint: Pub. Build, test, launch. Pub. Nervous breakdown.

I’ve little to say about the Sprint approach. It doesn’t appeal to me, but can be successful if the client and web team can collaborate effectively and swiftly through the discovery stages. In my experience, its usually the audience who gets left out of the collaboration. They often simply get what they’re given.

Process Structure: Rinse and Repeat

Ideally, we can design a relevant agile process, embark upon it, and then iterate that process, rinsing and repeating key areas of the process as feedback and understanding builds with each release, so we’re gradually releasing better products with more relevant tools or refinements.

How are we doing?

I should be clear that here at Erskine Design we are still struggling to find opportunities to work in a truly agile way. It is something we are learning to do, and we’re taking a step closer with every refinement of our processes. Elements of what we do might be considered “Agile” in approach, but matching our agile ideals to our actual real-world projects is a long road. Right now, we’re just making sure our processes are as flexible as they can possibly be.

Note: Slides designed by Gregory Wood.

Accountability

We often talk to clients about the audience “to whom they are accountable“. This is our way of explaining that we can’t wave a magic wand, that we need to collaborate through research, and that the client will contribute a lot to the process. You should be ashamed if your website doesn’t meet your visitor’s needs. Users of a product should be the main focus of our collaborative efforts. They are the people who are personally utilising the product to accomplish their goals.

The user groups that should be of highest priority during the project should be defined, and their needs and potential frustrations should be put into context.

Audience Grouping

I’ll briefly discuss a couple of methods we use in order to work with a client, or internally for our own systems, to better understand the audience. We need to set goals, investigate options and use our processes to reach conclusions.

I find it easier to discuss aspects of a project when referring to an audience group, rather than individual user profiles. Its sometimes referred to as Segmentation, though this often divides the audience by typical demographics such as age, sex, location etc. With my preferred kind of audience grouping, we look to create unique groupings based entirely on the anticipated or existing visitors the website will receive.

Its a case of “Well, yeah, but what would Group X do in that situation? You hadn’t thought about them…”. More typical User Personas can be real or invented, and that old faithful method can be very important in certain scenarios. However, a better foundation is arguably to work in broader brush strokes and think in terms of groups.

Logo Visual Thinking

Lets enter the scary world of business management and training solutions!

“Logovisual thinking uses simple tools and structured processes to bring about profound learning – enabling individuals and groups to think much more effectively, to solve problems, design solutions or make sense of complexity and change.”

Basically, we’re talking about magnetic hexagons.

At Erskine we have several boards and umpteen sets of these things. We use them for almost everything. Always have. Essentially, LVT tools empower a design team or a room full of workshoppers like little else. Visit Logo Visual Thinking for more details. Lets take a look.

LVT Example: ErskineLabs model

For our own ErskineLabs site, our team got together to try and identify all the possible uses for the site, all the ideas, all the fun, all the seriousness.

We then begin to group the hexagons, identifying similarities, problems, weighting the popular and unpopular and so on.

The outcome can be centred around a specific area of research, or can be accidental. The boards will stay around for the project’s duration, and we refer to them, or move stuff around. We photograph and iterate the boards as we go.

Sometimes, we (two or three of us) and the client team and invited guests (four or five of them) get stuck in with the hexagons. Each person is given a pen, a pile of hexagons, and a task. This one is very complex. We sometimes use a “Who, What, Where, Why, When…” model, and the possibilities are endless.

Audience Grouping with LVT

So, how do we use these magnets to define Audience Groups. Well, we might ask guests to list all types of user they can think of – anyone. Not just “press” or “businesses” or “government’, but more specific, deeper users. Perhaps “geography student”, or “art teacher”, “newspaper researcher” or “unemployed rat-catcher”.

They’ll write one on each hexagon, and because its quite anonymous, even the quiet attendees get involved. It is very democratic, and allows everyone to contribute. Then everyone gets together, all the hexagons are pooled and weighted, and the grouping can begin.

Post-its Examples

You can also use plain old post-its for similar research. Whilst the LVT magnets are much more flexible, the tools aren’t necessarily important. It’s all about empowering the client or the team, and defining audience goals or outcomes early on, or on the fly as you go.

Audience Hierarchies

With a typical “who is our audience?“ exercise, we can then group the magnets on the boards and identify a small number of key audience groups.

Next, we established a possible hierarchy. Which is the main group, which less so etc. We will then use these audience types as key reference points throughout the whole process.

Audience Grouping Models

Finally, we can use this information to assign common denominators and create lo-fi task models for each audience group. For example…

• What is their most important page?
• What is the next action they might take?
• Detail a few specifics relating to the project.
• If we have nothing for them, do we offer a sweetener?
• Define an ultimate action or outcome – what do we want them to do?

We can repeat this for all audience groups, and then refer to these groups in subsequent decision-making and process.

These task models take the important but traditional sitemapping a step further by identifying the various courses of action that a user may traverse within a section of the site, adding greater strength to the Project Backbone.

Note: Slides designed by Gregory Wood.