It’s never too late to consider “Mobile First Theory – By LukeW”.
When you start developing new idea in today’s scenario, first think from mobile point of view (primary development) not desktop view (secondary development).
As per industry research in 2013, we have 3 times more devices on earth of our population.
There are lots of articles, principles and guidelines available on Internet to tell how to develop/design mobile stuff…
For Android –https://developer.android.com/design/index.html
Problem To Solve: –In this industry problem is solved with innovation, development of app, services and software, which are the path to make human life easy. To reduce human effort we require technology solution. This means first identify the pain area/problem to improve and then propose new solution/product/service.
Business Goal: –Find out the service business goal, have discussion between stakeholders, management and business developers/sales team and try to match business goal and UX goal.
Target Audience: –According to your product/service USP, find out right target audience (geographically as well) and in this type of audience find out different type of users. Start thinking for UCD process implementation.
UCD Process: –In brief start with Persona, User Scenarios and IA- Information Architecture. For details you can read on our blog here.
Primary Devices: –All major native and responsive frameworks support all mobile devices but first point out your primary device and check out all major native/responsive action, gesture to complete task.
Affordance: –This a very important part of design process, check your design element’s affordance.
An affordance is often taken as a relation between an object or an environment and an organism, that affords the opportunity for that organism to perform an action. For example, a knob affords twisting, and perhaps pushing, while a cord affords pulling. As a relation, an affordance exhibits the possibility of some action, and is not a property of either an organism or its environment alone.
Touch Gestures: –Make sure you guys have test gesture scenarios with one hand single finger (thumb and other finger) tapping and two hand (two thumbs). Google propose below gesture table:
|One-finger press, lift
|One-finger press, lift, one-finger press, lift
|One-finger press, wait, lift
|Select an element, such as a list itemLong press is not used to display a contextual menu
|One-finger press, wait, move, lift
|Pick up and move, select multiple items
|One-finger press, lift, one-finger press, move, lift
|Zoom in, zoom out
|Two-finger press, move outwards, lift
|Two-finger press, move inwards, lift
|Two-finger press, lift
|Two-finger swipe, drag, fling
|Two-finger press, move, lift
|Select multiple items, pan, tilt
|Two-finger press, wait, lift
|None; this gesture is uncommon
|Two-finger long-press drag
|Two-finger press, wait, move, lift
|Pick up and move
|Two-finger double touch
|Two-finger press, lift, two-finger press, lift
|Two-finger press, simultaneously orbit both fingers around the center point, lift
|Rotate content, such as a map
Haptic/s Feedback: –Haptic/s feedback is the most important part of UX design on touché devices.
As per Mobileburn – Haptic feedback, often referred to as simply “haptics”, is the use of the sense of touch in a user interface design to provide information to an end user. When referring to mobile phones and similar devices, this generally means the use of vibrations from the device’s vibration alarm to denote that a touchscreen button has been pressed. In this particular example, the phone would vibrate slightly in response to the user’s activation of an on-screen control, making up for the lack of a normal tactile response that the user would experience when pressing a physical button. The resistive force that some “force feedback” joysticks and video game steering wheels provide is another form of haptic feedback.
Heuristic Evaluation: –Evaluate your design as per Huristics by Jakob Nielsen (wiki)
|Visibility of system status
|The system should always keep users informed about what is going on, through appropriate feedback within reasonable time
|Match between system and the real world
|The system should speak the user’s language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order
|User control and freedom
|Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo
|Consistency and standards
|Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions
|Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action
|Recognition rather than recall
|Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate
|Flexibility and efficiency of use
|Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions
|Aesthetic and minimalist design
|Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility
|Help users recognize, diagnose, and recover from errors
|Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution
|Help and documentation
|Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large
Design & Development Phase: –After covering all above points start your design & development phase.
Usability Testing: –Test your application task flow with always real end user to get accurate result/feedback. You can do this UT activity as per your project convenience time in starting, middle or later phase.
Keep checking for latest updates, signing off – Sanket