Timeless Usability Principles that every professional UX/UI designer should know

These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

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

Error prevention

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.

MetaScrum - Maintaining Product Priority Order in the Company

The MetaScrum is the meeting where all decisions product are made and/or heard by representative decision makers from all areas of the company.  Typically this is a weekly meeting run by the Master Product Owner and supported by the CEO.  The agenda includes a charter of meeting rules, objective, current sprint status update and upcoming sprint plan. Depending on the company culture, more items may be included that impact the product release cycles.  One of the most important rules to enforce is that all priority order changes must be made in the meeting and supported until the next meeting. These meetings can be critical to helping the product management and development teams focus on getting things.

I will be posting links to sample formats and documentation.

Implementing new user experience design

When it comes to agile requirements, user experience and creative design implementation often becomes a challenge especially for large organizations.  I have many different approaches to recommend but I will share one way that was wild successful for me.

Assume the user experience flow will require refinement after the screens have been developed and after real end users have used the system in their physical environment.  The key is to partner closely with your customers at any given time in your planning, development and release lifecycles.  

Below is a phased approached. Make sure you have thoughtfully identified minimum task completion, don't try to solve the experience for everything in your roadmap. If you listen to your market, they will adopt new feature flows and experience changes if you always do the right thing.

Phase1 (Mockup, Design, style guide and slices)

-------------------------

- Basic look and feel design and core user conventions. Conduct story mapping and identify only what tasks are necessary.

- Usability testing and feedback sessions with clients, user groups and CMIO panel

- Upload designs to central repository for review by all SMEs and front end architect. Time box feedback and move on.

- Work with product analysts or BAs to finalize user stories

- Requirements ready for development

Phase 2 ( In Development)

-------------------------

- Implement Design using artifacts provided by Creative

- Creative available for questions

Phase 3 (Beta Feedback and Refinements)

-------------------------

- Review implementation by development, make recommendations and refinements

- Beta Test Case feedback from client and product owner

Helpful Tips - Scrum Feature Teams

Scrum feature teams make up vertical slices of areas of expertise to form cross-functional teams.  Feature teams can help a company scale by allowing team to take ownership of active projects in-flight that must be released in parallel.
Please note, unless your architecture is stable and modules are completely stand alone, be mindful of how many major features are being releasing in a given sprint. I recommend the team limit the number of active projects and never start a new project until the current one is 'shelf ready'


Helpful Tips for Choosing Feature Team Members
* There must be a Lead Product Owner or Master Product Owner that oversees all the inputs and outputs
Per each feature team:
1. One Product Owner.  Each feature team should consist of only one product owner. I will start another discussion on this topic when the same resources are responsible for projects belonging to different product owners.
2. One ScrumMaster.  An experience ScrumMaster is recommended to teach both the product owner and the team to work through sprint goals.
3. The Team. Try to keep the team size limited to three to four developers and no less than one IT QA staff per feature team.

Helpful Tips for Training your Feature Teams

For members new to Scrum
1. Make it very clear to all team members that no one is the boss, it is a horizontal org chart with everyone answering to the client.  Everyone is a subject matter expert of their team function. Each person is held accountable for their role and responsibility during the sprint.
2. If teachers are limited, train development first. Developers appreciate Scrum if you point out that requirements and priorities do not change after the sprint is locked and committed to by the feature team. Check out Jeff's article on shock therapy - http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
3. Train Product Owners on how to write a user story and break it down into manageable parts. Provide high level training on the Scrum Framework, don't reinvent the wheel, use material provided by your Scrum Certified Professional or what is available on the Scrum Alliance.
4. VERY IMPORTANT - When the team completes estimations and goals can be selected, make sure there is a face to face meeting in which the sprint goals are clearly defined and committed to.  The ScrumMaster only locks the sprint goals when the expression on every team members face shows comprehension.
5. Define a Sprint Activity Calendar and Checklist per each role. This is most helpful when there are old waterfall mindsets on the team.
6. Let the feature team members attempt to follow the checklist according to their role, make the ScrumMaster responsible for ensuring all members complete a full set of checklists by the end of the sprint.
7. The Scrum Coach or Scrum of Scrum Masters must conduct one on ones with each team member on a daily or weekly basis.
8. RETROSPECTIVE IS KEY.  Inspect and adapt.  Train on what is most important, not on everything under the sun, or shall I say 'under the Scrum'.

KISS - Keep It Simple Silly

Every meeting room used for sprint planning by product management and development should have a laminated poster that says 'Keep It Simple Silly'. This advise is timeless when it becomes obvious that the teams are over complicating the software design.