RFP Advice to would-be clients

Generally speaking, I don’t get sent RFPs – most of the organizations that have to create RFPs simply would never think to send them to someone like me.  This is part of the reason I work where I work.  However, I often spend an ungodly amount of time trying to figure out how best to meet your needs, would be client.

This is a great little piece that clearly spells out the kinds of things you ought to be thinking about before asking me if I can make you a website.

https://www.palantir.net/blog/how-write-rfp-attract-best-response

Too much content

My gut reaction is that there’s just too much shit on sites that doesn’t matter.

Sites are over engineered, over designed, over written, over weight.

And although there are some compelling “minimalist” sites (which frequently require just as much heavy lifting just out of sight), that’s not what I’m talking about either.  One can be too minimalist, just as one can be too Modern or any other style.  And! Some minimalist sites push minimalism as an agenda too far, good information architecture be damned.   (a worthy critique of the site you’re on, by the way)

But then there are a sweet spot of fantastic visual design, excellent copy, and suitable development.

One example that I had ZERO to do with is Columbia College Chicago’s site. www.colum.edu

In addition to simply looking great, there’s a little PHP to handle online forms, and that’s it. It’s just HTML, JS, and CSS (from the looks of it, it’s Foundation 5 SASS originally).

They also deleted 97% of their pages and applications went up 80%.

They thought about what it is they needed to say to be useful for their readers, and had the discipline to get rid of stuff they no longer needed.  That’s how you get results.

Content Strategy is not content marketing.  Don’t let too much of one destroy your site.

Joining Spry Digital

NEWS:

I’ve taken on a full time, big boy job at Spry Digital as a front-end developer.

I really love it there.  One nice thing about freelancing is that I did not feel trapped into taking a job just for money, although the steady paycheck is nice.

This was the right move for me and my family for a couple of reasons.  On a personal level, my wife has been doing yeoman’s work with her steady job and a lot of work around the home during my freelancing time and it’s only fair that I help bring stability and comfort to our home life and a steady job helps with that.

And it is exactly that.  It is not just a good place to work, but a great place to work. Spry and I have a little history. I met the owners in early 2014, and they even offered me a job all the way back in summer 2014.  I didn’t think it was the right opportunity for us at the time,  but we kept in touch.  Very important to all of this was that it was not a one-way street: whenever I asked to meet up, chat, or anything, they always made time for me, and that level of personal concern absolutely means something.  It was clear that the owners do not consider their team members to be cogs in a wheel or resources to be mined, but real people with dignity.

In August, one of their developers moved on to another city.  There was an opportunity to help with a project (which you can see here) and a chance to see how we’d work together.  There’s always a learning curve when working with a new team, and we were both happy to see that I fit in well with them.

When they made an offer to me, my wife and I prayed for guidance and talked it over.  It was a fair offer, and I enjoyed working there, but was it the right thing? I think it was (obviously, I accepted), because of these things:

  • Team – one thing that sets this place a part in my opinion is how team oriented it is. No one feels above doing anything. They really take their belief that creative work (and a functioning office) is a team sport seriously. Everyone here is a little bit nerdy, and very kind.
  • Depth – when you freelance, you maybe spend half of your time running your business – bookkeeping, marketing, sales, networking, learning – and maybe half of your time on project work. It’s great because you develop broad skills that help you be good at many different tasks, but you can get technically and creatively stale from having to task switch all of the time. Working inside a team like this, I know I’ll be able to spend more time getting better at the craft of front-end development.
  • Impact – This goes hand in hand, but typically as a freelancer you’re either working on small projects that you can do by your lonesome or discreet projects that are a part of larger projects and either way it can be difficult to look at and say that your work made a true impact.  With this team and their roster of local clients, arts and education clients,  non profits, and civic organizations it’s easier for me to see how my work will make an impact.
  • Less Stress – When you freelance, everything is on you. Working with a team like this,  I don’t have to worry about every minute aspect of every project. I just have to focus on doing my job well. It’s a nice change from feeling isolated on every single roadblock for every single project.
  • Fun – Like I mentioned,  everyone here is slightly (or not so slightly) nerdy, and very genial.  It’s a solid, mature professional environment with a healthy amount of fun in the mix.  Laughing is pretty common and it’s small enough to avoid cliques. It’s a good culture to be in.
  • Opportunity – on several levels. First, it’s a stable company approaching 6 years in business with year over year growth.  The management team have decades of experience and know how to bring in work.  With more people slated to come on in the coming year,  I know I’ll be able to advance.  And I’ll have the opportunity to contribute not just in my specialty, but to design, client relations, business development, and client support.

It was the right thing at the right time and I’m really happy about our decision.

What does that mean for freelancing?

Well, I’m still figuring that out.  This company has no problem with me moonlighting on personal projects, and I like the work, so I don’t imagine stopping altogether.  I also am able to bring work in to Spry, so if you have questions about that, please email me!

I think the nature of what projects I take on will have to change,  but even with that I’m not sure what to think or which direction to head. One clue is that I will be much much more selective about outside work. Projects like Holy Communion’s new site hit a sweet spot in terms of client expectations, attention, and time demands, along with the X factor of an intrinsic attraction to the organization I was helping. Because I can afford to not take on projects just on budget and time, the satisfaction factor of a possible project will play a huge role in determining whether or not I will take it on.

 

Pricing Strategies for Designers

Recently,  a friend of mine decided to take on some consulting work for a start up here in St. Louis.  He reached out to me and asked:

I was asked to put together a plan to increase a startup’s average revenue per user — which I did — however, now I need to give them a set number of hours to get the project done. As I’ve mentioned before, I don’t do a lot of consultant work so I have absolutely no idea how to determine this.

My response was:

The first is I might reject the premise of the question altogether – Hourly work is fine and all, but you just put together the game plan for them to make a lot more money. So I might try a value pricing approach, something like 10% of the expected growth in AR/U multiplied by their user base – I’d use round numbers so the math is easy for them to understand when you pitch it. Like

(example)
Current AR/U = $100
New AR/U = $110
change = $10
10% of change = $1
Multiplied by Monthly Average Users (10,000) = $10,000. 

You can then break that amount up into as many payments as you think you’ll need over the course of it.

If they can’t grasp that you have earned a share of the reward, then you shouldn’t pursue the project further. (IMHO)

If that’s not kosher, I might just try a fixed price bid.  A fixed price can be a wild ass guess for all they know.  The nice thing for them is they know what you think it is worth and they know what they will pay. The bad news is, you now just have to make it work on that amount.  (For small projects this is not a bad thing – companies routinely outsource things they are inefficient at to experts who are.)

If that’s not going to work because the project is too big, estimate a timeline and establish a monthly retainer, i.e. 3 months at X amount of dollars paid each month by the 5th.  Monthly retainers are great because everyone knows where they stand, the bad thing is you have to deliver every month you have them.

Last, Hourly you need to break the project down into it’s smallest pieces, guess the time for each piece, pad it appropriately (to account for project management time, setbacks, workarounds, etc), add it up, and then I give them a range, like this.

“Based on my estimate, this project should take between 180-240 hours of my time and will cost between X-Y.”

Giving them a range is important so they can budget appropriately and account for changes during the project.

The conversation was in an email, and went on a little bit past that.  He’d never heard of value pricing, but was intrigued.  I cautioned him against going all in on just one pricing strategy:

All of the pricing models work and have been around for a long time.  The only right answer is the one that works for you and them that you can agree to.

The only other things I tend to do with contracts are:

1) a non-refundable deposit
2) a kill fee (an amount they agree to pay if a project is cancelled or indefinitely delayed) usually 1/2 of the remaining balance paid as a lump sum. In exchange,  it acts as a final payment on a contract and you hand over your work.

both of these are non-negotiable in my contracts.

the deposit works just like an airline ticket – it will reserve the time, headspace, and resources you need to start a project. Most importantly it allows you to say No to other offers (b/c you’re in demand, duh). Kill fees are project insurance –  if something goes wrong, you still get paid for your work.  You don’t buy a car without money down and without buying insurance, and working with me is the exact same thing.

To recap, there’s 3 basic ways for designers to price their work:

  1. Value Pricing, where the designer estimates the value add to the business the client – which is an ideal scenario because the incentives are aligned.
  2. Fixed Price, where both parties know exactly how much the project will cost (and then the designer is on the hook to make sure it is profitable for them).
  3. Time and Materials, where the designer knows how much it will cost (rate x time), but the client doesn’t know how long it will take.

Retainers are a kind of bastard child of fixed price and time and materials, in that X dollars buys the client Y time.  There are many many ways to price your work, and ultimately you don’t need to choose only one.  There are many prominent designers, like Dan Mall, who swear by value pricing.

I tend to agree with them.  As a designer (and really, just a competitive person), I’m always confident betting on myself.  I’m confident defining problems and building solutions, and when I make a value pricing proposal I’ve already done both.

Pricing Strategies for Designers reviewed:

Sometimes a fixed price is a necessity; especially when dealing with governmental and NGOs who often have RFP (request for proposals) that require an all in bottom line number. Fixed price does have the drawback of scope creep.  Like any business, designers have to make a profit. Every additional minute not estimated for in a fixed cost eats into that profit. From the jump, a client’s incentive to get their money’s worth is at odds with your incentive to maintain your margin.

Time and Materials inverts those incentives,  but can work out for everyone (if they are honest). Sometimes hourly makes sense too, but I will say that for experienced designers, it can be a raw deal both due to efficiency and rate resistance.

Efficiency is just being better at something than the next guy.  If it takes a less experienced designer 10 hours at $50 to do an assignment, and a more experienced designer only 3 hours to do the same task but $100/hour, is an experienced designer really supposed to be paid less for their work? How does that make sense?

Rate resistance is similar.  There are very few professions that Americans are comfortable paying more than $150/hour for. Lawyers can charge more –  but there’s significant barriers to becoming a lawyer. There are far fewer for a designer.  There’s also the simple fact that you have to bill hours to get paid. With just hourly pricing, if you aren’t working for whatever reason, your cash flow stops.

I know that I am personally moving more toward value pricing as more dominant strategy.  I am finding it requires more trust on a potential client’s part to figure out how much value I can add, which is a good way to determine if they’d be a client I want to work with in the first place. Later, I can point to how much value I created for them as part of my marketing and sales to future clients.  To me,  I think this is a method that takes a little more thought up front, but is ultimately the best strategic play for a designer.

 

Common Biases and Design Corrections

If design is the rendering of intent, then the two important things are the rendering itself (execution, tools, quality) and the intent behind the design.

Where most projects of mine have struggled have been with the intent behind the design.  Decisions get made without regard to the projects’ objectives or constraints, or in an arbitrary way.

Fortunately for you,  Business Insider cataloged some common biases here, adapted from Daniel Kahnemen’s Thinking Fast and Slow.

In my limited experience, I’ve noticed these three biases most often:

  1. Group Think
  2. Confirmation Bias
  3. Halo effect

The best design corrections for 1 and 2 is unvarnished User Research.  No, I don’t mean Surveys, either. Great Ethnography makes it much more difficult to ignore dissenting or contradictory opinions because there’s an actual human on the other end of the discussion.   It also does not take very much time, budget, or effort to do a passable job on this.

The halo effect most often takes the form of something like “He’s a wizard” or “She’s a rockstar” [insert title du jour]. As designers, our reputations work for us in winning projects and counter us in executing them.  Bad Clients erroneously equate reputation and rate for miraculous and obsequious – it’s our job to set and enforce working boundaries.

That’s why it’s important to explain that Design is a craft, not an art and certainly not magic; to explain (ahead of time) our process, needs, and timelines;  to show our work iteratively so they understand we’re not nailing it on the first crack; to measure our value in concrete terms, and to help clients understand their role in the process.  Design Corrections start with shared beliefs, taxonomy, and language about the project.

Research and project management are core design skills because without them you’ll build the wrong thing.

User Error: Addressing Cognitive Bias in Design

My Father in Law, as far as I know, never lent a book out until I asked a few years ago. It was an unopened (as in still shrink wrapped) copy of Don Delillo’s Cosmopolis as an audio book that was on top of a ramshackle stack of books, tapes, and other junk in the garage, apparently collecting dust.  He was not pleased at my request and begrudgingly went along with it, probably to please his wonderful daughter.

So imagine my surprise when he just up and offered to loan me a book!

This past month, he offered me to take back his copy of The Martian by Andy Weir. Great Book, I’m sure the movie is great too although at time of writing I haven’t seen it.

In The Martian, astronaut Mark Watney gets stranded on Mars and has to McGyver his way to surviving long enough for a rescue attempt. What’s fascinating is that for large swaths of the novel it is literally just Mark thinking a loud.

Most of the Science-y stuff you’ll remember from high school (if you were paying attention), so one of the things that stood out to me was Mark’s thought process.  In the name of making a compelling story, I’m sure it was more roundabout and error prone than a normal astronaut’s thinking may have been, and this part of the book resonated for me in my line of work.

Although there are many complex tools out there, producing great looking sites and applications has never been easier.

But, that’s never been the problem.  It’s a good problem to solve but the real problems are not easily solved by tools.

Things like:

  • Do I understand how my business makes money?
  • Do I know who my customer is?
  • Do I understand how to shape the experience they have with our brand/company?
  • What are we going to make or say for these customers?
  • What activities do we need to do to make these plans work?

It’s not the same scale or urgency as being stranded 12 light-minutes away on Mars, but these are the same kinds of problems and designers like us should focus on helping clients answer these questions and be able to follow through with the design we spend so much time crafting.

For instance, how many times have you gone back to a client site to find a page you spent weeks crafting mangled beyond recognition because they’ve made changes?

Typically the client has no idea that they may be doing more harm than good.   And I’ve been blamed for human error on these things before too.

One solution has been to write service manuals or guides – I’m doing that on a side project now because there will be at least 4 users writing a lot more than they are used to.  I want to make sure that I build not just something they will use, but will be able to find new, inventive uses for.  The manuals address what they should be writing, when they should be writing it, what happens when they turn in writing, how the writing should be formatted, and why they are doing all of this in the first place.

The hardest part of writing this has been identifying and addressing cognitive biases. The premise is, if I can figure out why a user may make that assumption, I can coach to prevent that assumption, saving everyone a headache.  Modern CMS’s can be edited to include custom instructions, which is particularly helpful for some basic art direction like reminding the user what resolution a photo should be.  Cognitive Bias in Design is a real problem – the need to step outside our normal modes of thinking and to help clients see the limits of theirs is key to creating designs that serve others better.

Becoming a better designer is about helping your clients become aware of, test, and overcome their cognitive biases so that they can succeed.

Wisdom

Berkshire Hathaway Vice-Chairman Charlie Munger:

It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.”

From the article I got that quote from:

I know a few very smart and talented individuals whose lives are in utter shambles despite their gifts. And it’s because they keep making stupid and avoidable mistakes. They consistently add wholly unnecessary downside to their lives.

If they had done nothing really positive, but had simply avoided the DUIs, the drug arrests, the out-of-wedlock births, the affairs, and the consumer debt, their lives would have been vastly superior to the ones they have now.

Let that sink in: doing nothing would have given these people a better life than they have now.

So so much of what I read and people I meet fall in to the trap of trying to out-smart others.  Just avoid the stupid stuff.

IA is hard

You may not have noticed it, but there’s a great piece making the rounds on the interwebs this week.  Here it is:  http://deep.design/the-hamburger-menu/

TL: DR Stop using the ubiquitous but harmful “hamburger menu”.

What’s great about this piece is that it actually makes the really salient point – bad navigation interfaces are the result of bad information architecture (IA) choices.   And IA is hard.  In fact, it may be the most difficult thing we do.  We’re making up nimbus structures of words and abstract objects to fit together coherently and clearly for people we’ll never meet.

And clients what they want.

Why Information Architecture is Hard

It’s hard enough (especially without proper research budgets) to convince clients that the information they think is important and the information you’ve discovered to be important are not the same things; try getting them to accept that they only need the information that’s actually important.

What results are really bloated menus,  and of course,  because all of that information has “priority”, they all end up in the same place in the requirements document (what we end up building off of).  Hamburgers are a logical result of a broken client process.   They elegantly cram lots of information in a neutral enough icon.  Given that they are simple to construct and come pre-packaged in many front-end frameworks, it’s very easy to implement, which helps to sweep the IA mess under the rug.  When you can hide everything in a closet or a drawer, why would you ever actually clean it up?

But we know that approach is a band aid.  Take the time before you get to the interface to:

  1. Know what it is your users are supposed to do at your site
  2. Label them clearly in an organized document
  3. Ruthlessly remove other information

Clarity in information architecture results in sites that people like to use.  It helps designers avoid cliches in their work, which helps your site stand out.  It gives copy writers a better chance to write copy that works, and it makes it easier to track progress.

Ropa Vieja

Ropa Vieja is Spanish for “Old Clothes.” It’s a Mexican dish that you probably won’t find at many restaurants because, well, it’s not glamorous.  It’s peasant food and the prep could not be simpler: get a big pot, a very cheap piece of meat, throw in stock, vegetables and seasoning, and cook on low heat for a day, give or take a few hours.

The tough meat falls apart in strands that look like torn, worn out clothes. Hence the name.

What on earth does this have to do with design, and specifically design tools?

I tweeted out yesterday that the more I use great tools like SASS and the libraries that it has on client projects, the more I enjoy using plain old vanilla CSS on personal stuff.

SASS is wonderful – I am in no way anti-SASS.  I use the libsass port of Foundation on nearly every client project now because doing so allows me to

  1. become more efficient by doing (repetitive actions get faster)
  2. reuse snippets for common components (saving time, which ultimately means more profit and/or cost savings)
  3. ensures my code is standards compliant (because Foundation is built by really smart developers and a lot of people use it)
  4. Helps me automate performance testing and performance improvements (the libsass version uses Grunt to manage tasks, and is totally configurable.  Again, this saves time and makes adding value easier)

To extend the cooking analogy,  if you’ve ever worked in a kitchen before you know –  lots and lots of prep goes in before the house opens. Some ingredients and dishes can even be par-cooked, so the speed of service (i.e. production) can be sped up to increase profitability. You also know that every dish in every restaurant has a recipe and that every prep cook, line cook and sous chef is expected to follow the recipe.  Following the recipe is not that difficult.

When I write production code,  I am basically following recipes so that I can serve them quickly, with a smile and try to leave my guests (clients) planning when they are coming back next.   But following a recipe and writing a recipe are two very different tasks. Understanding why a recipe works is different than following the recipe.

Which takes me back to vanilla CSS.  Whenever I want to learn how to do something with SASS, and really understand it, I’m going to practice it a lot with vanilla CSS.  The flaws of CSS actually make it a very good learning tool.  To write all this by hand is time consuming, far more than applying snippets.  The action of writing it all out helps me to understand it. It’s a simple method to reintroduce mindfulness and focus to tasks that can be pretty rote once you’ve done them a few times.  By slow cooking my CSS,  I begin to understand what it is I’m doing better and as an extension, can find novel ways of doing things.

Production and practice are two very different tasks, and the tools we use can be different.   If you look at any sport or craft,  most of the practice time is spent on activities that aren’t actually the competitive or production environment.  It’s totally worthwhile to practice isolated tasks (such as, say, making a block grid list) in a slower,  simpler environment.  It’s analogous to taking batting practice, or doing a table read for a scene, or peeling potatoes.  Ultimately, the best in the world at anything aren’t all that special: they happen to be flawless at the rudiments of their profession, and this only comes from lots of dedicated practice time.

So, the next time you set out to learn a new skill, put away the command line and the fancy tools and the things that make your competition or production better. Get back to basics, slow down, and enjoy some old clothes.

 

Word Camp STL 2015

Here’s the Power Point Slides and Notes from My Presentation at Word Camp STL 2015

Notes, links, and analysis of WordCamp STL coming very soon, as well as video on WordPress.tv!

Notes:

Slide 3:

In the next five years, a billion more people will come online. Mobile page loads will dwarf desktop page loads.  The average page load from http archive in the last year grew to 2MB with 100 requests.  Consider that we went to the moon with only 16kb of memory.

The point is, we can no longer consider these as edge cases; these are actually becoming the new norm.

 

Slide 4:

Same reference Source also notes 60.7% of all CMS installs are WordPress.

 

Slide 5:

I want to make the point here, in my notes,  that it isn’t simply about Mobile First.  It’s that Mobile usage is a lagging indicator of how people use what we build.  What I’m making an argument for is better serving these people.

 

Slide 6:

Real quickly on the first point: every single time I’ve taken on a design project where the best thing about it was the money, I’ve regretted it. I don’t begrudge anyone making a living, but you have to stand for more than money if you want to stick around long enough to make a difference.

I will probably write a post on how to avoid bad fits.

Site builders are great.  I’m not slamming site builders.  Squarespace is a fantastic product to quickly turn around a site.  But the degree of control that you ultimately get to exercise is quite limited.  WP never was a site builder, and is now closer to a full fledged CMS – albeit one that’s easy to train a client team on and comparatively easy to maintain – two of the many reasons we love it.

 

Slide 7:

Because, at least for our purposes, WordPress is a CMS, and requires lots of decisions to be used to the proper effect,  making good decisions becomes the most important thing.

— It should be noted that WP can also make for a very useful app platform. In which case, all of this still applies, plus additional concerns about interaction design.

 

Slide 8:

We do not work with anyone who won’t allow us to do research. We are problem solvers and strategists, not production artists.

Common Objections:

“We’ve been in business for X decades, what else will we learn?”  “Isn’t that costly?”

Answers:

“You may know your business cold but I don’t” and

“Would you rather sink a lot of money on untested assumptions or spend a few bucks checking them out?”  Research methods worth using:

Ethnographic Research – in person, open-ended interviews (works best with a partner: one to talk and one to write)

Usability testing –  watch people use what you’re designing and note problems

The Bladder Test – “accidentally” run into people on their way to the bathroom and try to get them to complete a task

Comparative research – know the tropes to subvert them.  Writers are always reading.

Business Model Analysis – if the goal of the site is to make money, you need to understand how they make it, and where your project can fit (or better, how their shit is broken and how you can help)

AVOID:

Surveys. -qualitative data dressed up as quantitative.  requires large n for representative sample.

Focus Groups. – worse than useless

Copying.- this isn’t research but some people pass it off as

Meaningless Data or cheap analysis – If you’re going to involve hard metrics you have to be willing to investigate those thoroughly.  Most designers don’t have that skill set or time allotted, plus they are easily manipulated.

For more,  pick up Erika Hall’s amazing book.

 

Slide 9:

I’ll let the content experts at WCSTL talk more about this but the four basic considerations you want to have thought out are:

  1. What is the substance?
  2. What’s the style?
  3. Who will produce it?
  4. Who will make sure it’s working? (http://www.usability.gov/what-and-why/content-strategy.html)

This is a deep topic and one absolutely worth diving much deeper into,  but I’ve got to keep going.  One other point: having less or micro copy does not mean you get to skimp here.  Also, Content Strategy is not Content Marketing.  I have no idea how to do the latter.

What we’re also talking about here is Content Priority – what goes where and why.  The why will be based on the people you want to read or complete the action.  Which leads us back to the question of how do we best serve them.

 

Slide 10:

Your household and company probably have a budget, so why shouldn’t your next project?

Obviously time and money are important; and the performance of your site effects both (yours and your clients.

How?
For More: Tim Kadlec

  1. Define Early On – should arise from research. -aim for 20% faster than your competitor, as a benchmark.
  2. Focus on Perceived Performance (http://alistapart.com/events).  Keeps focus on people.
  3. Use a set of benchmarks, not a single number.
    1. There’s several different types of measures like
      1. Time Measures – Load Time, DomContent, Total Load – perceived performance will favor faster render rather than shorter total.
      2. Quantity – HTTP Requests, Page Weight  – Weight is fantastic for using with designers to make tradeoffs, especially fonts/images
      3. Speed Index https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
    2. But what’s more important than how much is how you load.

 

 

Slide 11:

For WP,  we can actually make this very very easy.  With some simple modifications to functions.php we can:

1) register and enqueue only the js/css we need

2) do so conditionally – such as with outdated browsers.  (modernizr is a good example)

3) remove a bunch of feeds and other ephemera that WP spits out by default: http://nicolasgallagher.com/anatomy-of-an-html5-wordpress-theme/

4) unlocks some really cool features in WP – menus, widgets, featured images — the list goes on and on and you get to decide!

 

Slide 12:

Four things:

  1. I forgot to mention GZIP.  You should be doing it.
  2. Lara Hogan: http://larahogan.me/design/ Scott Jehl: http://abookapart.com/products/responsible-responsive-design AND http://www.filamentgroup.com/lab/performance-rwd.html and Yesenia Perez Cruz: https://vimeo.com/108328247 For a LOT more on the actual techniques.
  3. What I was explaining about task runners seemed to lose some people.  Basically We have a source or assets folder with our raw, commented,  partialized code; whether that’s JavaScript, SASS/LESS/CSS, Images, or HTML/PHP templates.  We set up a Grunt or Gulp File that will do several things, but chiefly it will – compile SASS/LESS into CSS; Concatenate all of the CSS/JS into one file each; Minify that File; and place the new, minified file in the root. Each step of that will improve performance.  see gulpjs.com for more.
  4. These will help any site but the more decision making you make ahead of production the better the result.

 

Slide 13:

If you want more information about pattern libs, I highly suggest you check out Brad Frost and his work, as well as Joe McGill’s presentation.

 

I’ll make a sample testing matrix soon.

 

Slide 15:

I didn’t go as fire & brimstone as this, but the intellectual, ethical, and political basis for my talk is Mike Monteiro’s call to arms, How Designers Destroyed The World.

You should also read everything the guy has put out – they’ve been my beacon in these murky seas.