You are here


The rejectionists

Seth Godin - Mon 29th Jun 2015 19:06
We can choose to define ourselves (our smarts, our brand, our character) on who rejects us. Or we can choose to focus on those that care enough to think we matter. Carrying around a list of everyone who thinks you're...        Seth Godin
Categories: thinktime

Buzzer management

Seth Godin - Sun 28th Jun 2015 19:06
I started the quiz team at my high school. Alas, I didn't do so well at the tryouts, so I ended up as the coach, but we still made it to the finals. It took me thirty years to figure...        Seth Godin
Categories: thinktime

A corollary to 'Too big to fail'

Seth Godin - Sat 27th Jun 2015 19:06
"Too big to listen." Great organizations listen to our frustrations, our hopes and our dreams. Alas, when a company gets big enough, it starts to listen to the requirements of its shareholders and its best-paid executives instead. Too big to...        Seth Godin
Categories: thinktime

On Our Radar: Precious Humans

a list apart - Sat 27th Jun 2015 02:06

Molly Holzschlag is a great educator, tough fighter, and vital friend of what folks are now calling “the open web,” and she needs our help.

Molly Holzchlag and Jeffrey Zeldman.

She took over as project leader when I left The Web Standards Project in 2002. In that role, Molly did hugely important (and often thanklessly unheralded) work bringing improved compliance, plus a renewed respect for web standards, to some famously intractable browser companies. She also directed The Web Standards Project’s important and multi-dimensional educational outreach effort.

Between those efforts, her two decades of public speaking, and the dozens of web development books she has written, Molly has contributed meaningfully to the foundational thinking and understanding of tens of thousands of web developers, designers, and engineers. If you don’t know her name and her work, you don’t fully understand this industry.

Molly has been diagnosed with chronic pancytopenia, a life-threatening blood disorder, and her insurance is about to disappear. She’ll need the support of friends and strangers to afford lifesaving blood treatments and medications. Pray for her, chant for her, help her if you can. —Jeffrey Zeldman, founder and publisher

Your weekend reading
  1. I’m a big fan of the Library of Congress Flickr feed (mostly for the old-timey photographs of the type that Shorpy cleans up and posts) and recently they’ve been posting old graphic posters from the collection. Like this poster for a 1938 photography exhibition in New York City. The description for each piece links back to the Library of Congress, where they often have very high-resolution images available to download. —Mike Pick, creative director and designer
  2. This week, Wired talked up new startup Doxa, which aims to use an “OKCupid-like” algorithm to match women with tech companies where they’re likely to thrive. It’s an interesting approach to getting beyond “diversity” percentages, and it’s nice to see Wired lead with the truth: “Tech has a diversity problem.” But I was more convinced by Danilo Campos’s take: that “shoving underrepresented people into the existing startup order”—even using smart algorithms—won’t make those organizations actually ready to support diverse employees. “If you’re serving at a place where no one in leadership understands your needs, getting accommodation for those needs can become challenging—or even alienating, when you’re misunderstood,” he writes. In other words, crunching survey data to help women find a better fit might be nice, but real change happens when leadership teams are as diverse as the people they’re trying to hire. —Sara Wachter-Boettcher, editor-in-chief
  3. Richard Rutter has Kickstarted a book he’s writing on web typography. I remember first reading an article Richard wrote for us on the topic back in 2007, and this book has been in the works since before then. Richard lives and breathes this stuff: he helped set up Fontdeck, and has also run several installations of Ampersand Conference. I have a feeling this book is going to be the canonical reference on web typography for years to come. —Anna Debenham, technical editor
  4. I was doing some reading on SVG this week for a project we’re working on. I came across Jake Giltsoff‘s SVG on the Web, a single-purpose site outlining the use of the SVG format. Giltsoff went into quite a bit of depth, addressing the use of SVG as an image type from a development perspective, and responsive approaches to using the format. It’s a bookmark-worthy resource for in-depth or at-a-glance referencing. —Erin Lynch, production manager
  5. I was privileged to hear Leslie Jensen-Inman speak last week, and she explained how adding a single question to the daily stand-ups at Center Centre has helped the team create an environment that is enthusiastically supportive of ongoing learning. “What is the most important thing I learned since the last time we met and how will what I learned change the way I approach things in the future?” In Leslie’s Meet for Learning, she goes into more detail about the ways this open-ended question has changed their work culture for the better. —Aaron Parkening, project manager
Overheard in ALA Slack “I watched a chipmunk suck water out of my friend’s Camelback at the Grand Canyon.” Your Friday gif
Categories: thinktime


Seth Godin - Fri 26th Jun 2015 19:06
Fighters and pugilists are different. The fighter fights when she has to, when she's cornered, when someone or something she truly believes in is threatened. It's urgent and it's personal. The pugilist, on the other hand, skirmishes for fun. The...        Seth Godin
Categories: thinktime

Risk of bowel cancer reduced by taking aspirin for Lynch syndrome patients

Teaser:  An international study led by The University of Melbourne has confirmed that long-term regular taking of aspirin or ibuprofen reduces the risk of bowel cancer by more than half for people with the genetic mutation causing Lynch syndrome.

This article originally appeared in the Newsroom on 26 June. View the original here.

An international study led by The University of Melbourne has confirmed that long-term regular taking of aspirin or ibuprofen reduces the risk of bowel cancer by more than half for people with the genetic mutation causing Lynch syndrome.

read more

Categories: thinktime

Rian van der Merwe on A View from a Different Valley: Unsuck the Enterprise

a list apart - Thu 25th Jun 2015 22:06

There’s something strangely appealing about trying to make enterprise software not universally despised. I guess I believe in a utopian vision where enterprise software is useful, usable, and (gasp!) enjoyable.

But until we get there, I think we can all agree that enterprise software mostly still sucks. And I think it sucks mainly for two reasons:

  1. A lack of empathy for end users.
  2. Too much legacy.

The lack of empathy issue is an understandable outcome of the process. See, we have this piece of software that we sell to company leaders, who care about things like control, configurability, compliance, and how many features the thing has. But the piece of software is mostly used by people who have very different needs.

The people who use the software every day only care about one thing: getting stuff done effectively. And if they can’t do that, a really ugly death spiral happens. As more people realize they can’t get anything done with the software, fewer people want to use it, until eventually no one uses it anymore.

In short, a buyer-focused product strategy builds for features and timelines. A user-focused product strategy builds for the Job-to-be-Done. Those are very different things.

Second, there’s too much legacy that drags large corporations down. There are waterfall processes masquerading as “agile,” well-established and well-defended functional silos, and many layers of bureaucracy. The result is something Jon Kolko sums up well in “Dysfunctional Products Come from Dysfunctional Organizations”:

The dysfunction in the organization becomes the dysfunction in the product, and that gets passed on to the customers.

How can we unsuck this predicament? Four things have helped me, and continue to help me as we make this transition toward designing in leaner, more empathetic ways.

Show the business value of design

The 2014 Design Value Index report just came out, and it showed something quite compelling about design-led companies:

The Design Value Index (DVI), a market capitalization-weighted index comprised of design-driven companies, shows … 10-year returns of 219% over that of the … S&P 500 from 2004 - 2014.

Good Design Drives Shareholder Value

From “Good Design Drives Shareholder Value” by Jeneanne Rae

So we know design-led companies make more money. But is it also possible for design to save on development costs?

This chart is based on data from the book Software Engineering: A Practitioner’s Approach, and it shows how much cheaper it is to make changes to software before or during development. This quote from Marty Cagan also makes the point really well:

Instead of using one prototyper for a few weeks, [many companies] use the full engineering team for full release cycles to build the software that is then QA’ed and deployed into production systems. This is why it typically takes so many companies three or more releases over one to two years to get something usable and useful. They are using the engineering organization to build a very, very expensive prototype, and they use their live customers as unwitting test subjects.

This is a way to tie user-centered design to both revenue increase and cost reduction. That’s an essential (and compelling) combination to get people to take design and user empathy seriously.

Shrink user-centered design to fit

The biggest reservation that teams at enterprise software companies usually have about research and user experience work is that it takes too long and costs too much. Our job is to show teams that we can still get enormous value from UX methods, even if the budget is relatively small.

That’s the beauty of user-centered design: it shrinks to fit. Can’t do an ethnographic study? Do some phone interviews. Can’t build out a full HTML prototype? Make a clickable prototype in Axure, or heck, make a paper sketch. Can’t do a full usability study? Go to Starbucks Stumptown¹ and ask someone if you can buy them a coffee in exchange for some feedback:

Big budget Medium budget Small budget Explore Ethnographic study Phone interviews Ask a friend Prototype HTML Clickable prototype Paper sketch User testing Formal usability testing RITE Show someone at a coffee shop --> Turn sales into a product design function

This is a big one. I’ve seen enough animosity between sales teams and product teams to last a lifetime. And both sides usually have legitimate points.

Product teams usually complain that the sales team sells stuff that doesn’t exist in the product—and even worse, promises release dates—which means they have no flexibility to base their roadmaps on user feedback and strategic direction.

Sales teams usually complain that product teams don’t see them as partners, and ignore their feedback constantly. This is a huge mistake, because sales teams often know the product’s capabilities and shortcomings the best of anyone in the organization. They should absolutely be part of the development process.

How do you do this? What’s worked for me is to provide a framework that allows both teams to speak a common language. For me, that framework, is Jobs-to-be-Done, and more specifically, the Product Forces Framework.

Product forces diagram, based on

For someone to move from their existing behavior (a product they’re currently using) to new behavior (switching to a new product), there are two types of forces at work: progress-making forces, and progress-hindering forces.

Progress-making forces move people from their existing behavior to the new behavior, and consist of the push of the current situation (things they’re not happy with in the current product) and the pull of the new idea (things that sound appealing about the new product).

Progress-hindering forces hold people back from switching to new behavior. They consist of allegiance to the current behavior (things they really like about the current product) and the anxiety of the new solution (worries about learning curves and not being able to accomplish their goals with the new solution).

For someone to switch from an existing product to a new product, the progress-making forces have to be stronger than the progress-hindering forces. This might seem obvious, but applying this model to your product planning can inject an extremely healthy dose of reality. Is the product really that much better than a current solution? What does the new product have to do to overcome people’s allegiance to what they’re currently using?

This is not only a very good sales strategy, it’s also a good way to gather product feedback and come to agreement on what will make the product better (and help it sell better!).

As for putting a stop to selling features that don’t exist yet… I’ll be honest, that can take some time. But the more the sales team and the product team collaborate (keep reading for more on that) and have a common language, the better this will get as well. There is hope.

Break down silos through collaboration

“Collaboration” has become a pretty overused word, and it’s now difficult to know exactly what we mean by it. So let’s be clear: just because you sat in a meeting with a different team doesn’t mean you collaborated. Collaboration, to me, means that you made something together. There is always some output during collaboration—from a solid idea that a designer can go work on, to personas that everyone worked on together, to piles of sticky notes that eventually become a customer journey map.

This kind of collaboration is especially important in the enterprise, where a designer’s role is often mostly about facilitation.

There are several techniques to encourage real product collaboration:

  • Product discovery aligns teams on the user needs, business goals, and core competencies of the organization. It then goes through a process of divergent thinking (trying as many options as possible to solve a problem) and convergent thinking (narrowing down to the best options). The process also lets a team build consensus about the most important things to work on. For more, see my A List Apart article “Usable yet Useless: Why Every Business Needs Product Discovery.”
  • Design studio gives teams an opportunity to try a wide variety of design options, and come to an agreement on the best solution to go with. It uses the entire team to iterate quickly to a hypothesis that can be prototyped and tested with users. For more on how to run a design studio, see Design Studio Workshop: Adding Up the Benefits.
  • User research might seem like a solitary sport, but it’s not. Taking team members along on field visits and usability testing gives them a real sense of how users interact with the product. It also has the power to make them depressed about how difficult something is to use. But most people break through that really quickly, and move on to solving the problem effectively.

If I can further summarize a way to bring empathy-driven design to an enterprise, here are the methods that I try to communicate to teams I work with:

  1. Show them why it’s important.
  2. Show them it’s not going to make their lives difficult.
  3. Give them a framework that covers the whole product.
  4. Make them part of the process.

So if you’re someone who works in enterprise software, come a bit closer—I need to tell you something…

I know the work can be difficult. I know there are an infinite number of factors involved in getting product live, and sometimes what gets launched isn’t what you had in mind. I know there are sleepless nights about this sometimes. But don’t give up. Don’t think that enterprise design has to be boring or tasteless. With a little bit of effort and a lot of tenacity, it’s possible to create great enterprise product. We need you to make it happen, though. Who else is going to do it?

  • 1. Gotta represent Portland!
Categories: thinktime

Pulling a hat out of a rabbit

Seth Godin - Thu 25th Jun 2015 19:06
It's tempting to do what's been done before, certain in the belief that if you do it, it'll be a little better and a little more popular, merely because you're the one doing it. In fact, though, that's unlikely. You'll...        Seth Godin
Categories: thinktime

The tragedy of small expectations (and the trap of false dreams)

Seth Godin - Wed 24th Jun 2015 19:06
Ask a hundred students at Harvard Business School if they expect to be up for a good job when they graduate, and all of them will say "yes." Ask a bright ten-year old girl if she expects to have a...        Seth Godin
Categories: thinktime

"Did you win?"

Seth Godin - Tue 23rd Jun 2015 19:06
A far better question to ask (the student, the athlete, the salesperson, the programmer...) is, "what did you learn?" Learning compounds. Usually more reliably than winning does.        Seth Godin
Categories: thinktime

Understanding and responding to the impact of violence in families

Location Ian Potter Auditorium Melbourne Brain Centre 30 Royal Parade Parkville, VIC 3010 Australia See map: Google Maps Dr Angelique Jenney 17 August 2015 - 6:00pm - 7:00pm Dr Jenney will discuss some of the challenges of designing and delivering social services for women experiencing intimate partner violence. Len Tierney Lecture 2015

Angelique Jenney is the Director of Family Violence Services for Child Development Institute, a multi-service child and family agency in Toronto, and is an Assistant Professor at the University of Toronto. Angelique has over 19 years experience engaging both victims and perpetrators of family violence in intervention and prevention services within the violence against women and children’s mental health sectors.

read more

Categories: thinktime

New times call for new decisions

Seth Godin - Mon 22nd Jun 2015 19:06
Those critical choices you made then, they were based on what you knew about the world as it was. But now, you know more and the world is different. So why spend so much time defending those choices? We don't...        Seth Godin
Categories: thinktime

The problem with holding a grudge

Seth Godin - Sun 21st Jun 2015 18:06 that your hands are then too full to hold onto anything else. It might be the competition or a technology or the lousy things that someone did a decade ago. None of it is going to get better as...        Seth Godin
Categories: thinktime

You will rarely guess/create/cause #1

Seth Godin - Sat 20th Jun 2015 19:06
The breakthrough pop hit is so unpredictable that it's basically random. You will always do better with a rational portfolio of second and third place reliable staples than you will in chasing whatever you guess that pop culture will want...        Seth Godin
Categories: thinktime


Seth Godin - Fri 19th Jun 2015 19:06
Just about all the ranting we hear is tribal. "He's not one of us, he's wrong." Or, the flipside, "He's on our team, he's right, you're blowing this out of proportion." The most powerful thing we can do to earn...        Seth Godin
Categories: thinktime

Matt Griffin on How We Work: The Art of Creating Accurate Estimates

a list apart - Thu 18th Jun 2015 22:06

The estimates. Good gravy, people, the estimates. Is there anything more terrifying in this business than when you have to go on record saying how long it’s going to take to do a thing that (frequently) you’ve never done before? Estimates, after all, are the logical result of a series of questions that raise more questions. “How much will this cost?” leads to “What is it we’re doing?” which is followed by “How long will it take?”

And no matter how risky it may seem to come up with answers to this last question, it’s an expected part of the client services business. How else would our prospective clients know what they’re going to have to pay us? Without this knowledge, they’d likely never take the leap and agree to become actual clients. (Which, as you may know, is kind of important to this whole thing we do.)

Likewise, without good estimates, we can’t schedule our time. We wouldn’t know when projects end and when new ones can begin. Kind of crucial, right?

So why does estimating incite such raging fear in our hearts?

The problem of accuracy

Quick show of hands: who thinks they’re really good at creating consistently accurate estimates? Yep, that’s what I thought.

The quality of an estimate stems primarily from how closely it represents reality. There are several challenges to creating accurate estimates.

My experience is that most estimates (particularly those that are written with less experience to back up their assumptions) come from a place of optimism. We imagine doing a series of tasks in the best possible circumstances. We ignore unknowns, and all the resultant extra work that may arise from them.

Sadly, this is rarely representative of the world we live in, and leads to underestimating.

On the other hand, perhaps we’ve had a very difficult experience with a similar task. Perhaps it was due to circumstances that, though they were truly miserable, are unlikely to be repeated. In that case, our historical anxiety comes rushing to the fore and unrealistically colors our expectations, causing us to estimate far too high.

Or—as is often the case with unique and complex problems—if we have very little experience to draw on, we may simply take a shot in the dark. Have we estimated too high? Too low? Who could possibly know?

There are, thank goodness, a few things we can do to alleviate these problems. So let’s look at two possible ways to go about it, which I’ll refer to as “scope to time” and “time to scope.”

Scope to time

The scope to time conversion is a pretty standard, traditional estimating exercise. Given some fixed scope of features and deliverables, how long will it take to perform each task? For websites, we try to understand scope-defining things like:

  • How many templates are we designing?
  • How many rounds of design revisions?
  • What are the development features (e.g. is there a newsletter sign-up, a t-shirt purchasing system, integration with a fulfillment house API, etc.)?
  • What are the limits of browser testing (e.g. IE6, IE7, IE8)?

Once we think we understand all the things we’ll have to do, we try to make up numbers that represent how long it will take to do each thing. But before making a calculation (or guess), we must first think about what kind of timescale we want to work with.

That timescale tho

Timescales are lenses through which we can look at a task. I’ve found that which lens we choose can have a profound effect on our estimations.

Consider a task such as creating an element collage for a new client. We could potentially estimate time in terms of minutes, hours, days, weeks, months, or even years. Let’s take the extremes first. How many minutes does it take? I don’t know. Lots. How many years? I don’t know. Some small fraction, I guess. OK, how many hours? 10? 15 maybe? 8? Those all sound kind of right. Days? Well, 2 to 3 sounds good.

But 2 to 3 days at 6 hours each is 12 to 18 hours. Which is higher than 10 to 15. So which is right? My hunch is that when we think about an hour, we’re not looking at the right scale. Because the difference between a good hour and a bad hour can be wildly different. I’ve had an hour where I’ve accomplished almost nothing tangible. I tried things that failed; I got stumped on some problem to which an answer revealed itself only later; I was maybe just in a bad mental space at that time. I’ve had other hours where I’ve had great insights, closed ticket after ticket, made a huge dent in a project. The thing is that every day is made up of some of both of these hours. So when I think about what I can get done in a certain timescale, I remember that a day or a week is made of good and bad hours, and what that averages out to. What can I do in an hour? Somewhere between very little and a lot. In a day? A reasonable chunk of a thing.

On the other hand, at very large timescales—say months or years—my brain starts telling me that the chunk of time is approaching infinity. What can I do in a year? Everything! Which of course is not true, and is in fact a very dangerous assumption to make. Even very big numbers have an end. And to find those ends, we need to ratchet down our timescale.

This is why, in general, I find the middle timescales (days and weeks) the best for conceptualizing how much we can get done. Questions like “How many days will it take to build out a feature?” or “How many wireframes can I complete in a week?” tend to get me on the right path.

In addition to that, experience can help a lot. The more work we complete in our careers, the more data we potentially have to check our assumptions.

Condemned to repeat it

So we think it takes two to three days to make an element collage. Great! But is this our first time at the rodeo? If we’ve done element collages before, and—here’s the kicker—if we’ve accurately tracked our time in the past, we can compare this estimate to our record of the actual hours we spent the last time.

This is why I encourage a policy of tracking time spent on tasks. You can make a habit of running a timer (at Bearded, we use Harvest, but there are others, such as Freshbooks and TimeTracker), and switching that timer with every task switch. The motto is ABT—Always Be Tracking.

Now if we think our mental model of how long it takes to do a thing is way off, we can confirm our hunch by looking at historical numbers, and correct that mental model for the future. It can keep us from under- or overestimating the same thing over and over again. Which is nice.

Delta delta delta

Another way to check our assumptions, especially in larger groups, is to compare independent estimates done by multiple people. Seth Brown, COO of Lullabot, explains how he employs this approach:

Typically we try to work either on a retainer or an hourly basis, however clients often need to have an understanding of what the retainer length might end up being. We tend to decompose projects into bite-sized chunks, first epics, and then tasks, and then estimate those with a group of developers on our team. Each developer does a blind estimate for each task and then we compare everyone’s guesstimates. If the “delta” between each developer’s guess is large we discuss assumptions, ask questions if we have to, and then re-estimate.

This approach can certainly minimize risk. If two independent people think a task is easy or hard, it’s more likely to be the truth. And if they disagree, then a deeper discussion will likely lead to a better definition of scope.

Things fitting into things

Some tasks scale up or down with the scale of the project. Project management and meetings are perfect examples. For instance, when we estimate an hourly project at Bearded, we like to add 15 percent for project management to the grand total estimate. That way, more project scope results in more hours to manage that scope. Seems reasonable, man.

Time to scope

Defining scope and converting that to an amount of time is one way to do things. But you can also go the other way, and there are some very good reasons you might want do that.

Constraints are your friend

When was the last time a client showed up on your doorstep with infinite weeks and infinite budget to complete a project? Usually at least one of these constraints is in place. Great! So if they only have eight weeks before some event requires the delivery of some solution, then that’s what you have to work with. You know how many people-hours you can devote in those eight weeks, and that time constraint determines the maximum effort and cost. The next question is: What’s the most valuable way for everyone to spend their time during that timeframe?

Likewise if they have a budget of $100,000, just divide that by the team’s weekly rate and you know the maximum number of weeks they can afford. Then it’s time to answer that same question: How can we best spend our time to maximize value for that client?

Talk it through

Not surprisingly, this often becomes a conversation. Though sometimes a client is reluctant to divulge their budget (often out of the belief that a vendor is just trying to get the biggest number possible out of them), I find that telling them our weekly rate up front engenders some initial trust. At that point the mechanics of our cost are exposed, and we’re simply trying to figure out—together—how many weeks of our time they feel comfortable paying for.

It’s all about trust

In these scenarios, the scope and work products tend to be more open-ended. We’ll have a prioritized list of things to work on, and we’ll work our way down it—with the understanding that the list may change as we gain more knowledge and new facts present themselves throughout the project. Again, we’re always focused on maximizing our value to the client, so if something more important has appeared, we won’t just keep plugging away at a task because that’s what the contract has bound us to.

This approach tends to bring us closer to an agile process, where our ship date is fixed, but the work product and deliverables are variable. This approach requires a certain amount of trust and empathy on both sides. Everyone needs to understand that none of us can guarantee exactly what’s going to be delivered at the end of the engagement. It may be scary, but this uncertainty is tempered by a different kind of increased control on the client side: they can continue to reprioritize and redirect us throughout the project, without negotiating change orders.

That isn’t to say we rush into these projects with no plan. Far from it. But we admit that our plans are imperfect and subject to change. Frequently we begin these projects with a research phase to define the rest of the project (or perhaps to define a second phase).

The big question in this kind of arrangement, then, isn’t “Will we ship that thing on time?” Rather, it’s “Is the work we’re doing worth more than the money our client is spending on us?” If the answer is yes, then the value is clear, and the details about the exact work product or deliverables become less important. If the answer is no, then it’s likely a bad match and you should shift your focus, or they should look for another vendor.

Easing the pain

It’s not just in estimating scope that we encounter trouble. As Woody Allen famously said, “If you want to make God laugh, tell him about your plans.” No matter how we go about making estimates of things, it’s rarely foolproof.

So what else can we do to ease the pain of estimating?

Plan for the fan to be hit

For one thing, we can plan for what to do when things go worse than we imagined. In my experience, people who build things (web things included) are often optimists. Why else would we agree to dive into the unknown again and again with each project?

Paul Ford’s epic article for Bloomberg, “What Is Code,” sums up the problem of estimation optimism fairly well:

You ask the universal framing question: “Did you cost these options?”

He gives you a number and a date. You know in your soul that the number is half of what it should be and that the project will go a year over schedule.

Clearly, we must plan for when things go less than ideally.

In hourly projects, we borrowed an idea from our friends at Sparkbox and include a 20 percent contingency budget on every project. The contingency budget is a line item like everything else, but we never track time against it. It just balances out against overages from other line items. It covers our butts when things take longer than expected.

Likewise on weekly projects, it often makes sense to not densely pack every week of the schedule. Having a penultimate week on the project that’s focused on things like “polish” or “fit and finish” can keep you out of trouble when something goes awry. And if everything goes smoothly, great! When could you not use an extra week to tighten the screws, refine UIs and interactions, test on a few more devices, or create documentation for the client team and—heck—your future self?

Reaching across the aisle

Something that makes almost any project better—regardless of process or format—is good, open client communication. Why not extend this approach to the estimating process?

Says Ben Callahan, president of Sparkbox:

Lately we’ve been experimenting with an idea called “Collaborative Pricing.” It typically starts with an email from a potential customer where they’re answering a few key questions about budget, timeline, and scope. Our next step is to clarify any major questions we have based on the information we’ve been given. Then we’ll quickly put together a Google Spreadsheet that breaks down the work in a way we believe is reasonable given our current understanding… The idea is that we can work with our clients to find a budget, scope, and timeline that is mutually beneficial. We use Google Spreadsheets because it allows real-time collaboration but is also intuitive for anyone familiar with Excel or Numbers. The most helpful part of estimating in this way is that it makes the very first interaction we have with our customer one of collaboration.

Sounds pretty great, right? It encourages our clients to start prioritizing their resources (us) from the beginning. Do they want to pour extra hours into one feature instead of another? Do they want to cut something that doesn’t seem worth it, so they can add more budget to another area? Can they take a section or set of tasks off our plate (for instance, usability testing recruiting or QA) because they can assign internal resources to cover it?

Exposing the machinery of an estimate helps to demystify the process. It sets up a more collaborative relationship from the beginning, discourages adversarial behavior, and builds trust. These, my friends, are things of which a good client relationship is made.

Yeah great but how much does it cost?

Just as there is no single good way to set pricing, there is no single good way to estimate. You’ll need to do some trial and error to see what works for you, your communication style, your design and development process, and your clients.

The web is always changing and so, it seems, is everything else in our industry. So don’t be afraid to experiment and try new things. If all goes well, you’ll have plenty of opportunities to try again, and refine your estimating process with each project. You may also find that as your organization grows, what worked before no longer does, and that a new approach is suddenly more suited to you.

And oh hey, I’ll be damned if that doesn’t segue us quite neatly into the final installment in this series, where we’ll investigate how scale affects our web businesses. See you then!

Categories: thinktime

How, why and the other thing

Seth Godin - Thu 18th Jun 2015 19:06
Almost all the inputs, advice and resources available are about how. How to write better copy, how to code, how to manage, how to get people to do what you want, how to lose weight, how to get ahead... Far...        Seth Godin
Categories: thinktime

This week's sponsor: O’Reilly

a list apart - Thu 18th Jun 2015 01:06

Internet of things + design + business. Sound interesting? Head to SF for Solid Conference, June 23-25, brought to you by this week’s ALA sponsor, O’Reilly​.

Categories: thinktime

Plenty more

Seth Godin - Wed 17th Jun 2015 18:06
One of the critical decisions of every career: "Well, there's plenty more to do, I'll do the least I can here and then move on to the next one." vs. "I only get to do this one, once. So I'll...        Seth Godin
Categories: thinktime

The Homepage Exception

a list apart - Wed 17th Jun 2015 00:06

Everyone wants beautiful homepages. It doesn’t matter who’s running the organization, what industry they’re in, what design trend is hot, or what CMS is being used. A homepage is the front door to an organization, and organizations want homepages that reflect their sparkling missions and content.

Obviously this is where we, the web professionals, come in. We identify patterns in a company’s content and design. We build an ordered system to manage the site, with content stored in structured fields and cross-referenced by neatly stacked taxonomic containers. We build drool-worthy designs into pretty template patterns, into which a CMS can automagically flow that content. Relax, humans! The computer robots have got this.

And, of course, the robots drive homepage content, too. A common type of homepage—which I see a lot in my work with nonprofit organizations, but can be found in any industry—is a mix of somewhat static, explanatory content, with dynamic chunks populated by the most recently published content from a CMS. When these organizations are on tight budgets, often without a lot of staff and resources, it seems like a good idea to code the static parts and automate the dynamic parts. That way, staff doesn’t have to fuss with edits, updates, or technical interfaces, and the organization can focus on doing important work helping people. Homepage: done.

Until the request inevitably comes: the board of directors needs a slider because they want a way to highlight more than one post at a time. Furthermore, they need each slide to be able to feature a blog post OR a donate page OR an about page OR their gift catalog. And it’s important to the executive director that all static blurbs be wordsmithed especially for the homepage, and the blurbs may need to be tweaked during peak fundraising months. My easy homepage publishing system just left the building.

Maybe the robots shouldn’t win

After having this conversation about 242 times, I’ve realized that the homepage is almost always a giant exception to the rest of the ordered system for a reason. It’s the most human page on the site, where the potential helpfulness of computer robots collides with the messy reality of humans.

The homepage is a company’s elevator pitch that must telegraph an organization’s priorities and values as succinctly as possible. The fundraising department, program staff, and board members may feel anxious about ensuring their interests are visible on this valuable real estate. These internal forces, or the politics of partner organizations or funders, will affect what is presented on a homepage, even if it may not be the most logical choice for content, design, or structure.

Instead of wishing for (the ever-elusive) Total & Complete Control, it’s more useful to accept this human foible. Rather than fighting it, let’s build something specific to handle this exception better, in a way that’s least likely to break down the road.

Of blobs and chunks

Here’s a homepage I am currently rebuilding for Small Can Be Big, a non-profit project of the marketing agency Boathouse. Small Can Be Big works with Boston-area partner charities to help keep local families from slipping into homelessness. Let’s break it down:

  1. Hero area: the organization wants to be able to put anything they want here. This content and its design are unique to the homepage.
  2. “How it Works”: three quick points about the organization’s process. These are also unique to the homepage.

  4. “How it Makes a Difference”: A list of brief highlights about the organization’s impact. Blurbs very similar to these live on an “Impact” landing page of the site, and could be pulled in automatically. The content admin, however, needs to be able to wordsmith these blurbs specifically for the homepage, so they are unique.
  5. A newsletter subscribe form: this form may get used elsewhere on the site, so it will be stored in a sitewide-accessible block or a widget and then displayed on the homepage and on other pages as needed.
  6. The latest blog post: This will be automatically populated.
  7. A custom call to action with supporting content, just for the homepage.

So, we’ve got one sitewide, global element here (the subscribe form), and one systematized, auto-populating region (the latest blog post). How do we let this organization custom-craft the other pieces of this page?

One way to approach this is to create this page in a single body field, and give the client a WYSIWYG with which to maintain it. This offers the ultimate flexibility. But as anyone who’s written a goodly amount of HTML knows, giving content admins a big WYSIWYG blob can lead to broken code, elements that aren’t accessible or semantic, failures in the responsiveness of the page, and content that doesn’t fit within the constraints of the design. This can quickly lead to a schlocky-looking (that’s a technical term) homepage.

A better approach is to break the page up into little custom WYSIWYG chunks (blocks, panes, or custom text widgets). You assemble them on the homepage via whatever best methods your CMS offers, and the client maintains each and every little snippet in its own block.

The advantage is that the homepage gets broken down into components, reinforcing—at least somewhat—the separation of the content from its layout and design. For example, the “How it Makes a Difference” chunk might be built as four separate blocks or custom text widgets, floating next to each other:

The downside is more complicated management over time: the containers holding these chunks are generic tools, wired together in a front-end display. Each chunk may be maintained at a different URL. Specific help text can be tricky to include. And lots of small bits in the backend can be difficult for content admins to track, especially if there aren’t editorial guidelines and a strong governance plan in place. Eventually, the quality of the homepage, and the site, can start to degrade.

Let’s embrace the exception!

What I’ve been increasingly doing is making a content type that exists for one purpose: to serve as a structured form for homepage content entry and maintenance. This can feel weird from an information architecture perspective. Content types are generally reserved for pieces of content that share common attributes, implying that there is more than one instance of that content. As one of my colleagues said the first time I suggested this: “A whole content type for one piece of content?! That’s not what content types are for!”

But here’s exactly when we need to check back in with the goals of building CMS content structures in the first place: robots are here to serve humans, not the other way around. If this exception is needed, let’s embrace it rather than fight it. A single form to edit all of the custom content on the homepage can make things easier on the content admin, and helps enforce design cohesion and content consistency.

In breaking down the content type for the Small Can Be Big homepage, I looked for logical content and design patterns so I could group fields in a helpful way. For example, the three “How it Works” blurbs are there to inform donors about how their contributions work:

It’s logical for this sort of element to live on a homepage, and it will likely always be needed for this site. So I built it as a list of three items, and called it exactly what it is: How it Works. In the CMS, it looks like this:

I included help text about what HTML goes into each field, and some sample content. If the homepage changes in the future, these fields can be tweaked, or deleted and replaced with something else. But if the content structure remains the same, the design and/or layout can easily change to restyle this same three-item list. Either way, this setup is flexible.

The homepage edit form is your oyster

How you break down a homepage into a content type is dependent on the kind of content and design you’re working with. In the Small Can Be Big example, I’ve broken the form itself into the different content and design areas of the homepage: the lead feature (hero) section, the impact section, etc. This makes the form a lot less overwhelming to edit.

The breakdown is also dependent on your client’s staff resources. In my example, the client has a dedicated technical person on staff to edit homepage content. We collaborated with the content admins throughout the development process; we know the homepage content admin knows HTML well, and when we asked him what editing tools he wanted, he requested no WYSIWYG. I wrote help text to remind him of the HTML elements that are allowed and expected in the field (if he tried to put messier HTML in there, it’d get stripped out by the CMS), and provided him with a quick inline example or reminder of the content that should go there.

For a less technically savvy admin, I might make more fields, rather than fewer. Fields could be made to hold icons, images, and alt text. I could put WYSIWYG editors on each of the text fields, customized for the expected markup. Alternatively, I could make every element its own field: image fields with clear, descriptive help text for the icons, and plain text fields for the H3 headers and paragraph blurbs. I would then output those values into customized HTML templates, giving me complete control of the markup around the content.

The homepage edit form is a fantastic opportunity to add helpful UI elements for content administrators. It’s also a very good idea to add a general help text block, like I did in the example, linking off to the site documentation. You could also link here to the site’s style guide, if it has one, or add voice and tone notes.

Of course, how far you can take this is also a function of your project budget and timeline. If possible, it’s wise to build time into ongoing project budgets for regular adjustments to these customizations, to ensure they continue to be helpful for content admins in everyday use. But even adding a little structure and help text can go a long way.

Let the humans win

My job is to map messy human communications onto computer systems to help make it easier for people to manage those communications. That means that I need to balance the boolean realm of computer code with the far more ambiguous needs of organizational communications. By creating a structured exception for the very human homepage, I can better ensure the consistency I crave as a developer while giving content admins the flexibility they need.

Adding more logic and structure to homepage editing has another benefit as well: it encourages people to evaluate the meaning of their homepage content, making them plain old better. Rather than concentrating solely on visual “wow!”, and putting up icons and copy “because it just needs a little something there,” a structured edit form can force people to inventory what’s there, and identify that “little something’s” purpose. This encourages conversation around the role of the homepage, and keeps it from becoming a pretty parking lot subject to the whims of the boardroom.

The homepage exception is just one example of the many kinds of accommodations that human beings need in the coded, structured systems we build for them. It’s our job to adapt computer systems to their needs, not the other way around. If we don’t, then our robot overlords have won. If we expect, plan for, and even celebrate these messy, human exceptions to our logical systems, we get closer to making a web that works for both people and machines.

Categories: thinktime


Subscribe to kattekrab aggregator - thinktime