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 publisherYour weekend reading
- 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
- 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
- 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
- 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
- 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
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.
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:
- A lack of empathy for end users.
- 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.
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 jobstobedone.org
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:
- Show them why it’s important.
- Show them it’s not going to make their lives difficult.
- Give them a framework that covers the whole product.
- 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?Footnotes
- 1. Gotta represent Portland!
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.
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!