The plight of the in-house designer
Posted in Web strategy on: Thursday, June 19, 2008 by Paul Boag
The more organisations I work with the more sympathy I have for in-house designers and developers. It is a role that can be thankless and isolating. How then can their lives be made that much easier?
I last worked as an in-house designer/developer over 8 years ago, so I don’t feel I can really comment on the subject. I therefore enlisted the help of the boagworld forum and dug out various emails I have been sent over the last couple of years. I also picked the brains of Paul (our researcher) and Ryan (our producer) to compile 10 quick tips for improving the lot of in-house staff.
1. Coding with others in mind
The general consensus seems to be that as an in-house coder it is important to consider the next guy. Whether you are working as part of a team or as a lone developer, sooner or later somebody else will have to pick up your code and work with it.
Two techniques were suggested for coding with others in mind. The first was to carefully comment all of the code your produce and if appropriate even create supporting documentation. The second was to have a library of reusable code so that all work produced is consistently marked up. That way it can be passed around the team easily.
Personally, I believe this is good practice whether you are working in-house or not. Certainly Headscape use an extensive library of HTML, CSS and Javascript snippets.
Of course, if you are working alone the need for a library of snippets is less pressing. However, our next problem is a bigger concern.
2. Seeking out like minded people
Many in-house designers/developers are working in isolation. There are a relatively few organisations that can afford a web team. Working alone has two obvious drawbacks. First, it is hard to keep up-to-date with new approaches because you are learning on your own. It is easy to get stuck in a rut, using the same old techniques. In web design stagnation can be dangerous both for your career and for the evolution of the site you are supporting.
Second, it can be lonely. Even though you have other people with whom you work, they do not share your experiences as a web developer. You cannot moan about shared problems or ‘geek out’ on code or typography.
The solution is something we have spoken a lot about before. Make contacts within the industry both online and off. Use tools like forums, twitter, and mailing lists. Offline, look for meetups and conferences you can attend. Nothing in your area? Don’t let that put you off. Setup something yourself. If somewhere as backwards as Dorset has a web designer meetup then there is no reason why your area cannot!
3. A demonstration speaks a thousand words
The feeling of isolation can be exasperated because management often simply fail to ‘get’ what you are trying to do. It can be amazingly frustrating when you have a great idea but you fail to make others see why it is so good.
One solution might be to build a proof of concept or prototype. It is often much easier to convince management of an idea if they can see it in action. Some even spend their evenings producing prototypes as they are not given the opportunity while at work. Personally, I cannot help but wonder whether you should actually be looking for a new job if you are forced to develop ideas in the evenings!
4. Impose some structure
One idea I agree with is that in-house developer you should work within the same rigid structure used by external agencies. Too many in-house teams are treated like a free resource people can turn to whenever they like. This leads to scope creep and (more importantly) to the web team being undervalued.
So what do I mean by a rigid structure? I am talking about things like:
- Statements of work
- Change control procedure
- Client signoff
- Project milestones (for both yourself and the client)
- Resource assignment and budgeting
These techniques ensure projects run smoothly, limit scope creep and project a professional image to the internal clients improving their perception of the development team.
They are also worth applying no matter how small the job. For example if you have been asked to change some copy on the website always confirm what the requirement is via email. This acts as a mini statement of work. Project management doesn’t need to be onerous to be effective.
5. Encourage internal charging
Of course the best way of making somebody value your work is to charge them for it. There seems to be a general consensus that where possible internal charging is a good idea. However, often this is outside of your control.
If you are unable to charge internal clients there are alternatives. One option is to calculate how much you cost the company per hour. Once you have this figure (even if it is an approximation) you can start to include it in statements of work. List all of the tasks to be done, associate a time with each of these tasks and include the cost to the company for each.
Hopefully this will make internal clients think twice before using up your time. If you want further leverage start submitting a monthly report to management outlining what work you have been doing and the associated costs. Let clients know you are doing this as a further incentive for them to think twice.
6. Be the authority
Another piece of advice that was generally agreed upon is the need to be seen internally as an expert. How you are perceived is important if you want your opinion to be respected.
Avoid being hesitant or negative about ideas because you are unsure how to implement them. Instead research solutions and if appropriate bring in an expert. Using specialists does not undermine your authority. Rather it demonstrates that you can manage a project even if it is bigger than your personal capabilities.
7. Exude confidence, personality and enthusiasm
On the subject of negativity, avoid saying ‘no’. Many internal web teams are perceived as a barrier to be overcome. Internal clients often turn to external agencies in an attempt to bypass them entirely. Once you are ‘out of the loop’ you loose control entirely.
A better tactic than saying ‘no’ is to say ‘yes’ but go on to explain the consequences. Once you have explained the negative impact of a suggestion, be quick to provide a positive alternative of your own.
Be confident and enthusiastic about every project. Avoiding being perceived as the stereotypical geek sitting in the dark barely uttering a word. Ensure you are likeable. If people like you they will listen to and respect your opinion.
8. Broadcast your successes
To further enhance your reputation internally make sure you broadcast your successes. If you launch a new sub-site or feature, ensure you tell as many people internally as possible.
If the company has an internal newsletter or mailing list make sure you write something for it explaining what you have done and why in plain English. Focus on what the project brings to the business rather than how it works and why it was challenging.
Offer to run workshops about the web or give a mini-presentation on web strategy to management. Anything to make you appear pro active and a benefit to the business.
9. Understand the politics
A lot of the points so far relate to company politics. Every organisation has its internal politics and ‘rising above them’ isn’t a realistic option.
One area where politics becomes particularly important is sign off. If you are having trouble getting something approved ask yourself the following questions…
- Does my internal client have the power to sign off themselves or is there somebody else I should be talking to?
- Who are the people influencing those signing off?
- Who are the opinionated trouble makers slowing down the process?
In many cases the person who appears to be the decision maker is not really. They are being controlled by management higher up or influenced by a few vocal individuals. If this is the case you need to speak directly to these people or at the very least give your client the tools to force sign off through.
10. Stick to the facts
Finally, always have facts to back up your opinion. This is especially important if people within the organisation do not respect your opinion.
Facts and figures are especially good but when that is not an option turn to an expert opinion. Quoting an internationally respected author like Steve Krug will generally carry more weight than your own opinion.
That said, remember to explain who this person is and why their opinion matters. You cannot expect the heading of marketing to have a clue who Steve Krug is.
Where an internal client remains unconvinced by an experts opinion turn instead to the weight of evidence. Don’t quote just one expert, quote ten. The shear number of people saying the same thing will impress.
So there you have it. Advice straight from the boagworld community. If you have anything to add, post it in the comments below.
11 Comments
Comments are for the discussion of this post. If you have other questions / comments then post them to the forum or send me an email
Bravo – this is spot on, and well-timed. As a designer who has worked in-house for the past 11 years, I can only echo that all of these points are excellent advice to read.
Hey Paul, really enjoyed this article! I’ve recently moved to a position as an in house designer and would very much like to start a snipppets library for our team. I’ve been a bit stumped as to what software or structure to use to accomplish this. Any suggestions? Thx!
This article brings back memories of discouraging times. I used to work for a small company full of self proclaimed internet experts. I’d always present things in a positive manner, backing designs with usability concepts and evidence. I would prepare multiple solutions and share multiple sources of supportive evidence for why we might consider making a change. They just disregarded everything I would say writing me off as being difficult. It was one of those deals like “this is how it is, nobody knows why and presently we can’t find any initial reasoning.. but lets assume maybe their was”
When I left they hired two interns to replace me. I heard through the grape vine one of the interview questions was along the lines of “We are looking for somebody who does exactly as we tell them, have you ever found yourself questioning authority?”
Thank goodness thing I’ve moved on to greener pastures and a company that embraces new technologies and encourages a learning environment.
Excellent points. Having erred my way into learning them all, I hope in-house designers/devs take this to heart. Another I would add: if you leave, leave a note where designers/devs will find it that detail your design & coding mindset at that time, so they know what they’re inheriting and why. Designers/devs who take over your work can trash your reputation if they don’t understand where you were on the learning curve, or why you made decisions the way you did. That can migrate to old bosses, and there into references for new jobs. I made that mistake at the job in which I wrapped my brain around web standards. The devs who came after me painted me as incompetent to management, and I had to work some angles to get a good reference outside my old chain-of-command.
Good article Paul, it definitely covers many of the issues I have personally dealt with in the past.
I also want to point out that there are a lot of upsides to being an inhouse designer too – you get to be really involved in a website over a long period, so you see what works in practice, not just in theory.
You can develop deep product knowledge in an area, which is useful for future roles. You often also get the opportunity to do a lot of different things – IA, design, front end code, copy writing…whereas in an agency your role can be much more defined for you.
Inhouse design, especially where you *are* the design team, is an excellent way to get in and really create your ideal job, if you have the guts to make it happen!
I am currently in my second in house role and my first one was really not good. I am not sure why they had an in house designer as they didn’t really want to give me any time to work on their site. If I was willing to work extra hours from home I could get stuff done.
Luckily now I work with at least one other designer and they work to give me the tools needed to get my job done. Flexible telecommuting options. It can go well if the management understands and values the position.
the BIGGEST problems I had was, I was a in-house contractor for a vary large company. I was not allowed to go to any of the meetings and i never got the chance to fight for my ideas.
Did anybody answer Josh’ comment? as this is just what I thought of straight after reading Paul’s advice on snippets… In the mean time I’ll do some google searching.
Hey Paul, really enjoyed this article! I’ve recently moved to a position as an in house designer and would very much like to start a snipppets library for our team. I’ve been a bit stumped as to what software or structure to use to accomplish this. Any suggestions? Thx!
From my current experience, WORKFLOW would be one to add to the list. I recently went from one of 4 in-house designers for a Fortune 500 company to the sole in-house guy for a small software firm. I got used to the whole source control DEV-STAGE-PRODUCTION environment and saw the benefits of implementing it. Currently I’m wrangling code from 3 different servers and pulling them onto my local machine for testing before deploying the code live straight to the production servers.
Create a consistent workflow for managing and backing up the sites you design and maintain. It’s helpful for you and is a great help to anyone who has to inherit your projects.
As far as snippet libraries, I have used something as simple as a folder named “code_library” on the Dev server that was accessible to all designers/developers. Create sub-folders for the type of code with example .htm files of the code in action so others can get a quick overview of what it does and how to implement it. This is a good repository for design teams and helps to learn new tricks and code from others around you. Saves time and testing as well, as most snippets tend to be well tested across different environments.
The most trying times of an in-house web designer is when you’re asked to print out the web site for review. Just awful. This has happened countless times, and you end up getting a stapled bunch of papers back with red pen ink and scribbles all over it. Then when they wonder why the graphics didn’t get printed out because you used a print.css file it gets even more fun to explain. ;)
Carl I usually print screenshots and include the browser window, it puts it into context.