Beta version is way too late
Users are central to user experience. Why not involve your beta list into establishing a feedback loop even before the ‘beta version’ is far. Software products which are kept under wraps till the beta is release gets few eyeballs and these are all internal which means that only the people developing it or getting it developed are seeing it rather than the people who will be using it.
You don’t need everything to be working; it can’t in the first week or first few weeks.Developing a prototype with links and working tabs of initial functionality thrown in, give the prototype the look and feel of a product which users can play with and comment upon. The only thing that you need to ensure is the users are able to get a feel of a product whereas actually it is just a sketch.
The point to take home here is that before you build the 7th storey penthouse; give users a feel of the 1st floor design plan to see if they like it enough.
Get feedback through task-oriented use.
Getting beyond the features is important. The feedback loops shouldn’t be about features, they should be about the tasks that need to be performed by the users. Usability can only improve if you test and get relevant feedback on tasks and how the prospective buyers are using the system to accomplish them, rather than features based approach which focuses more on developers than users.
Understand your software from a user’s standpoint.
User’s perspectives are more important than anything else and that is where market research and one to one communication comes good. For a software product that helps in decision making, ‘reports’ as a feature highlight not important. The better way to convey is that the reports can help you share your decision making with peers/colleagues or help you in publishing your results online. During prototyping of your product, it is essential that you think the way users think and problem solving is what they are after. Remember that cliché – ‘No one wants a drill; all they want is a hole.’
Segment the process into logical chunks.
Products are developed in phases, and feedback should be used at every stage to improve the user experience. In terms of getting user feedback, the questions change with each stage and you know that the hurdles have been crossed with each iteration, including changes that are validated by a considerable fragment of your test audiences. Usually these questions will get narrower as the stages are completed.
During the first stage, you may need to ask leading questions link – Is this interface OK, will it work? Workability and proper installation/activation might form questions in the next stage of delivery. Till the time, the final ‘beta’ is ready for your users, you can test the performance, boundary conditions and bugs rather than spend time on tweaking the UI or worse even, asking your target – how does that looks?
The more the feedback, the better
Use your website, paid and display advertising as channels to promote the beta and don’t just limit your test set to that initial contact list that you’d developed.
Audience propose, you dispose
Usually, deciding the features that you’ll develop for your software development project will be a rejection criteria rather than a selection one. And you have to remember that the niceties that you wish to add to the product should be backed by ample evidence of a strong demand. This is essential since each feature requires you to take a design decision along with lengthening your code, documentation and support files and may be adding a few personnel to augment your support staff strength.
Know when to put the brakes on
Some users will request more and more and you assume that satisfying those means you have a super product with a great UI. But you need to ask yourself a question – Is that adding to the ease of use and task completion or is it just creating commotion and users feel as if they’re driving a fighter jet with hundreds of settable options which they don’t know what to do with.
Using a cross departmental approach including the market research people and top management might be a good idea to quantify actual demand. It is essential as it will be an enormous task to pull something out which is already in as compared to deciding if something can wait for the next version release.
Use your UI to give the user a sense of context
The UI/user interface should tell where the users are and at least get them to where they highway is. This highway may be a dashboard, a homepage, a task list or virtually anything that gives them the sense of direction. Enriching the value of this highway will help in an above par user engagement.
Only a sense of direction, no directions please
Dictating the way, users should use the system make your UI/software a dilapidated structure which is about to crumble. You should be better off observing the baby learning how to stand up on its feet rather than helping it. You may give them a hint, a hot links option, related topics or help files but do not try to spoon feed.
Should problems be fixed? Yes, but with some thought process involved
You can quickly fix a problem based on your users’ feedback. That’s the easy way out, but can you think over the problems to see if the information display or product function design can itself be improved. Usually things inaccessible provoke a presentation change idea, but if that’s the root, information display or assistance in it might be the right answer rather than that ‘quick fix’.
The ball should roll on
User Interface improvement efforts should not stop till the product/application itself has been called off. Users’ feedback should be continually sought after and improvements rendered in a way that enrich the user experience.