Related
I guess this is a question that may interest many, so please discuss! :-)
Now, imagine you want to show people you work with a concept for future development (like a new product or a new technology you want to introduce).
Does it make sense to show code early or would you go with the PPT first? Or what would you recommend?
+1 to Stijn, because really, that's all that matters.
But, it really depends on what you're doing. What is your "concept"?
An API (e.g. mapreduce)?
Show the code of the API, don't waste people's time with the implementation code, that's not important - "hey, check out how I iterate over your input! it's so clever!". Nope. Nobody cares. If your API is wonderful, it will get used, nobody cares how crufty the code is to make it work.
A product (e.g. facebook)?
Show the code? Nobody cares. Not even facebook cares (if they did, why would they use php? I kid!). Blow their mind with a demo of the half-complete prototype that does a few things poorly, but shows how great it can be.
The implementation itself (e.g. a new std::sort routine)?
A lot of people might be interested in seeing the innards. Especially people on SO. So, publish the code, or a whitepaper, when you get something working. It's not "my twitter clone is gonna be sweet, check out how cool my TruncateTo140Chars() function is!". On the other hand, you can get quick feedback on your new implementation's approach by showing your algorithm (in code or pseudocode). You can show benchmarks, which is better than "this code should be faster because I do one less compare with zero".
Please just prototype, get something demo'd that your Users will care about. Only worry about the code if that's what your users want to see (It's usually not).
I like the no-bullshit approach of a proof of concept. Just blow them off their feet and prove that it works.
It depends on the audience and the nature of the product. If the audience and/or product is considered "technical" than consider presenting code. However, you should make it an integral part of the presentation not the entire thing.
I don't believe it is very useful to show your code early. "Us" technical people are always proud to show off our new technical details and ideas. However, people using the products and technologies are only interested in what they can accomplish with it. They will often not share your enthousiasm of the techniques, in this case the code.
My advice is to stick with a more general approach, explain why it's useful and how it will make their lives better. To add a car-analogy: people want to know how much horse-power it has, not how a combustion-engine works!
These implementation-details might however be interesting to your co-workers!
If it really isn't tech people at all, then I have found out that paper models works great.
People are scared to criticize when it has been coded, it much easier (and cheaper) to scrap a paper model then the real thing.
When showing a concept of a website/application to a non tech, draw the different pages, the login dialogs etc.
When showing a concept to a fellow developer (if he just don't get it) draw the different classes on paper and show the relations. UML could be useful here if both of you know the syntax.
Else if you got the time, I would say, blow them away with a full implementation :-)
I agree with rtalbot. If the audience is non-technical, perhaps future users, or your boss, I'd go with some diagrams. Perhaps Use Cases. Show them what you can do with it. If it's small, and your friends are nerdy, code up a smoke-and-mirrors demo.
Show customers / stake holders the prototypes early, and review the code among peers later.
Stake holders control what functionality you want to deliver (finding this out early is key to delivering something profitable / useful).
But to increase code quality, code reviews are extremely powerful if done at the right time. My experience has been that doing this towards the end of an iteration provides the most bank for the buck. Your mileage may vary in terms of the optimum time to perform code review (junior devs need review early and often, senior devs are usually fine until later).
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 on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.
Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?
I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:
If you give them the opportunity, they WILL break it
Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.
I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.
The section I'm referring to is Choices:
Every time you provide an option,
you're asking the user to make a
decision.
This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.
Instead it just does lots of things badly.
Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.
Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.
Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.
Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.
Lessons I take away are:
Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.
Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).
Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.
Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.
Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.
Yup, it's harder to program. Embrace it.
There are at least two ways to build a good software product:
Focus on a narrow set of functionality, and implement that functionality very well.
Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.
Unfortunately, there are many more ways to create a bad software product.
Your questions implies that you can either provide a flexible solution OR make it foolproof.
I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be:
How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?
For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there.
That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.
So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.
The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).
On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.
It's all about who's going to be getting them.
Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.
I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.
I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am writing a system requirements document and need to include non-functional requirements relating to the usability of the system, but am not sure of the best way to express this.
"The system shall be easy to use" seems a bit vague to me, and not testable. Are there any 'official' standards/guidelines that can be adhered to relating to the usability of a program?
Usually, we try to hash out an application-specific definition of 'easy to use'. For example, for our current project, easy to use means:
-All delays in the system longer than .5 seconds will produce a dialog box that says "Please wait."
-It is possible to reach any given system function from the main window in less than 3 clicks.
-It is possible to accomplish any given task with just the keyboard, without the mouse.
-All buttons in the system will adhere to established button convention (link to established button convention regarding size, naming, position, etc.)
-All screens will have a help button. Each help button on a given screen must provide at least one 'topic' for each control on the screen.
-etc.
These sorts of things are testable, and taken together, constitute a 'pretty good' usability standard. That said, nothing substitutes for actual users trying it out.
Usability requirements are hard because the only way to know if your system is usable is by having real users try it out. How will you know if your requirements have been met? To do that, you need formal metrics for usability. Those metrics have to somehow be extracted from the results of usability testing, and if you abstract your usability testing to the point where you're just getting metrics out, you're missing out on its usefulness.
Some items like "must be able to do X with Y many clicks" or "system must respond in Z milliseconds or less" are useful, but they're actually functional requirements that have to do with usability, not usability requirements in themselves. It's quite possible (if not likely) that you can design and implement a system that meets all such formal requirements and is still frustrating for the users. Again, the only way to know is through usability testing.
Well, 'The system shall be easy to use' is exactly the kind of documentation that frustrates both designers and developers, so let's see if we can do a little better than that shall we? :)
To start with, you may find it helpful to sit down and imagine exactly who the intended user is. Give them a background, give them a bit of colour, then send them to your imagined application and try and figure out how they as individuals would want to interact with it.
Remember, different users are concerned about different aspects of usability. Don't just concentrate on the story path you think you would follow if you were using the application.
Next it might be helpful to break the site down into usability components. Does it have a lot of pictures? If so, what's the best way of presenting a lot of pictures to a user. Does it have a deeply nested menu structure? Might there be a better way than a sitetree to help your users navigate their way around?
Usability design patters will help you here. A good resource for design patterns for usability can be found here and here. Design patterns are good because they clearly explain to everyone involved how certain functionality is supposed to work.
Take a moment to consider accessibility in combination with usability. How the site work with javascript turned off is always a very good place to start and can be a great help to developers who tend to get very tired of watching their designer stick yet another <a> link on a page that is going to need to submit a form.
Remember, usability is about clarity and it begins with clear communication to the people building the system. If you can't speak clearly about what you want built how do you expect the developers to build something functional? Take the extra time to paper prototype if you have to.
My reply may be a little too 'web' focused to be of enormous use to you, but I hope it provides a few useful tidbits amongst my ranting.
Metrics & Usecases.
We have a number of personas that encapsulate our different customer types.
We have the user poweruser (George, he's a nerdy, university type),the non-tech person (Frank, who can barely use a calculator) and someone in between (Susie, she knows how to surf the web and can talk to tech support but don't ask her what emacs is).
Based on that we say:
For feature X, George should be able to access it without using the help or pausing longer than a few seconds, Suzie may need to look at the help but probably won't and if Frank does it better be real clear because he doesn't have much patience.
Now, for metrics, we also have usability study guidelines, like out of 10 people, 8 should be able to access Feature Y without looking at the help or be able to do it with 30 seconds.
Those are really subjective, but it might help you get going to in the right direction. Plus, it may help you talk to non-developer types who "just want it to work and be easy".
It wouldn't hurt to read Joel on Software articles too.
The most unambiguous way to include usability requirements in a requirements document that I could find is: make lots of screen mock-ups (and connect them with the "flow" of the performed actions, e.g. by having an arrow point from one item at image1 to the relevant next item on image2 etc.). If people actually see how something is supposed to work, it's easier to understand and leaves less room for interpretation.
Here's GNOME's documentation regarding human interfacing. This is intended as an example of how to specify, not what to specify (as I don't agree with everything they're saying in there).
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.