Does anyone have recommendations/experience of how to find people willing to do usability testing of web based apps? I suspect I may need people who might actually be potential users, because mine is a commercial/vertical app which contains some processes and terminology which may not mean much to the average joe/jane.
I have a fairly robust prototype of a web app which is designed for people in Sales Management and before I go too much further with it I want to try a couple of key pieces out on some live users. I have a few friendly faces I can turn to (and have already), but I really want strangers who will not feel they need to be nice to me about it.
I'm fine designing the usability tests themselves, it is finding the guinea-pigs that is proving difficult.
I've used this service a couple times and have been impressed with the quality of the feedback they provide.
usertesting.com
Don't Make Me Think has the exact chapter you would be interested in. Basically, you should set up your test in such a way that it's not about being nice or not, but it's about finding out whether the user can use it or not. This way you can use all your relatives or friends you want and know.
In a nutshell: set up a desk with a computer that has access to your app, get two chairs, a notepad and a pencil. The book mentions a video link to your co-workers, but let's skip that. You get your tester and place her in front of the computer, while you sit beside her with notepad and pencil at the ready. Be specific about that for the sake of this test, it's technically impossible that she would do something wrong, because that's what you are interested in.
Ask her then to do some specific tasks; You present her with some kind of state in the application, and ask her to do something. Example: "If you would want to do a new entry, how would you go about doing it". Ask her to describe what she's thinking, her train of thought; "I would seek for some kind of 'add' or '+' labeled button, let's see if I can find it. They're usually underneath the lists", etc. Make notes of the subtleties of her gestures and faces, like if she hunts with the cursor for something, or if she's grimacing in frustration.
If she can't find that add button quickly enough, there's a usability problem.
But really, buy the book. It's a great read, worth every penny.
Do you have a list of local companies who could be potential customers for your application? This would be a good place to look; you can simultaneously get users for user testing and make good contacts.
Take yourself to Starbucks and put a sign on the back of your laptop which says "Ask me for a Free Coffee" make sure you use some screen recording software like Silverback to record the session for later.
I read this a few days ago and it might help:
http://www.joelonsoftware.com/uibook/fog0000000249.html
Does your organization have a Sales team that will allow you to borrow appropriate users? I think that would be a good start for Alpha testing of the UI. After that, perhaps your customer can use the Beta UI for further testing.
Believe it or not an ad in Craig's List works for us. Simply offer a reward, we use $50 prepaid debit cards, and you can usually get 10 - 20 people per ad.
see useit.com - there are several levels of usability testing, and it is obviously critical to recruit users that are representative of your target market
You could also check out uTest.com, a software testing services that relies on "crowdsourcing" the testing process. While more on the side of functional and technical testing, I'm sure you could negotiate a test project more focused on usability testing.
Related
How do I go about explaining that I am a "Web Application Developer" and not a "Web Site Designer" to prospective clients - without talking myself out of the project?!
Often I am approached to "design a web site" for someone where it turns out to be more of a "brochureware" presentation site and less of a real web application.
While I am a highly skilled developer, I am not a graphic artist. That said, I would still like to be able to close deals with prospects without disqualifying myself. Simply stating, "I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
Sure, I can just subcontract the project to a real designer and mark up his rate, but I would rather be up front with the client that I am not going to be the guy doing the actual work and they would be paying $120/hr for $60/hr work.
...and then they will ask price - is visual design often quoted hourly like app dev is, or will I get sucked into the oblivion that is fixed fees?
First thought: You sound like you're a good developer, which is a great foundation in this situation because people feel that we have a broad understanding of technology -- and they're right! You're correct in your insecurity though - a good developer is not exactly what they're after.
They want a solution, and if you can become the guy who knows how to navigate all the complexities involved in delivering that solution... Well, then you're the guy. And you're much more valuable.
And you don't have to stop coding, either. Which has always been my phobia.
So that's more or less how I present myself to my clients. I'm a developer, but I'm also a competent project manager. I know how to take your project from here to done even though it may involve designers, IT guys, additional developers, datacenters, etc.
Working with other professionals: You probably aren't in a position to hire folks. That's fine, but find good partners, and you can market your self as a shop or consulting group that is good at more than one thing. Believe me, people will appreciate that! For instance, we have a fantastic partner in Romania that we use for a lot of design, and we add value because we know how to get results from them and handle all the communication and so on. My customers don't want to talk to 3 to 6 people, they want a single point of contact who is accountable for all of it.
One thought here: try to find people who do this full time. Moonlighters and people doing side jobs have constantly let me down. I sympathize; I know what it's like to be spread too thin.
Fixed prices: You will probably have to deal with fixed prices, and you will need to hold your partners to fixed prices (or have some other mechanismf or controlling costs) if that's the case. Once the relationship becomes more comfortable, I usually try to give clients a range of what I think a job will take -- 5 to 8 hours, etc. And I let them know that fixed prices are a little bad for them because I have to assume some risk, which means they get charged more.
Most companies still want actual fixed prices for larger projects though and many large companies are shockingly comfortable with being overcharged in this situation. Fixed prices seems to be unfortunate fact of life in the contract development space.
First of all, I think you're exaggerating a bit - you don't really want to have a $30/hour designer working on a $150/hour website. If you do, and your client doesn't notice a difference, they deserve what they get.
And if we're talking about, say, $60 - $75/hour range vs $150/hour (which, IMO, is more realistic), you have to count in the time you spend working with said designer, so it's not like remaining $75-$90 goes directly into your pocked with you doing nothing.
If I am a client, I want a FINISHED PRODUCT and I'm paying YOU to deliver. Consider yourself a general contractor. I DON'T WANT to deal with designer / tester / technical writer / what have you myself - that's what I'm paying you for. My time may be a lot more valuable to me than $90 / hour difference. I may (will) get a second / third / fourth bid if I think you're too expensive.
That said, if you need to placate your conscience you can always bill couple hours less.
I tend to say something along the lines of "My job is to develop the stuff you don't see, but that make your site work"... And that is actually quite true.
... And you might add something that says that building a website is an activity that requires several very different abilities, like :
creating something that looks nice, and is usable ; that's a job on its own ; do your client have designed to logo of their company ?
integrating this nice looking thing into a dynamic application ; that one is your/my job ^^ Your clients send/receive e-mails every day, but do they know how it works ?
administration of the hardware / server : your clients use a computer every day to go in the Internet, use Word/Excel and the like, but do they know how to install those ? How to secure their network ? How to deal with security alerts the right way ?
You can use analogies with other processes ; designing / building / using / repairing a car, for instance ; some people understand better when we just don't speak about computers at all...
The way I always try and explained it, since I'm a Developer not a Designer is.
Developer -> Makes it work.
Designer -> Makes it pretty.
Of course there are vest generalizations, but for the most part they're true.
-> Developers creates the product
-> Designers create the package
Do you bill enough hours that you could consider hiring a program manager/product owner type person at least part time to do most of your customer interaction? Because if you do, you can abstract the "design/code" questions away from the customer; let the program manager really focus on figuring out what the customer wants built.
It sounds like your average customer isn't that technically savvy. If that's the case, figure out a way to speak their language (which most experienced program managers can do). They really don't care about the difference between a designer, a developer, and a tooth fairy that shows up and delivers the site that they want.
It's also worth considering whether you really want to take on projects that are mostly web design. If not, you should work on improving your marketing materials to focus on what you do best (interactive line of business web applications, or whatever).
You can steer the conversation toward what business problem the customer wants to solve, and propose the statement of work that best matches their objective. I think this will do the most good, and then it's never a question of misleading them. It's about packaging up a solution that matches what they want.
"I do backend work, not frontend" will quickly end the conversation, and along with it my opportunity for work.
This is not necessarily a bad thing. It's generally a good idea to be honest with prospective clients, and if they do not understand exactly what your job entails up front, then they may end up expecting too much from you when the job is done, or for future projects.
If you do really want to push your services on them, you could always try to point out exactly what kinds of benefits you will be offering to them. Make a point in explaining how much value can be added to the end-product by using your expertise.
A car may look great on the store floor, but if its powered by a lawn mower engine held down with duct tape and chewing gum, the only thing it's going to be doing is looking pretty and collecting dust in your garage.
We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!
I'm working in a small development group. We are building and improving our product.
Half a year ago we couldn't think about higher characteristics, such as usability, because we had so many problems with our product. Many bugs, high technical debt, low performance and other problems kept us from being able to focus on usability.
With time we've improved our process substantially. What we've done:
Real Agile iterations
Continuous integration
Testing(unit-tests, functional Smoke tests, performance)
Code quality is 'good'
Painless deployment process
So we are now producing stable, reliable releases. The following quote (paraphrased) describes our current situation:
first - make it work; after that, make it reliable; after that, make it usable
We are geeks, so we can't 'make' a great UI by ourselves.
So what should we do? What direction can you recommend?
Maybe we should hire Usability experts part-time or full-time?
How can we explain the importance of Usability to our stakeholders?
How do we convince them that this is useful?
What do your Business people say will make you the most money? Do that. Maybe usability is the next thing to do, maybe more features, maybe a different product. It's not something a "geek" will necessarily be able to guess.
I'm in the same boat as you are - I basically live on the command line, and I'm completely out of touch with the modern UI (both web and desktop application).
The solution for me was using a real UI developer for all my GUIs, and I just live in the back-end as it were.
There are quite a few benefits of this arrangement:
You don't have to debug your own crappy UIs anymore :) that's their job, and they're better at it than you, so no worries.
Your code will naturally gravitate to a MVC or at least tiered API approach, which is easier to code against for all parties involved.
Good UI people know what questions to ask end users, and know when those users don't know what they're talking about. I certainly don't have that skill.
You can do what you do best, and they do what they do best, making a stronger team overall.
The cons are obvious - you need to not only find the money for a talented UI dev, but you need to find a talented UI dev!
Now, I can't speak for you and your company's position in your market etc etc (I also don't do buisnessspeak :) ) but if you can afford another hire, it will give back more to the team than the cost of the position. It did for me!
You ask, "How can we explain the importance of Usability to our stakeholders?" but I'm not sure that you yourselves get it!
Interaction design (iD) and usability aren't things that you can tack on to an existing products when the "important" things are done. They should be there from the very first start, preferably done in small iterations with small tests and studies. I'm talking about cheap and dirty iD/usability, stuff like lo-fi prototyping, user testing with just four people, having enough stats to be able to detect user errors and such.
If you don't to iD/usability from the start, you risk ending up with the same crappy product as your competitors and/or providing users with band aids when they need surgery.
What do your users want ? They're probably the people best placed to identify requirements.
You are the ones who know and understand the product, so don't assume that just because someone else has 'usability expert' in their title that hiring them will somehow make your product usable.
Also, don't undercut your own instincts for usability. As a programmer, you use software all the time, what products do find the most usable? Think about what you like about them and compare them to your product.
Think about what your product does, and imagine that you are the person having to use the product and imagine how you would want it to work. Think of what a user wants to accomplish using your product, and imagine the steps they would have to go through to do it. Does it seem easy to understand what to do? Can it be done in fewer steps?
Most importantly, talk to your customers. Find out what they found confusing or difficult to accomplish. See if they have come up with their own workarounds for using your product in ways you didn't initially picture.
If you put as much thought, planning and effort into usability as you did into improving the reliability and deployment, you will end up with a much better product.
When analyzing the next step it really all comes down to business requirements & goals.
What is upper management like? Are they tech-savy? Are they open to new ideas? Do they think that the current product needs adjustment, improvement, etc? Is the product still in high demand? Is the marketplace changing such that the product/service will soon be obsolete? etc. etc. etc.
IF there are real business reasons for spending the $/time/resources then you can begin to explore product improvements. At that point consider the opinions of previous posters regarding user opinion.
I know so many geeks including myself who know usability, so one way would be learning it. Another way bringing someone in who can do UI design and usability.
To convince them that usability is important:
It's useless if you can't use it!
I don't know what sort of product you build but you always got clients, and clients always love usable applications. This will increase sales, happy client count and decrease tech support.
What does it do for your users? What do they think about the usability? Maybe it's not an ssue for them.
Make it more valueable to your users. Deliver more business value. Help your customers getter a better return on their investment. Do this by making it do more of what they need it to do, to do it better (more accurately, more quickly, more reliably more useably), or to do it at lower cost (less infrastructure needed to run it, reduced maintenance costs because you improved reliability), more flexibly (deals with their business changes)...
Lots of dimensions which do connect with the technical ones you refer to (usability reliabilty stability etc). But paying customers normally care about their business needs/features, not your technical ones that deliver them.
Go talk to your users (or potential users)
My one-liner about the importance of usability:
What use is a reliable system that is not usable?
If you have an existing product with existing users, then what makes you think that your current UI is not usable?
Do you suspect that there are some minor changes you can make that will greatly improve usability or is something more revolutionary required? If the latter, then what about the needs of your existing users, will they be willing to re-learn a whole new UI?
Edit
A user interface can be considered "poor" for a variety of reasons...
It is just plain ugly / old fashioned / does not "look like a Windows application"
It uses metaphors or workflows which do not relate to things that the user understands or wants to do
The first of these is relatively easy to fix, especially if you hire in a great designer. The fix would be the equivalent of redecorating your lounge and buying a new sofa and TV. Same room, different experience. Your existing users would still be able to use this application.
Fixing the second of these gets a lot more complex and involved, and might really impact your codebase. It's hard to comment further without knowing more about your application.
I think the answer is in the order of things, you say its:
"first - make it work; after that, make it reliable; after that, make it usable"
But the most important thing here is "make it work". Acceptance criteria for a functionality to "work" is that it is in fact - usable. If not, it will not be executed. Then it's just a block of dead code. And dead code should not be in the system in the first place.
Make a UI.
Then throw that away, and make another after you tried to use the first one. Then simplify as much as you can. Any time you can programmatically determine what the user wants from inputs, instead of multiple explicit choices, do so. Too many buttons induces paralysis.
Personally, I've found that when good developers deal with clients, they often get sucked into the after-sales support process and this process has been difficult to reverse, so was just interested to hear the various strategies that developers employ in maintaining a healthy, useful relationship that keeps clients using the right person at the right time.
So do you and, if so, how do you deal with clients?
Just a tip: Write down every single thing a client says to you.
Most of the projects I work on are done on time-and-materials contracts, which means: we give the customer an initial estimate of how long the project will take but bill for actual hours worked, whether over or under the estimate (I don't know why a client would agree to this, but they do). Once the project is "complete" and in production, we set up a service extension to the time-and-materials contract, creating a block of billable hours to cover after-sales support. When a client is aware that they're being billed for all contact with us, they tend to keep that contact to a minimum.
One other point: I've found that it's best to communicate with clients via email where possible. It's a much more efficient way to transfer information (assuming everyone involved can write), and it leaves a permanent record of what the client told you to do.
I'd go the opposite of what have been said.
The client is your number one information source
Avoid intermediaries (human and technical)
Keep tracks (not to use it against the customers, even if it can happen, but because he pays to get what he wants)
Communicate - on your initiative - in a short regular basis but for small amount of times.
Any doubt can be cleared asking the good questions. The guy don't want that ? Get rid of it (even if you like it better). The guy want that ? Why not, add time and money on the contract.
You must train your communication skills
Most of what has been said here before is essentially related to the fact that programmers usually have poor communications skills. So they fall into the typical traps :
customers give them bad info
they waste time
they get stressed
At the end, nobody is happy.
But with trained communication skills you will learn to direct when, how long and about what your chats will be, and so :
Make any deal quick and nice
Give confidence to the client
Understands what the client wants (not what he says he wants)
Ensure is satisfied with the answer (even if it's nonsens for you)
Everybody will be happier : the customer will feel good and let you work in peace while you will have the information to keep working. Eventually, the resulting software will be better.
Think talking to customer is boring ? They think it too. And paperwork is boring as well, but you must do it, so do it well instead of looking for excuses.
This is a pain we feel as well. Once you help out a customer it is too easy for the customer to directly contact the developer later on and request support. And since we usually aim to please, and probably feel sort of responsible when the application we built for them has a problem, we too often give the customer a quick helping hand.
I think that the developers should be separated from the customers, but this requires that the company has a support/concultancy department which can fix the problem instead. They in turn should be free to contact the developer, unless it's a huge company with a mainstream application where there is a less risk that the problem can be traced back to a problem with the sourcecode.
But let me tell you, I understand how difficult this is. I've been working in our consultancy shop for many years, starting from support and now I'm mostly managing the other consultants and developing. There are a lot of customers (like hundreds) who feel they have a personal relationship with me, and assume that they can call me directly even after years and years.
My tip is to make sure you have a good network of concultants and supportworkers who can help the customer for you, and have them contact you instead if they can't figure it out.
I just finished my education and am working at my first job, but here is what we do:
I communicate through a third party from the same company with "higher rank". The third party is someone knowledgeable of the requirements the software should have, but not in software engineering. When I ask about specifications, or send them proposals he distills the essence of their answers send them to me.
I think this way of working with stuff limits the amount of bullying a customer can get away with when it comes to changing specs, expanding specs etc.
For me it's especially useful since I'm only 21 years old, and people might have trouble believing I can get things done.
best practices:
Remember the client is the one who signs the checks.
Users work for the client.
Refer any user requests to the client for approval.
Always deal with the client because they understand that everything you do will cost them money.
If the client wants after the sale support and is willing to pay for it then give it to him cheerfully.
Oh and what MusiGenesis said!
The best way is to never ever ever give your direct line to a customer. Have them go through Tech support (if it exists) first. We employ this method and it works well. The software developers are the last resort - for things that support simply can't do/don't know how to fix -- such as a DBA not knowing that the servers are instanced. But it will cut down on the "it's not connecting to the internets" type of phone calls.
You could also force all support requests to go through email/secretary. At that point, you can discern which ones are critical, and which ones can be solved with a simple 'tutorial' on how to fix the problem.
And as stated above - record EVERYTHING in an exchange with a customer. Doing so prevents the 'well he said she said' deal that customers can fall into.
Then again -- if you're getting a ton of customer support issues, you should be looking at the cause of it - whether it's a training issue, or whether the software is legitimately buggy.
In our company, every developer is also a salesman. If I step over the door of a Customer then I'm in a good position to make more business.
They know me and I have credabillity because I've allready delivered to them.
I have knowledge about their business
I use my knowledge to ask questionas about other parts in their business
I plant hooks to them when I talk to them, in their best interrests of course.
I make clear that we are not a "hit and run"-company, but there to really support their business.
Maybe this is not how all company does, but I think you should use the people you have that allready has a foot inside the customers company to really work with them and make more business and tie the customer tighter to you.
I personally think developers should never interact with clients. This is why you have the Q/A team. They get requirements, hand them to developers, discuss any issues, schedule development progress meetings. If developers have questions, the go to the Q/A personnel responsible for the requirements and documentation. Developers are engineers, not salesmen or negotiators. They should be given environment to develop stable, working code without getting distracted by customer phone calls. This is how many companies deal with customers regardless of company size. In the end, your chances of completing a project on time are higher than when you customer calls up and decides to change requirements or requests a feature. Which would probably mean you have to go back a couple of iterations and change something that may break everything completed past that point.
Lots and lots of communication. Communication can be as simple as checking in with your customers by stopping by at their desks (if you are co-located) or keeping in touch over the phone. The more personal the communication is (in-person beats phone call, phone call beats email, etc.), the stronger your relationship will be.
Another good conflict resolution practice I've used is keeping as much information as possible in a single, shared place. I've used a bug/feature database (JIRA), a wiki, and even a network share drive for this purpose, but the point is that neither party has exclusive lock/write access. Updates can be made together with your customers, and there is a clear, public record of the change history of your system.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?
Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.
It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.
Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.
I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).
It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.
There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.
If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.
Buy her a book for her birthday on ASP.NET or PHP.
A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.
Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.
If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.
I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.
Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)