Tag Info

Hot answers tagged

12

My favourite illustration about design processes is the following: Don't even care about where does it come from, it's the long-forgotten old-style software design (when there wasn't separate UX and technical design, there was software engineering, and engineering processes), but it still holds the key. As you see, all start roughly at the beginning, but ...


11

I think you risk the requirements vs design debate here. Wireframes are pretty important but I think it depends how you conceptualize them. The following is my own opinion but backed by pretty standard industry processes in my experience. Requirements should generally be written only because you are describing what a solution needs to do. They should be ...


11

I would strongly recommend reading this excellent article on smashing magazine on Lean UX,to paraphrase the article: Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed. Traditional documents are discarded or, at the very least, ...


9

Jon's answer is great and has the basics, but here's more detail in case you need it. 1) Figure out your audience. This could be customers, staff members, etc. Depending on your application you may have several types of audiences, and that's okay. 2) Come up with some user stories. These consist of roles and desires, involve both your audiences and ...


9

Simply put: Figure out WHO this project is for. Who are they, how do they act, what is their level of expertise. Business requirements, what needs to happen (interaction wise) to make the right amount of $ What information do they need to get to. How should they get to it in the easiest way possible.


8

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 ...


7

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 ...


7

I can think of three critical questions to ask upfront. What are their business goals? What sorts of behaviours are they looking to encourage over the next three to five years? More sign ups? More word-of-mouth circulation? Did they already have any ideas how the site could support this? What issues have they already identified with the existing solution? ...


6

Terms like "Functional Requirements document" are notoriously ambiguous and often misunderstood, especially when documents are being passed between design and development teams, so it's often best to define the purpose and scope of the document you are producing Before you begin, to get agreement on the content and format In the document itself, to avoid ...


6

I use Storyboards in PowerPoint in semi-high fidelity. I find written documentation has major flaws. People can't react emotionally to interactivity by imagining it from text. You can't write a paragraph on how something will work and have people understand the nuance of the interaction design. It's like writing "The graphic design will be beautiful ...


6

what do you think are the main differences in methodology between "Requirements Engineering" and "Usability Engineering" Personally, I would not separate these out. I spend a lot of time acting as a business analyst for projects, and whenever possible I make sure that usability is part of the main requirements gathering effort. They may be listed in a ...


6

We have developed over the last few years our own SWE BOK in our company, and there we see the two disciplines like that: Requirements engineering is the first of the disciplines which looks at the problem of the customer (only). It has to ignore completely the solution (even if you think you know it). Usability engineering has to think about how to make ...


5

It seems like you have two issues: Verifying/understanding user requirements; and Convincing your team that testing is a good idea. Verifying/understanding user requirements When trying to understand or verify user requirements, I try to stay from using any type of mockup or prototype. In this stage, I try to understand the problem not attempt a ...


5

The goal of indicators like this is to inform the user when something is different. So, let the form tell you how you should approach it. In general if most of your form is required, state that up front and then flag Optional fields accordingly. Inversely, if most of your form is optional but a few are required, flag the required fields. This short post ...


4

For various reasons I have to deal with this issue almost constantly. What we do here is: From the outset make it clear to the team that the subject matter experts and the domain experts will be needed for the requirements gathering. Meetings & interviews with them will occur. As we write the requirements I always note what user need is being addressed ...


4

I think you're misreading that banner. It most likely reads "If your download doesn't start in ### seconds please click this link." (Emphasis mine) The reasoning is pretty straightforward. The developers have done their best to make the download automatic. However, they know that with the wide variety of browsers, plugins, and security settings that ...


4

The user experience will suffer if you make it a past-input check. Users enter content, probably write a bunch of lines and get a message about how it isn't okay after they did all the work, this leads to a bad experience. So you have to display the potential errors on-the-fly. Like "Still 100 words to go" Also, you should consider analyse what high ...


4

As The technologies are changing and evolving we can experiment so many designs to perform the same task rather than use a red star in front of the required field , Its a good practice according to the ux point of view not to make the optional and required field messed up , make them separate and let the user fill the necessary information . Most probably ...


3

The team I work with has one person handling both the business analysis and design (who just happens to be me). I vary between starting with requirements and starting with rough mockups/wireframes, mostly depending on a couple of factors: Complexity of the task: if its something simple, I'll probably just jump to a wireframe In-person or distance review: ...


3

I used to try to achieve the same thing in Java Swing. Just select everything when the textfield receives the focus. However, doing so may actually introduce more issues than leaving the selection away if not carried out properly. If you opt of the selection upon focus gain, at least the following points should be checked: The focus can enter the ...


3

There are two possible scenarios here. We assume that by default the user wants to replace the search term. In this case the selection aids him, and in case he wants to refine rather than replace the term, all he needs to to is hit "end" or "home" or any of the arrow keys, and the selection is canceled. We assume that by default the user wants to refine ...


3

My frustration as a BA is the lack of clarity between "Requirements" that are testable units and "Design" which, when created as part of the requirements actually BECOME requirements. When the business signs off on a low-fi or a high-fi wireframe, they have made that visual their requirement. Now I'm writing testing scripts to ensure that the wireframe is ...


3

Mike Cohn published in his blog a good article, arguing to use User Stories for Requirements. Because User stories emphasize verbal communication [between devs and customer] They can be used readily in project planning. [...] use cases, on the other hand, are generally too large to be given useful estimates. User stories encourage the team to ...


3

Hiding your T&C behind a dropdown is probably very dangerous, since a user could legitimately claim that they never saw the T&C.Check out what happened to Zappos: http://blog.ericgoldman.org/archives/2012/10/how_zappos_user.htm .


3

GlenH7 is right; the banner says "If your download doesn't start in ###...", the page attempts to start it immediately by using JavaScript to open the link and gives you the link in case the JavaScript does not work. The link also does work immediately. After all the JavaScript just does document.open(that link). Now the bigger question is why they gave you ...


3

I swear that I will repeatedly tell users that nothing is guaranteed to actually appear in the final product, and that it may end up looking nothing like the mockups Tried that many times, it simply doesn't work that way. Problem #1: Users will have false sense of progress - There is nothing you can say or do to explain to your customers that what you ...


3

Whether to split the menu up into categories depends on how many options you have available. What you should be thinking about is how quickly can a user scan the menu and find what they are looking for. In western cultures a user will read from left to right, top to bottom. The first example you give is a little cluttered looking and makes me do too much ...


3

Put it to them this way: these days, the word "integer" gets taught at elementary level. Most people are going to know what it means. I do see their point for more technical terms though - if people aren't going to understand, you have a problem. A possible solution is to add a clickable question mark icon next to technical terms that produces a definition ...


2

I use BasecampHQ for this sort of situation: create overall projects and projects for each sprint follow message threads within a project and attach documents to messages messages are usually copied to email - and can be replied from email get a collective view of all the files attached to that project collaboratively edit documentation via the writeboards ...



Only top voted, non community-wiki answers of a minimum length are eligible