Related
So I want to create an online booking system for reserving tables at restaurants for a personal project, but I have no clue where to start. I don't know what language to use, what to do with the tables in MySQL or anything for that matter.
Any pointers would be hugely appreciated.
This is not the immediate answer you are looking for but I'll give you some pointers base on my experience and the different situations you might be in:
Treat this as a product: Define exactly what you need (if you have, we can help you best if you tell us about it). What is your main goal, what are the features you/the client need, think about the different type of users, build a road map for the whole UX, wireframe each step of the map, prototype, test. Programming-wise, stick to your guns. For example, if you know Rails and mySQL, use that. Do you know something else? Use that then, don't even think about it.
Don't reinvent the wheel, if there is a clear and accessible (read in-budget) option don't rule it out just because. Googled "table reservation software" and randomly picked one (tablein) and it's awesome and the pricing seemed alright to be fair.
If this is purely educational then go nuts. I would suggest following the steps from the first bullet-point and then picking a language you would like to learn or get better at.
All of this is common place for developers. Coming up with an idea just to learn something new, implementing some alien technology to your own code, or creating thing entirely from scratch.
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 are hiring a UX consultant, had a broadstrokes session with the company, liked their work, think the candidates are ok and now want a more concentrated interview with the specific UX consultant that will be embedded into the scrum team.
What questions should be asking that could weed out any dead weight candidates.
Thanks.
Ask Tog has a good Quiz. I'd also ask stuff on the Gestalt principles, but that's probably because I have a masters degree in HCI (as in that might be a bit academic). That said Gestalt principles are very important especially for things like Form design.
I guess also you could ask them what their favourite book on UX design are, if they can't list any that would be very odd to me.
Personal Experience A good UX practitioner should be taking an interest in the things they use personally. I would ask them what they use personally - obvious technology items like phone and websites, and also less obvious things like kitchen appliances and vending machines. If a UX candidate can't tell me what they observed in their day so far (e.g. the car or public transport they used to get to the interview), that's a good way to weed out the dead weight right there.
Practical Problems As with programming, the best way to assess someone is give them a real-world problem you're facing (or faced) and see how they deal with it. Their thought processes are more important than the answer.
I am a UI Designer/Developer and once I gave an interview to Verizon for UX Designer position. By the way, it was a phone interview. I never worked as UX Designer before. The person who interviewed me asked me about my past work experiences, skill sets and asked me if have contributed as UX designer before. With regards to technical question, he actually sent me a document which had some brief information (part of an application) and then a small interface (it was like a table with some graphic based information, and based on this information, the call center people would respond to user request). I was asked to study this table carefully and then i was given 24 hour timefame to suggest a changed table/design and was asked to explain why would i suggest those changes. Just by looking at that single page document, I didn't understand the problem itself and didn't know what to suggest. I spent 23 hours just looking at the problem and on the 24th hour I did make a suggestion and send them my reply. But didn't work ..... i never heard back from Verizon.
As a UI Designer, I have worked wiith lots of UX Designer and all I know about UX design is that you have to understand the problem very carefully. You need to look for all posible solutions and use the one that would best satisfies the usesr needs. And then you must know how to create wireframes.
Ask them how they would go about designing the UI for some system. Tell them to design a solution for some domain which you know well (for example one of your recent projects), so that in the interview you can take the role of the user. Then the UX consultant will need to dig the necessary requirements from you, find out what is the problem that needs to be solved, and then designing and testing a solution.
Or if you want to make it easier/quicker, use a domain that everybody knows, so that he doesn't need to dig the requirements from you. For example design a system for finding out in which of the nearby restaurants you would like to eat a dinner. In one hour you should get some understanding of what the consultant is like.
Give them some screenshots* of example pages from a selection of sites, some of which you consider good, some bad, and in varying degrees. Ask them to point out good and bad features in each (and there is some good and bad in every site) and explain their thinking. If they fail to spot something obvious, prompt them with a neutral "what about X?" and see how they analyse it.
* finding these isn't hard, but a little time consuming possibly. Even better if you can give them access to an actual browser so you can go over the "live" elements
UX work is made up of two parts: Research and Design. You need to be clear which you want most emphasis on: someone who can grok out massive taxonomies and build wireframes in their sleep, vs someone who has hundreds of hours of usability lab experience. (You can find people who have both areas of expertise, but people often lean in one direction).
Beware of UX consultants who have never been embedded in a scrum team before. They will need some bedding in time. If they are used to working agency-side rather than client-side, they will be used to doing shortish research projects and then leaving. This kind of "skirmish" is quite different to the long-view you have to take when working client side.
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.
I work on a variety of projects using different languages and platforms. Parts of them I abstract out into their own separate projects, and I want to open some of these up to the public.
What gets me stuck is the christening.
So, does it matter? Should I just choose something and stick with it?
And if it does matter, what's better: a cool-sounding name that's memorable, or a descriptive name that's easier to find?
I think naming is an important part of getting ideas to spread. What I look for in a name are:
Memorable. It should be different than other names but easy to remember.
Accurate. It is helpful if the name reflects something about the project.
Positive. It is helpful if the opposite of the name is unattractive. For example, Structured Programming follows this rule because no one wants to be unstructured.
Clever. Clever is optional, but it helps make a name memorable when you achieve it. Clever ages badly, though.
It's not worth waiting to program until you have cool name. The more experience you have with the project, the easier it is to name. JUnit wasn't christened until several months after its debut.
For more information about naming, I highly recommend "Words That Work: It's Not What You Say, It's What People Hear" by Frank Luntz. He is an amoral political operative, but he loves language and communicates that love effectively.
One last point about "sticky" projects: be sure to tell the "creation myth" frequently, the story of how the project got started. Every project I've seen that has had long-term impact has had an oft-repeated story about its genesis.
I've decided to go with generic names to start because I'd rather get started quick programming and worry about names later.
This Web 2.0 Name Generator is entertaining.
If the name is to be used publicly at all - marketing, on the web, etc., just be sure you pick a name that someone else isn’t already using for anything at all similar. At least do a Google search. And before you spend money on advertising or anything like that, spend a few bucks to get a search done in one of the more specialized name and trademark databases. At least in the US, being first with a name gives you legal rights and it’s cheaper to do the search than to have to change your name later.
Of course before you go too far, make sure the domain name is available, too.
For stronger legal rights in the name, pick something that’s made up and not just a generic reference to what your product does. Somebody like Microsoft can spend oceans of money to get legal protection of something like “Word” or “Windows” - you probably can’t.
Yes, I think it matters (having been in the same position myself). I think the name either needs to be cool/memorable or obvious/simple - not necessarily both. As a rule of thumb, imagine you were looking for a program/library that does what yours does. Would the name you've given it encourage you or put you off and would you remember it? That's really all that matters.
If you look at the history of products in general, there are numerous examples of poorly-chosen names that become part of the language (Kleenex, Tasty-Freez, Wisker-Biskit), so I don't think it matters much at all from a marketing perspective. You do want something that's easy to type and spell over the phone, though. I work for company with a weird name with lots of Ss that sound like Fs, and it's a nightmare.
It matters if you care about other people using your code. Prefer memorable names. They may be memorable because they are descriptive, or because they are "cool", or for another reason. If you are putting your code on the net, it should include a description that will show up in relevant searches.
Before settling on a name for your app, you may want to check to see if the domain name is available.
Google Friendly
Something unique (or at least something you can get your homepage in the first 10 results)
Easy to spell
A point not always considered is how easily you can google your project. This may or not be a factor, but you may have an interest in keeping tabs on what the community/press is saying about your project.
If it's called "Project X", "e" , "Raptor", or "Purple Windows", unambiguous searches are near impossible. Over and above the domain name availability issue, picking a name that's not used in any other context allows you to do useful stuff like set up automatic alerts for tweets/blogs comments on your project.
Sadly most of these names are hard to pronounce/spell unambiguously, so it's a tradeoff.
I absolutely think that naming is important for your project. A lot of open-source projects have this problem that makes them get names that look cool on the screen but are hard to pronounce. This means that at minimum your website has to have a pronunciation guide, and that a lot of people will be confused about how to pronounce your project. A name with difficult pronunciation can introduce some cognitive dissonance as people try to think about your project. Is it Cool, Cooyil, Coowheel, Coil or what? What's wrong with these people that they can't name their project? If they can't name a project something that is easily readable by sane human beings in the intended target audience, can we really trust them to make a good product?
Wait to pick a good name until you have something good to name your project. Don't feel bad about changing to an awesome name once you find it, there's no need to remain tied to whatever name you were using in development.
Would be hard to suggest a name to use if we don't know what the product is.
Also, this sounds a lot like a marketing question. I would say something cool and memorable but is descriptive as well. iTunes comes to mind.
You could do both. A good example would be Shoes for Ruby. it was originally going to be called (Or so they say) "MIDAS MACLEAN'S WINDOWS OF GOOD FORTUNE" but then he decided on Shoes.
The toolkit/library has nothing to do with shoes.
I've seen project naming be a big problem. I've managed around 20 programmers working on maybe 40 projects, and it got to be a real problem when you have a project named X, a virtual directory named Y, a Visual Studio project named Z, etc. When an application writes to the error log, which project is it? Who does it belong to? We created a project database to capture all this, but it would have been better to have conventions, because the project database is not always complete and up to date.
I resisted this idea, but it may be best to have project numbers. It seems better to have mnemonic project names, but if you have a lot of projects, you run into questions of mnemonic for whom.