Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am a researcher on UX. My research aim is to help software engineering practitioners in early stages, i.e. requirements engineering, to deal with UX requirements even if their knowledge on UX and ID is poor. You know not all developer companies have access to UX and usability experts.

So far, I have realized that one challenge for practitioners is that they do not know what types of UX requirements are considered relevant for various software. So, I aim to develop (or if it's already out there, reuse) an ontology or taxonomy of UX requirements in my research. The next step is to provide tools/methods on how one can elicit those requirements and document/represent them.

Do you know of any related source? In which a list or category of tangible UX requirements can be found?

The result of my research is going to be published for free to everyone in due course.

share|improve this question
    
Welcome to UX.SE! That's a good question, Pariya! I upvote and favourite your question - since I want to know the answer too. Will you publish the link to your resaerch on this question (by editing it) or somewhere else? –  Benny Skogberg Mar 28 '12 at 8:46
1  
Hi Benny! Thanks, do you mean publishing my results? of course, I will publish it as soon as I'm done with the study. I'm in early stages now. if you mean publishing this question, I just put it on twitter :-) –  Pariya Kashfi Mar 28 '12 at 11:27

5 Answers 5

The requirements section of wikipedia's page on user interface design is a good start. It refers to ISO 9241, particularly part 10 which has been withdrawn and replaced with ISO 9241-110:2006

There's the UX principles that mozilla use as keywords to tag bugs in bugzilla which are based on Jakob Nielsen's Ten Usability Heuristics.

I've recently been trying to map the mozilla keywords to the Dialogue / Feel principles from ISO 9241 to see how they matched up:

  • Suitability for the task
    • ux-efficiency
    • ux-implementation-level
      • ux-jargon
  • Self-descriptiveness
    • ux-affordance
    • ux-discovery
      • ux-visual-hierarchy
    • ux-minimalism
    • ux-userfeedback
    • ux-tone
  • Controllability
    • ux-control
      • ux-undo
    • ux-interruption
  • Conformity with user expectations
    • ux-consistency
    • ux-mode-error (special case of ux-error-prevention)
    • ux-natural-mapping
  • Error tolerance
    • ux-error-prevention
    • ux-error-recovery
  • Suitability for individualization
  • Suitability for learning

I'll update with the definitions at some point.

Update: See also Psychological Usability Heuristics


† ISO 9241-110:2006 is a 22 page PDF costing 108 Swiss Francs, ~110 USD or 70 GBP. I'd be interested in hearing from anyone who has read it as to whether it is worth purchasing.

share|improve this answer
3  
Go to your nearest library, BL (British Library) has the full repository of ISO standards, they even bring it to you inside UK as I remember, although that has usually a high fee in order to encourage buying from original publisher. –  Aadaam Aug 1 '12 at 13:44
    
@Captain, Thanks for the bounty. –  Sam Hasler Aug 21 '12 at 11:45

I'm also a developer by profession (and I have an MSc in Software Engineering from a famously hard uni), but nowadays I do UX. What follows comes from a view of HCI perspective of UX, this is what was taught to me, this is the school I consider myself belonging to.

In general, UX is not far from IT: what developers are taught at software engineering unis as "software design" and what UML was about is basically what UX does today. Software design went out of mainstream at the end of the nineties, beginning of the 2000s, with the Agile boom (I was there, I know), so it's hard to find people who actually practice it, but most of them heard of it in university.

UX is a lovechild of Software Engineering and Psychology

Let's put this into perspective, for which I'll draw a simple diagram:

The UX coordinate system

I'm pretty sure there are many more things, but that's enough for a quick illustration.

The "micro-IT" quarter isn't empty, it's just something which doesn't have to be explained to any frontend developer on the world.

Believe it or not, for example, taxonomies are also a required study in all IT universities, and they're used every day in object-oriented programming. So it's nothing new there.

Understanding the developer: the common language

For a developer, I'd start with familiar things, like flow diagrams. I did explain the relationship between flow diagrams and so-called Finite State Machines (again, a required study) in another answer at Programmers.SE

For understanding what a developer was taught, consider reading a UML book, like this one, (dubbed the "iconix book").

As for Use Case Analysis, which deals in general how a system should behave the best book is still Cockburn's Writing Effective Use Cases

Programmers like to categorize, and most of them do like to "lego", Design Patterns are a good place for a start. Design patterns originated in architecture, then went to IT, and it went from IT to UX. Nowadays Design Patterns are still widely used in IT, but not as prevalent as they were 10 years ago.

Orientation: Goals and Whys

It is important to each party to understand goal-orientedness: typically programmers work more effective if they do understand the goal the user likes to have. We talk so much into "it has to have this button and that shadow and that transition", which are non-meaningful to a developer, if you don't tell them, why.

I feel this is also a problem in UX sometimes, a lot of "pattern libraries" concentrate on the shininess factor, instead of goals and problems. A pattern should be always a problem pattern, and should always contain the explanation why the recommended solution works for that problem.

Support your stated goals with user research or scientific papers. Perhaps give them live demonstrations or statistics from the project's own research. Otherwise, the goal won't be authentic, and you won't be respected by the developers.

I tried to do my UXes in terms of goals and problems, and patterns: for each step, there is a problem to be solved.

This is what programming education education also looks like: they present you with a problem, then wait a few minutes,then start to have a grand-scale solution, then they say, "it's fine, but", and then they dwelve into the details until a full solution is found.

Quantify, quantify, quantify

Programmers understand numbers. If you tell them it is crucial that a feedback comes within 1000 msec, they can write an automated test to check if it does. Automated tests are in full-swing fashion nowadays, and this is something they can ask a computer to test.

If you tell them it's crucial to have an answer in 1000 msec, they'll work towards that goal. If you tell them something has to be at least 1 cm long on screen, they'll work towards that goal.

But it's always important to give them reasons. Developers are not dumb, and they hate being treated as such, especially by the UX community.

For Human Factors, provide cookbooks

It's true that the stereotypical programmer is not good at understanding people. That comes from the correlation between the affinity to deal with computers instead of other people and signing up to work as a developer.

They won't really understand, for example, that humans are bad at remembering things (recall vs remember), as most of them are really good at it (it's needed for their job).

But if you have a good cookbook (10 commandments, bullet-point checklists), which they can cross at the end of the day, with explanations, it might work.

This is what the bugzilla often-quoted tags do here, they give rule of thumbs to the developers. Saying, that there's a "ux-undo" bug says to the developer, "oh yes, there's a rule of thumb that everything should be easy to revert".

A good book in such is Weinschenk's 100 things

Accept, that programmers are occupied and enchanted by technology

Programmer flame wars are about technology: you might be surprised, how much it doesn't matter at the end, which technology do you use, and yet how much of their freetime (and, ehm, worktime, actually) goes into arguing over which is the best one. They even argue between apples and oranges, and they'll argue wether it's two apples or an apple and an orange.

They also put every single shiny thing they find on a website,thinking it's "ergonomic". That's especially true for shiny interactions.

If something isn't supported well by their current technology (like, a certain widget isn't found in the widget library of the system), there, the UX designer has to invest time and effort to understand wether the technological barrier is real or not.

To sum up

I had three aims with this text:

  • To provide a general overview of what most developers already know
  • To provide a general starting point on how a big taxonomy could be categorized
  • To have a reference which someone can link later in UX-vs-Devs discussions, not just the well-known bugzilla tags

  • -
share|improve this answer
1  
Good to get an HCI perspective, that's what one of my degrees is in. We had a list of 6? axes for usability, I'll try and find that later –  Ben Brocka Aug 1 '12 at 16:09
    
It's a self-made categorization for a single talk, but software is about serving human problems by the use of computers; computers are logical, consistent, and above all, mathemathical, while humans are... human, they're "psychological". This link was considered as a pretty good start as IT engineers learn half of specification stuff, just not the other half :) –  Aadaam Aug 1 '12 at 23:21

The same basic rules apply as for websites.

Which are also the same basic rules which apply to the 'interface guidelines' which are published for operating systems (eg the Microsoft & Apple Interface Guidelines).

Basically the interfaces need to be built around the 'human' element - and this of course stays the same no matter what the actual interface is.

The basic concepts are covered in the first 3 chapters of Apple Human Interface Guidelines. (takes a while to load)

share|improve this answer
    
Thanks for sharing this Philip, these guidelines are of course useful but as you see the assumption in these type of guidelines is that a designer will use them to design, and the development circle considered as design-prototype-testing. But we know that SW development does not starts with design but gathering requirement. Some functional requirements and some quality requirements. These requirements are then communicated to designers. –  Pariya Kashfi Mar 28 '12 at 11:33
    
What I'm looking for is a collection of different user needs/values/motivations etc. that practitioners can use as cheat sheet to have a more informed requirement gathering process. For instance, how do we know that system X should satisfy communication needs of its users? why is that important to be considered in designing system X? or why should system X motivate its users to finish a boring everyday task?...or even one step before, how do we know that people need to feel connected, and need to communicate, and hate boring tasks and need to feel motivated? –  Pariya Kashfi Mar 28 '12 at 11:41
1  
I have seen people talking about Maslow's hierarchy of needs. This is of course too abstract for an engineering field. But so far, I have not seen a collection of tangible needs/requirements that can be used in SW development, as guide for requirements gathering... I guess there should be related work in psychology at least.... –  Pariya Kashfi Mar 28 '12 at 11:42
1  
@PariyaKashfi I think most of us designing software do not consider motivations of users at all. My primary goal when designing UI is to make it easy for users to accomplish their tasks. In my case these tasks are what users are paid to do. It is their job. The worse our UI is the longer time it takes for them to do their job. –  Adam Smith Apr 3 '12 at 14:58
1  
@PariyaKashfi I start by trying to understand use cases, watch the users work and from that figure out what kind of UI would solve those use cases. –  Adam Smith Apr 3 '12 at 14:59

I think the challenge is that there isn't a good way to make a simple reference for this sort of thing. The best way to help might be to teach them to gather requirements on their own (one of those teach someone to fish and feed them forever moments). Jakob Nielsen has a great article on interview users. Combine that with a simple review of some similar/competitive sites/apps and you should have a good base to start UI/ID work. This is a process that would add value with you (a UI expert) present but would still teach them some fundamentals to use after you're gone.

share|improve this answer

Very interesting question.

I assume you are looking for an answer that goes beyond:

  1. Ask for demographics of the user.
  2. Learn about the context of the user. (location, environment, socio economic factors etc. : look at work models in Contextual design by Holtzblatt and Beyer.)

The whole point of initial user research is to understand the domain and try to find the problems/ breakdowns in the system. Only after this is done can there be more specific requirement related questions. What software engineers typically get (or are supposed to get) in terms of requirements is actually functional requirements distilled (using some sort of data analysis) from the data that comes in as requirements from the customer / user.

As Andrew above said, there is no good way to make a reference for this. Part of the reason is because different projects focus on different things. For example: do you want a complete redesign? Then go ask more fundamental systemic questions. If you just wish to change the look and feel and leave the business logic alone then the questions to ask would be more superficial.

Another reason compiling a reference for this is challenging is that various software projects lie in different domains and the questions to be asked differ considerably based on the domain.

I am sure there are more ways to group software projects.

Having said this it may be an interesting project to group various types of projects and then come up with fundamental questions that would be relevant.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.