Tag Info

Hot answers tagged

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


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


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

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


2

A few random thoughts: Focus on value. On the convincing the developers side I would be talking more about the value of the feedback. How much will it cost us to build the wrong thing, or build the right thing badly? Is the cost worth while? The developers are right. Some of the people you show it too will think that feature X will be in the final release. ...


2

What is your role? Information architect? Business analyst? Based on what you've said, I think one or more of the followings are happening: You are extremely talented at producing optimal layouts and workflows, so the designers always end up reverting back to your design. Your specification (which you said contains "wireframes + explanation of ...


2

You could carry out a mini ethnographic study, it is great that you have the opportunity to observe the users in their real-world environment. It is worth looking at: What they do How they use things What they need Information that would be great to gather include things like, contextual interviews, examples of other devices that they use and maybe ...


2

It's quite an odd question, since stakeholders and/or sponsors usually fund and initiate projects. If the stakeholders are unknown, and you have no customer party to talk to, I don't think you have a project at all. But "methods for communication" with stakeholders - we have a lot. In the 1990's and before that the waterfall project methology was popular. ...


1

When I'm working on a project, I work with a core project team and stakeholders. Stakeholders may initiate a project, but they're not always involved day to day (or even week to week). Stakeholders may also be people who haven't initiated thee work but need to be consulted in order for the work to be successful. Normally, to engage with stakeholders, I ...


1

Get a copy of - Rocket Surgery Made Easy if you can. MeeMMeem provided a great answer. The key to is to find out what users do. Avoid asking them what they want as you're likely to end up with a wish list that isn't really useful. What they need will come out through you talking about how they do things and what they need whilst they do it. Noting how tasks ...


1

This is a great question, and I'm so happy to see that you're trying to make the best use of this opportunity that is being presented to you. I gave a talk at Google DevFest West titled An Engineer's Guide to Learning About Your Users, which has a lot of advice for the best ways to go about doing it. The first thing to remember is that it's your job to ...


1

"Elaborate on functional requirements" is not a good place to start the elicitation. The users don't know their own requirements (even when they think they do), and besides, you should be trying to get the non-functional requirements at the same time. I am accustomed to work with Ian Alexander's requirements elicitation approach, and it has given good ...


1

leading to increasing amounts of iterations I think that's the best way. Iterate, iterate, iterate. To make the process smoother, try to get the client/business, UX, UI design, IX design and UI development all working in parallel (bonus if you can get back-end dev on the same page as well). When the entire team is working in parallel, it streamlines ...



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