Whether to progress one step ahead of the implementation by preparing and designing « just in time » contents of next iterations or to collaborate actively with developers on the functions that must be delivered during the sprint, one of the main activity of the AGILE UX PRACTIONNER consists in sharing with the team his knowledge of the design principles and User Interface patterns…
It consists in enabling easy reading and fostering a good understanding of what is displayed on the screen. This principle covers two dimensions: the physiological process of reading but also the understanding of what is read.
Make it legible: information is noticeable and distinguishable
Make it readable: information is identifiable, interpretable and attractive: it can be understood!
Legible, readable and attractive !
This UI principle refers to the lexical characteristics of the information displayed on the screen that can impede or facilitate the reading of this information (character brightness, contrast between the letter and the background, font size, interword spacing, text blocks, line spacing, paragraph spacing, line length…).
Small font size and low contrast between text and background are hard to read and often constitute the main users’ complaints. Accessibility issues and who will need to read the content need also to be taken into account.
Two bad examples…
Very bad contrast!
So hard to read !
But also very good practices…
Example
And the winner is...
Example
Legible and readable content. Good contrast. Good blocks.
Example
In both cases legible but sweeter and less visual "fatigue" with the grey version (for an interface used every day)
And finally some guidelines…
Use simple, common, and familiar fonts (sans serif font such as Verdana, Arial or Helvetica), designed for reading on screen
Use Mixed-Case for Prose Text
Avoid texts in all caps
Don’t overuse bold: use it only when you want to call attention or create a hierarchy
Use italics when you want to call attention
Use an underline only to indicate a navigation link
For line spacing use one to one and one-half times font size
For Web pages use 12 to 14 points for body text and 18 to 36 points for titles and headings
Present black text on plain, high-contrast backgrounds.
Ensurethereadabilityofthe textby adjustingthe contrastwiththe background(contrast value ofat least80%)
Ona light background(white / gray), avoidyellow,pale greenorcyan, blue, red, purple
Use line lengths of about 75-100 characters if fast reading is required
Left-justify text
Use lists to present facts.
Make text scannable by using Bulleted listings, Tables, Headings and subheadings, Highlighted and emphasized important issues, short paragraphs
Whether to progress one step ahead of the implementation by preparing and designing “just in time” contents of next iterations or to collaborate actively with developers on the functions that must be delivered during the sprint, one of the main activity of the AGILE UX PRACTIONNER consists in sharing with the team his knowledge of the design principles and User Interface patterns…
Visibility and Invitation ?
This first principle refers to the means (prompts and cues) available to lead users through an interaction, guide them through the accomplishment of specific tasks, indicate the possible actions that can be taken or just inform them about their context.
Presenting an appealing first impression and providing « just enough » invitations to the user are two of the keys to successful interactive interfaces. It ensures ease of use, ease of learning and global satisfaction. Nowdays, in the era of digital marketing, invitations are often reinforced and extended to persuasive design: the art to motivate users to view some specific content or take some action (through visual and verbal webdesign and patway optimization).
Call to actions, invitation and persuasive design
Clear pathways to information, call to action elements, short instructions, simple and appropriate information architecture, breadcrumb trails, progress indicator, various information visualization mechanisms, are all promoters of good visibility and performing invitation.
Two bad examples:
Where do I start ? How does it work?
Not so obvious 🙂
But also good practices:
Example:
Appropriate and useful step navigation
Example:
A very good invitation
Example:
Good invitation
Example:
Default and limited choices
Example:
Straight to the point !
Example:
Follow the guide !
And finally some guidelines…
Limit entry points on the interface
Make the entry points descriptive and « task-oriented »
Provide an ordering of screen information and elements that is rhythmic, guiding a person’s eye through the display, encourages natural movement sequences, and minimizes pointer and eye movement distances
Highlight important page items that require user attention
Use location and highlighting to prioritize pushbutton
Establish levels of importance
Use color to draw attention
Propose a short, unique, descriptive and meaningful title on each page
Provide on each page navigational elements allowing users to answer three questions: Where am I? What’s here? Where can I go from here?
Don’t overload users with too many alternatives or don’t confuse them with unneeded information
Ensure the main navigation system provides a visual indication to the user what menu item or it is
Clearly and prominently communicate the purpose and value of the Web site on the homepage
Put the most important items at the top center of the Web page to facilitate users’ finding the information
Do not create or direct users into pages that have no navigational options
One more time… and in small groups please: more fun, more feedback and more information collected even if you need more preparation effort (related to realistic content, screenshots and elements cutting, materials provided).
Design Workshop :Paper prototyping in small groups
At a time when others are still searching and waiting for the magic prototyping tool to make wireframe, Paper prototyping deliberately focuses on proximity, human interactions, feedback, collaboration, and simplicity… some core agile values.
According to me, even more in Agile contexts, the real strength of Wireframe format is on its ability:
To be done in a collaborative mode,
To generate feedback,
To share the Vision of the User interface
To support business and development activities
To stay at a « just enough » level (documentation, process, effort…)
And this is exactly what paper prototyping offers…
Moreover, Paper prototyping technique is FAST, EASY and FLEXIBLE (in terms of protocols…).
This is what I have observed in some group sessions:
It is highly collaborative with a rich feedback generation (especially for group sessions)
It enables multi disciplinary teams, various actors to get a common vision,
It reduces communication issues: we do it in groups, face to face, in the same room…
It fosters creativity by giving the impression that nothing is fixed and that we can change things easily
It’s interactive and fun with direct manipulation and collective activities (far from the passivity of some traditional meetings)
It is adaptive and scalable with various facilitation techniques adjusted to different contexts
To conclude, take a look at this huge session of paper prototyping:
One of the first differences observed with Agile is the way we estimate the size and duration of an IT project.
The entire team is made responsible for the estimate of the product Backlog (the list of all functionality desired in the product). Indeed, the team is invited to estimate collectively this list of valuable items that will require his work.
Scrum teams use Story Points and Planning Poker for this activity.
Story Points represent a measurement of the effort required by a team to implement a Story.
Planning Poker is an effective (and funny) way to assign collectively story points to user stories on the product backlog. It isa special card game based on the Fibonacci sequence. The idea is to pick a representative story and assign it a point value, then estimate the other stories relative to this standard (consensus must be reached for each user story)
Planning Poker Deck
Collective intelligence is the pillar of this new way to estimate … an effective team-based estimation technique but not so natural at first. Relative size and consensus are not so easy for the teams new to agile.
The problem:
Teams often lose the thread of their estimates. They have difficulty in comparing or lack of benchmarks.
An answer:
Use a visual display of the planning poker values in columns, and place the user stories in the appropriate column during the activity.
Visual display of the estimates
Benefits:
It is an effective form of visual management
It facilitates comparison and triangulation
It reinforces the concept of relative size (effort)
It reinforces the idea that result is not frozen during the activity: change is easy t!
User stories are increasingly used on Agile projects. This popularity is a very good thing. Goal and business oriented, their simplicity and a immediate focus on acceptance criteria make them terribly effective on design projects.
Once the 3C described (Card, Conversation and Confirmation) and INVEST criteria well understood, when the team and Product Ownerstart to discover their own stories, they often ask me if the « User Voice » format must be respected …
This format is the following:
As a <User Role> I can <Goal> SoThat <Business Value>
A sentence in which,
The role is the one that makes the action and who benefits
The goal is the action executed
The Business value represents the benefits that emerge from the action
So, should we use this format ? My answer is definitely YES!
The « User Voice » gives meaning to the feature … why and for whom the team will develop the product
It is a step closer to a user experience approach, especially to the Personas method.The role is often a Persona, representing a concrete realistic and shared vision of the end user.
It is clearly ACTION and GOAL oriented (so efficient to design products)
It justifies all the functionality of a business point of view, and requires the Product Ownerand teams to systematically examine the value of each feature
My advice: Give a concise and significant title to the User Story and then describe the user story using the « User Voice » format.
