Jeff Croft

I’m a product designer in Seattle, WA. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

I’m currently accepting contract work and considering full-time opportunities.

Blog entry // 11.13.2006 // 11:30 PM // 41 Comments

Bring me problems, not solutions

A topic of conversation here at in recent weeks has been the need to educate the consumers of our services — the clients — on exactly what it is we do, and how they can get the most for their money.

So, as part one of what will probably be an ongoing series of posts, I assert that if there’s one thing a client can do to help a web designer help them, it’s bring problems, not solutions.

It seems to me that a lot of clients don’t understand exactly what they’re paying for when they hire us web designers. In their head, they’re paying for technical services — the construction of web sites for their companies. But that’s not really the job of a designer. The job of a web designer, as I see it, is to craft solutions to problems and systems that will help achieve goals the client has set.

I liken the difference between what clients often think they’re paying for and what we really do to the difference between architects and construction workers. Architects plan and design new buildings, and construction workers implement those plans. Likewise, there are two tasks in creation of a new website: the planning and design, and the implementation. In some cases, they are both done by the same person — but it seems that many clients are expecting their web designer to be far more concerned with the implementation than with the design. That is to say, they sometimes see us as web monkeys who simply carry out whatever they ask of us. And to be sure, if they’re paying us enough money, sometimes we’ll do that to placate them. But the reality is they’re losing out on half of our skill set when they do this — and it really should be our responsibility to educate them as such.

Let me give you a simple example from a recent real-world project (which will remain anonymous for the time being). For a site I am working on, the client came to me and said, “the logo needs to be bigger.” In my estimation, the logo was already pretty large, and I could have articulated several reasons why I didn’t think making it any bigger was the best direction for the site. So, I asked, “Why do you want the logo bigger?” After a bit of talking back and forth, the client expressed their concern that the brand of the site wasn’t prominent enough. They didn’t feel like, when you first hit the home page, you would immediately know and understand you were at A-ha! Now we have a problem. See, “make the logo bigger” is a solution. “The brand isn’t prominent enough” is a problem. In an ideal world, it’s clients job to bring problems, and the designers job to find solutions. I didn’t end up making the logo bigger. I did put more whitespace around it and add a subtle (but effective) watermark of the brand icon in a very prominent position on the page. The point is this: making the logo bigger was only one possible solution to the problem. As clients are very often non-designers (and sometimes non-creative in general — although that’s definitely not the case in my example), it’s common for them to only see — and therefore suggest — the obvious solution. Once an experienced designer understands a problem, on the other hand, they’ll immediately conjure up about 15 different potential solutions.

Note: Just for the record, this is a great client who is very creative in nature and generally has been more than happy to let me run with my ideas without getting in the way. I just wanted to say that in case they happen to read this. :)

I recently had someone approach me with this proposal: “I’m working on a web application and I need a designer to help me. I want it to be very web 2.0 with gradients and drop shadows and other light effects. I’ve already mocked up the layout — I just don’t know how to create these effects in Illustrator and I need someone who will do it for me.” I know it sounds like a joke, but it was a serious proposal — I swear. When I said, “Okay, let’s take a step back — what kind of web app is it? What does it do?,” he got defensive and informed me that if he was going to hire me, I’d have to do what he wanted without asking so many questions. I talked with the guy for about 30 minutes and eventually told him I didn’t think it was “a fit” — and suggested that if he did hire a designer, he should probably back off a bit and let them design. On the flip side, if he just wanted someone to carry out his vision, there are several services that do that sort of thing.

This guy didn’t want a designer. He wanted an Illustrator guru to carry out what he’d already decided upon. He didn’t want me to architect a site for him — he just wanted me to be his construction worker. That’s not to say construction work isn’t important, of course — but it’s only a small part of what I, as a web designer, do. This was an extreme case, but it illustrates (no pun intended) my point — hiring a web designer and having them act as a web monkey is not only a waste of money, but also shortchanges your site from the benefits an experienced web designer’s perspective can add.

So if there is one thing I would love to be able to make clients understand, it’s that its in their best interest to bring the problems, and let the designer work on the solutions. Oh sure, they are more than welcome to make suggestions — most designers would love to hear them. But clients who insist on art directing every step of the way usually lose out — and frustrate the hell out of a designer.

Before you meet with a potential designer for your site, put together a list of problems you’re looking to solve or goals you’re setting out to achieve. They might look something like this:

  • We want to engage our customers more in the experience of our site.
  • We want to make our site easier to use.
  • We want a look and feel for our site that is suited to our company’s mission and brand image.

This list clearly outlines goals for the site. You should probably be concerned if your list looks more like this:

  • Add blogs to our site.
  • Make the navigation use drop down menus.
  • We really like the look of, make our site look like that.

This list, on the other hand, lists several solutions, without defining the problems or goals. If you want to make a solution suggestion, that’s fine — but be sure to outline the problem you’re trying to address and be open to other possible solutions the designer may have for the same problem.

What this boils down to, really, is understanding that when you hire a web designer, you’re getting a creative mind who is in the business of solving problems like the ones you almost certainly have. You’re not just getting a computer nerd who can write code in his or her sleep. I have no doubt clients who embrace this will get far more out of their designer than those who don’t.


  1. 001 // Peter Holloway // 11.14.2006 // 3:26 AM


    I agree completely. It’s not just web design, but most programming jobs too. The client too often comes up with a solution without articulating the actual problem they want to solve.

    My usual question of “What do you want it to do?” is usually met with blank looks by those who have already decided that they need a web site.

    I look forward to the time when web designers are treated as professionals who design, not just as ‘builders’.

  2. 002 // mrben // 11.14.2006 // 5 AM

    Excellent :) Totally in agreement.

  3. 003 // tenni // 11.14.2006 // 5:38 AM

    Excellent article. One of the best I’ve read in recent memory. This has cleared up a lot of thought’s I’ve had floating around in my mind recently.

    Thanks for articulating the whole web designer/web’?site builder dynamic so clearly.

  4. 004 // Arjan // 11.14.2006 // 7:09 AM

    Well put—and I agree completely. Now you’ve defined the problem, I hope your next post will define the solution :-)

  5. 005 // Baxter // 11.14.2006 // 8:38 AM

    I’ve always thought every web site, like every news story, has questions that must be answered. Maybe not the news story’s 5Ws, but at the very least: “Who are you trying to reach” and “What are you trying to accomplish” Failing to adequately answer either of those (and usually other questions) will inevitably lead to failure, and it’s the duty of the designer to ask them. It’s also worth nothing that it isn’t just client sites that run into these problems. I’ve worked on quite a few internal projects where someone important said, “We need another site” but no one ever asked the important questions.

  6. 006 // Nate K // 11.14.2006 // 9:03 AM

    I swear I have a little ‘jeff croft’ conscience living in my head, because we are often thinking the same things - and you articulate them well in your posts.

    The list of ‘problems’ you show as an example will often times gauge how a client wants their work done. Personally, I don’t want to deal with people that say ‘I want my site to look like’ That’s not creative, that’s not solving a problem, and that is surely not creating a strong brand. Not only that, but so many times has a horribly crafted website from a construction perspective - and I would never advocate that and keep adding to the junk already out there.

    Here’s the problem I have: when the problems listed above are actually from web developers themselves, not the clients. These are people getting paid to do a website - but have no clue of how to ‘architect’ the site. They want quick bucks, and don’t care how it gets done. The client loses here. We lose here, as another site of crap is committed to the web.

    I have decided to take this approach and go from the problems backwards. For instance, when people ask me to assess their site, I will list the problems - explain WHY they are problems (many times with examples), and then show them the solution. Many times they didn’t even know the problem existed in the first place. If I would have done it inversely, and started rambling off solutions for problems they didn’t know existed - they they would instantly be turned off by my approach.

    The education of the clients NEEDS to be there. Unfortunately, this is not always an easy task.

  7. 007 // J Phill // 11.14.2006 // 9:19 AM

    Wow this article is great. I had a guy recently email me, no greeting or anything, asking what my rates are, and attached his own mockup wanting me to build it out……ridiculous.

  8. 008 // Wilson Miner // 11.14.2006 // 9:59 AM

    Good post, but I think my original analogy was architects and contractors. ;)

  9. 009 // Keith // 11.14.2006 // 10:57 AM

    At Blue Flavor we’ve taken to calling this “solutioneering” when it applies to our own team, which it often does. If you think about it, putting the solution before understanding the problem is easy to do. It’s almost natural to begin working on a solution.

    We go our of our way to keep ourselves from doing it (when we do we have to put $1 in a bucket) and we also try to “teach” our clients not to do it as well.

    Whenever I hear a client offering up a solution before we’ve discussed the problem I push back and explain that we need to understand the root problems before we can make a decision on how we tackle things. A common situation is when we’re working out the Information Architecture of a Web site or application. Often times they’ll have goals like, “we need to convert more leads to sales” and want to address that by going with an unwieldy audience based structure (for example) when what they really need is better placed calls to action and an easier checkout process. Again, that’s just a quick example off the top of my head, but in that case the client will come saying that they need an audience based structure, not that what they really want to do is sell more widgets.

    It takes real effort, some empathy and good listening and deduction to suss out what a client really wants. Then it takes some persuasive conversation to pull them back to where you can nail that problem down and come up with the best solution.

    It’s hard, but necessary in order to provide the best possible solution.

    Good post.

  10. 010 // Dan Mall // 11.14.2006 // 12:13 PM

    Great post Jeff. Like tenni, Nate K, and Wilson were saying, I’ve been thinking about this recently as well. My next post (saved in draft status) was entitled “How to Keep your Designer Happy”, but yours is pretty encompassing and way less bitter, so thanks for saving me the trouble and the embarrassment :)

  11. 011 // drjuice // 11.14.2006 // 12:51 PM

    WOWOWOWOW! One of my friends pointed me at this essay and it’s outstanding. Thank you.

    In “real life” I work in a University (not as a web dude) and invariably when students want to do something, the reason is always “Because I want to” or “Because my friend is doing it” even though what they want to do is not within the scope of what’s allowed by their financial aid. When I explore with the students what their real objective is and not the “solution” they’ve chosen to reach the objective, I’m just like Jeff and can usually find something that will both be doable and help them get to their objective which, by the way, is likely to change by the next time I see them! ;-( Thanks again, Jeff.

  12. 012 // steve // 11.14.2006 // 7:01 PM

    holy crap. you literally took the words right out of my mouth (or blog)…right now, sitting in my drafts is a post about “web designers/developers” vs. “web monkeys” (really, same phrase!) so obviously i whole-heartedly agree with your opinion. when a client is engaged with a web designer, they are really paying for the experience and expertise of that designer. they are not just paying for the ability to churn out x lines of XHTML code per hour or whatever. well said!

  13. 013 // Christy // 11.14.2006 // 7:05 PM

    Clap, Clap, Clap” That is a standing ovation from me.

    This is the heart of the problem.

    I’m a freelancer but I’m also a 9-to-5 webmaster.

    I’ve not only heard all of these things but when I attempt to inject a bit of education (even the tiniest bit) I am told I’m “arguing too much” and “why can’t you just do what we tell you to”… so now I just do it. But it’s killing me.

    Recently I was directed to insert line breaks in sentences because the particular word the sentence was breaking on was unacceptable.

    I started to open my mouth, my brain started to develop the words to explain the concept that text on a web site is not like text in a printed document… and then I just stopped. I did not want to get yelled at again, I did not want to overhear someone else from management telling my boss “I guess that’s just how those designer types are”.

    I have found that it is impossible to educate someone who does not want to learn.

    Oh, and try explaining any of this to someone who doesn’t understand what a web designer is and they just don’t see the problem.

  14. 014 // Jeff Croft // 11.14.2006 // 7:07 PM

    they are not just paying for the ability to churn out x lines of XHTML code per hour or whatever. well said!

    Just to be fair, though — there are services who simply churn out (X)HTML and CSS, and I don’t think there’s anything wrong with that. However, it shouldn’t be mistaken for web design. That’s putting together a web page, which is different from designing a web page.

    Companies that churn out ()XHTML and CSS from pre-designed comps are useful and welcome additions to our industry landscape — but they can’t really call that service “design,” i don’t think.

  15. 015 // Jeff Croft // 11.14.2006 // 7:19 PM


    I’ve been in your shoes before. It is tough. Obviously, you ultimately have to do whatever your boss wants you to, or you risk losing your job. In an ideal situation, a boss understands that you have a great deal of experience and expertise in how the web works and how websites should be designed, and will be happy to hear your perspective and value it highly. But, that’s not always the way it is in the real world.

    People seem to assume when I talk about “client education” that I am a freelancer and that my “clients” are external companies I’m working with. While I do some freelance on the side, I also work 9-5 on an in-house web team. Most of the “clients” I refer to are actually the leaders of projects or properties within the company, and not external companies.

    With that in mind, everything I say about “client education” could also go towards “boss education” or “project manager education.”

    Part of the problem is in the hiring process. I think companies sometimes have a clear idea of what they want someone to do, but it’s not very accurately communicated in the job description. I see ads all the time for “web designers” when it’s obvious that what they really want is an “(X)HTML/CSS/JS guru to code designer our graphic designers have made.”

    I dunno. It’s tough. The easy answer to someone like Christy is “get another job where your expertise and opinions will be respected.” But, that’s far, far easier said than done. Keep on keepin’ on, Christy. Eventually you’ll either convince your boss to listen to you or you’ll find someone else who will.

  16. 016 // Christy // 11.14.2006 // 7:39 PM

    Thanks Jeff. It’s good to hear that other’s out there have been through it… I’m not alone after all :)

  17. 017 // Alex Aguilar // 11.14.2006 // 9:51 PM

    wow, pretty apropos post. I’m at the point with a client where yesterday I decided to stop caring and just finish the project because they want to clutter the fuck out of their site. I’m going to make another attempt to explain why they should tone it down a bit.

  18. 018 // Benson Low // 11.14.2006 // 10:45 PM

    Hear, hear! The client scenario is not the only scenario for this to happen. I had encountered numerous development projects where the web/UI designers (my team) was asked to “pretty up” the application screens. It is often the case where the solution is developed by tech leads and architects but not filtered through User Centered Design or usability for that matter.

    I normally take the stance if we (designers) are not involved in the initial scope requirements and workshops, the “design” will not be done. We are here to design for the users to make your application better. Not just re-skinning a dead cat.

  19. 019 // Luke S. // 11.15.2006 // 12:32 AM

    Oh yeah, amen to that.

    I was working in an organisation which had the equivalent structure of the CEO saying something to a general manager, who would say something to the department director, who would talk to the department board (!) and my manager, and my manager would say to me “Well they were wondering if you could just…”.


    I trained my manager about the whole ‘problems not solutions’ thing which worked to a point, but you really need your manager to advocate on your behalf if you are to survive long term in that position. Due to politics, ignorance, and the survival instinct of management, that’s pretty rare. The net result is that the organisation then loses good staff.

    I’m freelancing f/t now and its much better :) The problem still occurs, but in my case its much easier to talk to someone one on one, make your case, or just not take on difficult clients.

  20. 020 // Oliver // 11.15.2006 // 2:31 AM

    Stole the words right out of my mouth.

    I have a project at the moment (which I am doing for free by the way), and the client insists on controlling every little detail of the site (right down to the size of the borders used to denote a highlighted menu item in the navigation bar).

    As you well know, very frustrating when you know that the changes are not the right things to be doing to the site, and the client just isn’t interested in your opinions on design, even though your job for them is to be a designer.

  21. 021 // Nick Tatt // 11.15.2006 // 3:26 AM

    Great summary on how some clients wish to do the very same job they are actually paying a designer to do.

    I do sometimes think that a designers role is not fully understood by some. As you point out, it is essentially a problem solving role but very often it is looked upon as a low level implemention role that comes about because designers can use Photoshop.

  22. 022 // Brad // 11.15.2006 // 7:47 PM

    Excellent article, Jeff. This should be on A List Apart.

    I think you’ve helped clear some fog with the client / web designer relationship. It’s refreshing to see one offer a constructive solution instead of just whining about how their client just doesn’t get it.

  23. 023 // Henrik // 11.15.2006 // 9:39 PM

    Nice points :)

    You are assuming that the web designer is in the top end of the scale. In my experience most web designers have a fairly predefined context for coming up with designs.

    Even so, no design(regardless of area) will ever become good unless you work out what problems you want to solve.

    Wasn’t it Einstein that said something like “Genius is asking the right question” ?

  24. 024 // tedd // 11.16.2006 // 9:19 AM

    I agree with you, but isn’t that the way of all technical service industries?

    I came from a very technical industry ( and the main problem I had was dealing with clients who wanted a problem solved, but couldn’t understand the solution I provided.

    Now that I provide web services (web sites, applications, but primarily programming) the widget has changed, but the problem remains.

    I think what we developers (web design, application, or whatever) have to realize that we have to educate our clients as to what is possible; and the best way to accomplish that is to listen to their problems; and tell them how we can solve those problems for them in non-technical terms.

    For example, I have a current client who wants her database (things she wants to sell) to be keyword searchable. That sounds good, right? So, I proposed a FULL-TEXT MySQL search of the description portion of her products. That way anyone wanting to see what she provided in terms of “x” could search for “x” AND all she has to do is to include what “x” keywords she wants in the description portion of her database.

    Sounds simple enough, right? Not really, because she thinks she needs an additional field in her database entry form where she can add her keywords separately. She doesn’t understand what a FULL-TEXT search is and why it would be better for what she actually wants.

    Can I explain it to her in terms she’ll understand and allow her to make the right decision? That remains to be seen, but that’s part of what I do. That’s part of what we all do. It’s called service.



  25. 025 // jeff Croft // 11.16.2006 // 9:37 AM


    I personally can’t imagine why your client would be having any input at all on the database schema. I don’t think I’ve ever even had a client that would care about the database schema.

    Myself, I try to talk to clients in terms of ROI, the bottom line, and brand concerns — most of them seem to understand these things. I get only blank stares when I start talking about web standards, CSS, MySQL vs. PostgreSQL, why I prefer Django over some other framework, etc.

    I’m sure there are some clients out there that want to be involved at that level — but they seem few and far between to me. So, I’d ask — do you really need to be having a conversation about features of MySQL with her? Could you just have done what you think is best for her without ever bringing it up?

  26. 026 // Ranjani // 11.16.2006 // 6:08 PM

    I’m pretty happy that all the people I’ve done work for at my high school (yes it’s free, I run off of charity) don’t know a thing about my work and like it for that reason; although it’s beyond me to purposefully do a crappy job, I’m not sure anyone would notice. That’s probably the problem. Most people see websites as a status symbol - like a giant luxury car. The brand might not even be that great, and they still want it. They want what everyone else has and gets recognized for. So amen for intelligent clients - they’re all too few nowadays, when everyone’s waiting for the next trend (gradients in this case…good grief. Web 2.0 does not equal gradients!) just so they can copy it :(

  27. 027 // brendan cullen // 11.20.2006 // 2:50 PM

    Wow, you completely described my job, that hired me as a designer and use me as a web monkey, and i’ve been pretty unsuccessful in trying to explain the differences … i’m definately going to get some people to read this if i don’t just outright plagarize it in an email ;)

    Great article

  28. 028 // Grant Blakeman // 11.20.2006 // 7:08 PM

    A wonderful analogy to a constant problem in the designer’s world.

    I recently had an unhappy client suggest they could’ve built the site I delivered themselves in Frontpage (in half an hour). While initially a frustrating comment, I realized that the client just didn’t know how to express the problem they saw that I wasn’t solving. The client had expectations for the design of the site that I was not meeting (and they hadn’t been able to communicate).

    This was a good reminder because many clients (especially ones who aren’t used to the world of design) have trouble articulating “problems” and so, instead, propose solutions. Often our job as designer/developers is to probe through the solution and try to discover the underlying problem. It’s definitley not easy to do, but it beats just “making the logo bigger.”

  29. 029 // Clinton // 11.21.2006 // 7:47 PM

    Nice to see ya back on the web design tangent, Jeff ;) Insightful article and something that I’d do well to keep in mind when at my day job, where my guard is down and I sometimes do fall into the “web monkey” trap).

    Have fun in Vegas.

  30. 030 // Naomi // 11.22.2006 // 2:35 AM

    This is a really excellent article. My partner wrote a blog post on the same subject here: The WHAT and HOW in design: leaving your project in the hands of professionals

    So, it looks like we are all in the same boat and it’s up to us to educate clients about the value of our profession and what it is that we really do.

  31. 031 // Adam // 11.22.2006 // 3:37 PM

    You captured my sentiments exactly, but you seemed to word it much better than I had in my head. I will definitely refer peers to this article for some time.

  32. 032 // Neal Barrow // 11.27.2006 // 1:57 PM

    Thank you for spelling this out so well. It’s hard educating clients about what we do and the reason we do things. I feel like clients get defensive if you run with your ideas too much.

    I recently had a client tell me “You know, this is our site, and were going to do what we want,”after giving some good advice on current web conventions. It caught me off guard. I guess clients still think that the web is a place where anyone can create award winning sites.

  33. 033 // Michael Whalen // 11.28.2006 // 2:44 AM

    I cannot agree with Nate K. more on this post… If there was some worldwide Web Designer / Developer of the year award I think it would, hands-down, have to go to you.

    You are really the spokesperson for every struggling web designer out there, obviously you are experiencing things that all of us experience, and yeah, you do a damn good job “articulating them in your posts”. I can totally relate to every single sentence you write, in some way or another.

    I can’t tell you enough how much I love your blog, you rock dude!

  34. 034 // Rhys Thomas // 12.06.2006 // 7 AM

    It’s all true, I’m just starting out in the business and I swear I spend more time explaining to potential clients what I do, than actually doing it. I have a client at the moment who is expecting his site finished by the end of the day, but has provided none of the content for the unfinished bits and is calling constantly to ask why it is’nt done. If I could make things appear from thin air I’d do it with cash and I wouldn’t have to work for him in the first place.

    Great post though, think I’ll mail it to him.

  35. 035 // John Lascurettes // 03.05.2007 // 3:38 PM

    I’ve often said this same thing to my clients but in a much more roundabout way. Your pull quote says it succinctly and perfectly.

  36. 036 // Philip Skoog // 11.26.2007 // 4:56 AM

    In product development and process optimization, a requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. A specification (often abbreviated as spec) may refer to an explicit set of requirements to be satisfied by a material, design, product, or service.[1]

    In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development. Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. This is reflected in the waterfall model of the software life-cycle. However, when iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation.

    engineers try to guide clients thru a requirements phase. The idea is to get to the utility of the design….”what is the problem to be solved?”

    After a meeting or two you realize the problem is customers can’t write/express their requirements.

    What the consultant often does in frustration is parrot back to the client what they said they need or want. Neither need or want complete requirement definition but ya got to start someplace.

    The other way to go is to story board the customer experience with the design. Where to they go and how ……. what do they do with the designed object or service and does this fit some need or business objective.

    A good cup of coffee helps and the sooner they can see a sample the better the communication.

  37. 037 // Social Networking // 02.27.2008 // 3:10 AM

    Nice post!

  38. 038 // Robert // 04.07.2008 // 5:55 PM

    People just think that all we do is to ‘make things pretty’! sigh

  39. 039 // bizuteria srebrna // 11.30.2008 // 4:41 AM

    Excellent article.

  40. 040 // Ted // 12.17.2009 // 4:06 PM

    Great article. It’s exactly what my experience has been with clients.

  41. 041 // stainless all clad // 12.29.2009 // 4:21 PM

    Thanks for cooking up some hot tips!

Tags for this entry