U Xmagic Agile Presentation

Sketching and prototyping are proven techniques that enable you to explore ideas and concepts quickly without excessive investment in either time or resources. SketchFlow allows you to quickly and efficiently demonstrate your vision for an application. It provides an informal and quick way to explore, iterate and prototype user interface scenarios, allowing you to evolve your concepts from a series of rough ideas into a living and breathing prototype that can be made as real as a particular client or project demands. This rapid, iterative and cost effective approach to prototyping allows you to concentrate on what matters most, being creative and building the best solution for your client, on time and within budget.

Effective Prototyping - quickly and efficiently experiment with the flow of an application UI, the layout of the individual screens and how the application will transition from one state of the application to another.

Interactive Review - the SketchFlow player engages clients with working prototypes, collects annotations and feedback which get displayed directly on the design surface within Expression Blend.

Quickly create detailed project Microsoft Word documentation for your prototypes.

User Centered Design Basics Agility through the Agile Development Process The Agile development lifecycle The Agile collaboration and communications styles To become your team’s user centered design resource Communicate user centered thinking throughout the design and development team How to adapt your current approaches to increase transparency and information flow to well outside of the project. Improve and adapt your current approach to leverage daily involvement of other development team resources outside of your user experience team A “common language” and terminology that will help you to explain user centered design thinking back to your agile team

Agile Development Creates Business Value Business Goals Via Goals Questions Metrics How to set up a collaborative work sessions to model Information Our Business Problem Modeling Business Goals Communicating and Socializing Information in an agile environment

Separate Phases Hand-offs at each phase Requirements Problems with this methodology Errors are passed to the next phase Design Time overruns at the final phases Development and test often delivers poor Development quality results Quality issues on top of upstream problems Testing with requirements and design often result & Validation Common waterfall practitioners attempts usually lack Royce’s original feedback loop * Winston Royce, Managing the Deployment process. Development of Large Software & Maintenance System, 1970

Core Values: Individuals and Interactions Over Processes and Tools Working Software Over Comprehensive Documentation Customer Collaboration Over Contract Negotiation Responding To Change Over Following a Plan Principles: Iterative development and delivery People – both individuals and teams Collaboration Technical excellence

Agile describes an approach to a method, not the method itself You’ll know “agile” when you see it.. Use the four principles to evaluate a methodology’s basis in “Agility”

Feature or User Story Develop • Expressed from business or user perspective Test • Business value Feature • Estimation Capable Feature List: priority features Design Evaluate Iteration Iteration Plan • 1-4 week period Iteration Plan Evaluate Release Plan Evaluate Incremental Incremental Release Plan Release • 1-6 Iterations • Released internally or Product/Project Charter Product/Project externally to end users Plan Product or Project • Perpetually released

User Stories or product features are generally prioritized by their own business value. Incremental deliveries generate business value. (i.e. XP, Vista, 7, etc.) To understand a proposed software requirement you need to ask: “How does the business get value from this?“ Often what the business is trying to achieve is not well understood You need to create a model to communicate business goals and metrics to track their progress Identify and prioritize users Prioritize stakeholder concerns Prioritize suggested features How can we validate further decisions about a product like this? Through a Business Goal Model..

Identify and prioritize GOALS How will the organization improve after the delivery of this software? What will happen if we don’t deliver this software?  How might this software: increase Revenue, avoid cost, or increase service  QUESTION each: If we were making progress toward this goal, how would we know? What would change in the business as a result of reaching this goal?  Identify METRICS for goals  Metrics help quantify Return On Investment  Metrics justify ongoing development expenditures.  Requirements that track metrics often identify important product features

Team Collaborative Modeling will: Build shared knowledge Build communication and collaboration skills Help the team come together as a workgroup How to prep for the activity: Write a brief statement to set goals and scope Select participants in teams of four to six Information Suppliers Information Acquirers Information Modelers Facilitator Documenter Perform Launch kickoff with goals and scope Brainstorm information to identify information on the table Start modeling the information to clarify, add details, distill details, and identify the relationships Close by summarizing the results, on camera if possible Document & Communicate Capture model with photo and/or movie Document as necessary Post in publicly accessible place Display as a poster

Begin: Everyone read the business problem Where will the organization earn money from building this software? Take a few minutes to discuss the How will they measure return? problem as a team Identify Users & Goals Who will use this software for Did you learn anything from the what goal? discussion you hadn’t though about when reading the problem? Don’t forget how the business people who’ve paid for the software may use it and why?

Start by writing down on index cards your Consolidate & Prioritize Goals business goals Question Top 3 Goals to realize metrics Have one team member act transcriber for the If we are making progress toward this goal, goals. Everyone else will vocalize goals for transcriber to capture how would we know? Questions: What would change in the business as a result of reaching this goal? How will the organization improve after the delivery of this software? Build a Poster to Communicate Your Business Goals Show the relationship of What will happen if we don’t deliver this metrics to goals software? How might this software: Increase Revenue, Avoid Cost, or Increase Service?

In Cockburn’s Agile Software Development, communication is described in varied temperatures. This is a tenet of Agile development.

Agile environments use information radiators to socialize information In Cockburn’s Agile Software Development, he describes Convection Currents of Information. • Proximity • Osmosis • Drafts • Radiators

Show Workflow Support release planning and incremental development Use navigation maps (storyboards) to describe user interactions - This is very easily done inside of Sketchflow.. Development proceeds by leveraging whiteboard wireframe prototypes Allow for user models and UI guidelines communicated in posters - This can now all be created within Sketchflow You should use large displayed models to become a backdrop for ad- hoc collaboration. Model with Sketchflow and pass around a sketchflow player for collaboration. Record discussions while building a model to use for documentation

• Differentiate incremental release from iterative development • Use iterative development to experiment and validate before end users use the application • Align your user centered design practice with business goals • Know your business goals • bind user models , task models, and feature choices to business goals • Model in collaborative work sessions • Build models and work-products in collaborative cross-functional teams • Enhance communication • Always try to deliver information face-to-face supported by a paper or whiteboard models. • Support documents with conversation to discuss them. • Consider video documentation • Radiate information • leverage visual communication skills to model concisely and socialize information

A Simple User Centered Design Model Applying the UCD Model Dependencies to the Agile Development Lifecycle User Modeling Incremental Release, Increasing Profit and Reducing Risk Modeling Use Using Tasks Release Planning Based on User Tasks

Surface Skeleton Structure Scope Strategy

Surface task panes Skeleton Structure modal dialogs Scope modal wizards Strategy

user tasks: Surface • enter numbers • enter text • enter formulas Skeleton • format cells • sort • filter Structure • aggregate • graph data Scope • save data • import data • export data Strategy • print

business goals: Surface • displace competitive products • motivate sale of other integrated products • establish file format as default Skeleton information sharing format user constituencies: Structure • Financial planner • business manager Scope usage contexts: • office • laptop Strategy • phone

These layers of concerns apply not only to software but a variety of products In particular, products that support a wide variety of user tasks benefit from this kind of thinking

Test First Development is the practice developers use where they automate unit tests before writing code that allows those tests to pass Writing tests first forces developers to think about how the code will be used and what it must do prior to writing it Agile developers often say: “How do I know I’ve written the correct code if I don’t have a running test to prove it?” Models built by user experience teams perform the same role as developer tests Business goals help validate choice of which user constituencies to support User models help validate the work practice we choose to support Work practice models help validate the features we choose to design and implement How could we know we’ve chosen the correct features without business goals, user models, and work practice models?

Products & Projects abstract design & Model Strategy & Scope evaluate plan Incremental Release design & Segment Scope, Model Structure evaluate plan Iterative Feature Development design & Refine Structure, evaluate plan Design Skeleton & Surface detail features

Business Stakeholder Interviews Business Goal Modeling Financial Modeling User Interviews User Observation User Modeling Competitive Analysis Other Research? Task Analysis Task Modeling Activity Modeling Task-Centric Feature/Story Backlog Task-Centric Release Planning Product Envisioning using High Level Scenarios & Storyboards

A User Role is the goal-relationship a user has with a system Remember that a specific user may change roles as goals change Steps: Create a series of user cards that are representative of what you know about your users and potential users. Arrange the roles into models by affinity Roles with similar goals that might use the system in similar context should be close together Circle and label each Draw lines from role to role, or cluster to cluster, label as: relationships, transitions, specializations Note the model with other information relevant to those making specific feature and priority choices

 Understanding both user and business goals helps move your team forward with how you can release a product that would satisfy both.  Financial advantages for releasing sooner and more frequently can be realized.  This however often requires that user goals are met..

Software begins to earn its return after delivery and while in use The sooner the software begins earning money:  the sooner it can recoup its development costs, the higher the overall rate of return. Increasing release frequency adds costs that must be taken into account  additional testing costs  promotion costs  delivery costs  potential disruption to customers The impact on Return On Investment for early release can be dramatic The impact on cash flow even more dramatic

 Prove general architectural approach  Validate domain model  Perform user acceptance testing  Showing users complete workflow lets them effectively evaluate and give feedback  Test for performance  Test for load  Deploy in target environment

Software Is A Tool People Use To Help Meet Goals, Tasks are the Actions They Perform I have Goals Goals Tasks and Tools Understand your goals, then your tasks before identifying tools I’ll reach this goal by Validate tools by performing tasks and performing some Tasks confirming goals are met Defer detailed tool design decisions by identifying and planning for task support I’ll seek out Tools that help be better perform my task

Tasks have an objective that can be completed Tasks decompose into smaller tasks Activities are used to describe a continuous goal, one that might use many tasks, but may or may not be completed “Read an email message” is a task, “manage email” is an activity task activity task task task task

High Level Summary very high level ongoing goals that may not see Total completion but are used to drive summary level goals Summary Level long term goals used at various functional levels Functional Level tasks you can complete in a single work session Sub-function Level smaller tasks that by themselves don’t accomplish a goal but together with other sub-functional tasks reach a functional goal. Low sub-function level smaller finite level details that make up a sub- Function goal.

Originally eXtreme Programming described a user story as a small amount of text written on an index card to function as a reminder for a conversation between developer and customer From Wikipedia: “A user story is a software system requirement formulated as one or two sentences in the everyday language of the user.” The user story form credited to Rachel Davies in Cohn’s User Stories Applied combines user, task, and goal: As a [type of user] I want to [perform some task] so that I can [achieve some goal]

Identify And Plan Using User Tasks Now, Defer Specific Feature Choices Till Later Understand Business and User Goals Goals Understand user’s tasks and the business process that supports goals Select tasks to support with software Defer decisions for and designs of specific features till later Tasks "latest responsible moment" comes from Lean Software Development: “Put off decisions as long as you can: to the latest responsible moment… “ Features Tools An Agile-style user story may refer to a feature, or user, task, and goal. Most likely the goal however. Software Product Agile User Story

Build a workflow model Draw a left to right axis representing time, a top to bottom axis labeled necessity Identify high level activities performed by users of the system and place them above the time axis in the order that seems reasonable Within each activity, organize tasks in the order they’re most likely completed Move tasks up and down based on how likely they are to be performed in a typical instance of use Activity 1 time necessity Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7

Spread out your research Perform enough research early to make provisional decisions. Leverage assumptions. Replace risky assumptions with research Understand models as tests validate for subsequent decisions models built based on research and assumptions act as tests just as developer’s unit tests act as tests Align user goals with business goals this user’s goals are important to us because…? Spotlight user goals and tasks leverage good user story format Defer feature design to the latest responsible moment

Feature Design and Scaling Release Planning Agile Iterative Development Your first iteration plan build validate reflect

Products & Projects abstract design & Model Strategy & Scope plan you are here evaluate Incremental Release design & Segment Scope, Model Structure evaluate plan Iterative Feature Development design & Refine Structure, evaluate plan Design Skeleton & Surface detail features

Continue User Research As Needed Incremental Release Planning Defining Interaction Contexts & Navigation User Scenario Writing UI Storyboarding with Sketchflow Maps Low Fidelity UI Prototyping with Sketchflow Lightweight Usability Testing

Given a specific task a variety of feature design solutions may exist to support the task. These features can vary widely in scale. Managing scale appropriately is an important part of managing scope. With the initial planning the set of deliverable features, the scale of each feature must be planned. Scale management happens during design and development planning and should be done close to the time the functionality is needed In the context of other features, time constraints, development capacity, and other projects the team may have in progress.

Necessity: what minimal characteristics are necessary for this feature? Flexibility: what would make this feature more useful in more situations? Safety: what would make this feature safer for me to use? Comfort, Luxury, and Performance: what would make this feature more desirable to use? Each product feature may have some portion of each of these categories

If software doesn’t support necessary tasks, it can’t be used.. A feature or set of features that minimally support each required task meets necessity guidelines..

Adding flexibility to a system adds alternative ways of performing tasks or support for less frequently performed tasks Sophisticated users can leverage, and often demand more flexibility Complex business processes often demand more flexibility

Adding safety to a system protects the users from making mistakes with features such as data validation, or process visibility Safety characteristics of a feature may protect the interest of the business paying for the software by implementing business rules Sophisticated users can work without safety features, while novices often need them Complex business rules often demand more features

Adding comfort, performance, and luxury features allows your users to complete their work more easily, quickly, and enjoy it more.. Often the return on software investment can be increased by adding these types of features Comfort features benefit frequent, long term use of the software Sophisticated users can benefit from performance features Those making buying decisions often look at luxury features

When planning a software release, start with tasks that users will perform Add in tasks that provide flexibility as needed Add in tasks that provide safety as needed Add in tasks that provide comfort, luxury, and performance as it benefits return on software investment Each task you choose to support in a release will have some amount of these qualities: Time Estimation: factor in the amount of flexibility, safety, comfort, performance, and luxury you believe the feature solution of a task might need. Adjust your design and development estimates as necessary.

The Task Model identifies the major activities and tasks that span the business functionality A successful release must support all necessary activities in the process smallest list of tasks to support users = Activity 1 smallest span time Task 1 Task 2 Task 3 Task 4 Task 5 necessity Task 6 Task 7

time necessary less optional optionality more optional Choose obvious groups of features that take into account the span of business functionality and user activities. Support all necessary activities with the first release Improve activity support with each release

The topmost row of the span could be the first, smallest release By minimizing a release we can realize financial and risk reduction benefits earlier The top span represents the minimal tasks users need to accomplish to reach their goals. How can we split these “high level stories” into smallest parts? Can the feature to support a task have reduced safety? Can the feature to reduce a task have less comfort, performance, and luxury? Are there optional tasks that can be supported in a subsequent release? For necessary tasks, look at the steps – or subtasks that make up the task. Can any of those steps be made optional? Move cards around the model, or split cards into multiple cards to defer task support, or specific feature characteristics till later releases

activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional Consider tasks more optional Split tasks into optional parts

Develop your product using componentized paper prototypes Your first released prototype will be built in 20 minutes of development A successful release will span the entire business process supporting all tasks you feel are necessities, then filling in with features to support tasks that are optional Estimate your release based on how much you believe you can complete in 20 minutes of prototyping

activity 1 activity 2 activity 3 activity 4 time necessary less optional optionality more optional  Thin support for tasks using the following guidelines:  Necessity: is supporting this task necessary in this release?  Flexibility: does supporting this task add flexible alternative ways of doing things?  Safety: does supporting this feature add safety for the user or business paying for the software?  Comfort, Performance, and Luxury: does supporting these tasks make the software easier to use, faster to use, more enjoyable to use?

Continue User Research As Needed Defining Interaction Contexts & Navigation User Scenario Writing UI Storyboarding Low Fidelity UI Prototyping with Sketchflow Lightweight Usability Testing (Morae) Detailed Visual Design UI Guideline Creation & Ongoing Maintenance Heuristic Evaluation Collaborative User Interface Inspection

Iteration Design & Planning Sufficient feature design and analysis completed to allow development time estimation design & Iteration kickoff meeting: 1 hour to ½ day plan High level goals for the iteration: “at the end of this iteration the software will…” User story or feature introduction & estimation Feature Design & Development Features may or may not have most of their functional and user interface design completed before iteration planning – the remainder is completed inside the iteration Constant collaboration occurs between development and those in an Agile Customer role build Near the end of the iteration time box is a good time for testing how well features work together – collaborative UI inspection is common at this time End of Iteration Evaluation Demonstrate and evaluate the product as it is today to stakeholders – this is a good time for usability testing – adjust planned product scope in response Evaluate progress on features against a release plan – adjust plan as necessary evaluate Reflect on the process used over the past iteration – should the process change to improve quality of product and/or pace?

Develop Test Feature Design Evaluate Release Plan Evaluate Incremental Plan Release Product/Project Charter Product/Project Plan

Tools Card Stock (use for screen backgrounds and cut up for components) Index Cards (lined cards make great lists) Scissors Clear tape Multi-stick tape Pencils felt tip pens Transparency film OR Microsoft Expression Blend with Sketchflow Team approach Someone direct traffic Various people build components Someone assemble the user interface from the components Someone continuously review what’s being assembled against your use case – will it work?

Team approach Someone direct traffic Various people build components Someone assemble the user interface from the components Someone continuously review what’s being assembled against your use case – will it work? Use a span plan to complete feature support for all the tasks in your first release

Identify test subjects Should match the characteristics and skills of your target users Actual end users or stand-ins Identify tasks to test Assemble your test team facilitator computer observers Coach the test team on the testing personalities: Flight Attendant Radio Announcer Researcher Decide on test approach – single or “paired” subjects Setup your testing facility

Facilitator introduces the team. Facilitator introduces tasks to perform and goals, then invites test participants to “think aloud” and begin. Facilitator plays sports-caster; keeps subject talking, narrating when necessary. Observers record data – use post-it notes to make downstream analysis move faster. When the test is complete observers may ask test participants questions. Thank participants. Consolidate data.  How many issues did you detect? Consider issues as items you’d change.

Recorder captures audio, video, on-screen activity, and keyboard/mouse input during a research session. Observer enables team members to watch the customer’s experience, make notes, and flag tasks in real time. Use Manager to view and analyze Morae recordings, automatically calculate metrics, generate graphs, and create highlight videos to share with stakeholders.

In Agile Development reflection sessions, or retrospectives, are commonly held at the end of development cycles – iteration or release Before engaging in a reflection session:  evaluate the product you’ve built thus far against its goals  evaluate your team’s progress building the product relative to plans made The goal of the reflection session is to identify opportunities to alter the process the team follows to ultimately improve the quality of the product and/or the pace of progress the team is making A common reflection session tenant is to identify what worked, keep try and what didn’t work  Reflection sessions may turn into complaint sessions where the only goal may be to assign blame problems In a simple reflection session identify methodology characteristics: to keep doing, to try doing, and are ongoing problems

Measure your progress how many tasks did you end up supporting in your keep try product? Was that more or less than you expected to support? Discuss your product How well did you fare on usability testing? recurring Draw the simple 3 sectioned chart pictured problems Place in each section characteristics of your approach that:  You liked and want to keep with the next release  Things to try doing differently next time ongoing problems that you don’t see clear solutions to.

Plan useful releases consider the resulting work practice of the release’s target users for each release Scale features when planning product releases can the scale of features be reasonably reduced in order to release sooner and still effectively support target user work practice Validate usability before development use paper prototyping and light weight usability testing to validate features before development Validate usability after development as iterations of features finish development, perform usability testing on the finished features – they’ll change during development

design & Release Planning plan Release Building build Release Testing Release Reflection evaluate

Design Team design & Development team Interaction Designers plan Small number of seasoned Prototypers developers Business Analysts UI development skills Responsibilities Responsibilities Gather customer input for features Implement features for current build to be implemented in later iteration iterations Design next iteration features Be available to answer questions on current iteration development evaluate Test features implemented in the previous iteration

Iteration 0 Iteration 1 Iteration 2 Iteration 3 • planning • gather user input • gather user input for • gather user input for • data gathering for iteration 3 iteration 4 features iteration 5 features • design for iteration features • design iteration 3 • design iteration 4 features Customer 1 features – high • design iteration 2 features technical • support iteration 2 • support iteration 3 features Team requirements, low development development • support iteration 1 • validate iteration 1 • validate iteration 2 user requirements development features features Development • development implement iteration environment setup implement iteration implement iteration 3 features and fix • architectural 1 features 2 features and fix any iteration 2 “spikes” iteration 1 bugs if bugs if they exist Team they exist time

wins for interaction designers No designs were created and go unused Timely feedback, so if there was a sudden change in the market the teams receive input on it right away and could act accordingly wins for the developers maximize coding time No wasted efforts. The design team can create and validate multiple solutions passing the best to development for final implementation. Some designs may need to be longer than a single cycle to complete.

Pipelining Design team moves ahead designing for future iterations, but fails to evaluate and incorporate feedback from historic iterations “Discussion that felt like collaboration when they were working on the same feature set now feels like interruption…To protect themselves, so they don't get bothered while they work out their new decisions, the business experts write documents to give to the programmers and testers. Similarly, the programmers create documents to hand to the testers.” --Alistair Cockburn, Agile Software Development 2nd Edition Avoiding pipelining Past: “..most designs had to be tweaked slightly because of technical implementation problems, and the usability tests did not show us how the features would interact with one another.” Present: “..the interaction designers would work daily with the developers once implementation started to answer questions and solve problems that arose from issues with implementation” Future: “Designs were not just "thrown over the wall" to the developers. Through the daily scrums and interface presentations, the developers had followed the design's progression throughout the last cycle.” -- Lynn Miller, Alias, Case Study of Customer Input For a Successful Product

User Centered Design, Interaction Design, Usability, and Business Analysis and Requirements Gathering are siloed activities Duplication of data gathering and modeling efforts User interviews Business stakeholder interviews Business process modeling Task analysis UI prototyping Business stakeholders that find the duplication often choose to omit one group or the other Usability as an overlooked non-functional requirement

Use reflective process improvement to alter your process after reviewing your product quality and progress relative to your plan Increase the frequency and timing of end user involvement build a ready base of users and surrogates inside and outside of your organization to leverage continuously Avoid pipelining by working in the past, present, and future: keep collaboration, feedback, and product adaptation high between all team members Build a holistic process that includes business analysis, interaction design and usability, development, and testing as one team rather than silo-ed disciplines

User Centered Design A class of methodologies where design decisions are based on a tangible user model. The user model is based on the research of the users of the application. Interaction Design The specific choices of user interactions made to allow users to meet their goals in the software. Interaction Designers are generally User Centered Designers. Visual Design refers to the design of the visual appearance of software, advertising, or other commercial products. Visual Design focuses a bit more on esthetics. Visual Designers are often NOT User Centered Designers.

Usability the ability of a specific type of user to be able to effectively carry out a task using a product. Usability is usually measured through testing. Given a number of test subjects that reflect the type of user that will use the application: how many successfully complete a task. on average how quickly do they complete that task. on average how many user errors are made while attempting to complete that task. Usability Engineering The practice of usability. Usability Engineers often have much in common with testers. While they may design the user interface, often their emphasis is on evaluating the user interface and making recommendations for improvement. Usability may in many instances not be designers.

Information Architecture The structuring of information so that it best supports the consumption by its target users. An IA professional is often considered a counterpart to an Interaction Designer where Interaction Designers focus on how people use computers to accomplish work, and Information Architects focus on how people leverage information to support goals. HCI or CHI Human-Computer, or Computer-Human interaction refers to the study of how humans and computers interact. An HCI professional may be a researcher, a designer, a psychologist, or anyone who might focus on human-computer interaction as part of their work or study.

User Experience The overall experience a user has with a product. This experience doesn’t stop at the use of the product but starts with the advertising and presenting of the brand through the purchase to the use and the day-to-day feeling the user carries with them about the product. User Experience Professional may refer to any of the roles already discussed. Someone whose day-to-day practice focuses on improving some or all aspects of user experience. We are all directly or indirectly User Experience Practitioners… how professional we are at it may be up for discussion.

While Visual Design certainly can affect usability, it’s quite possible for a product to have pleasing visual design, but intolerable usability.

Visibility of system status (keep the user informed) Be forthcoming - don’t hide information Match between system and real world (user language and real world conventions) Watch your language User control and freedom (easy exits, undo and redo) padded corners, hand rails, and safety nets Consistency and standards same thing the same way Error prevention Recognition rather than recall (reduce remembering with visible options, actions, and instructions) Flexibility and efficiency of use (customization and support for advanced users) Aesthetic and minimalist design (reduce irrelevant or rarely needed information) Help in recognizing, diagnosing, and recovering from errors Good help and documentation Source: Jakob Nielsen’s Usability Engineering

Recorder captures audio, video, on-screen activity, and keyboard/mouse input during a research session. Observer enables team members to watch the customer’s experience, make notes, and flag tasks in real time. Use Manager to view and analyze Morae recordings, automatically calculate metrics, generate graphs, and create highlight videos to share with stakeholders.

Proximity communicates affinity while distance lacks affinity. Group related items together Groups of items can feel like one item

Alignment communicates association Nothing should be placed on the screen arbitrarily. Every item should have a connection with something else on the screen – after all if it’s on the same screen it’s associated. 3 Horizontal Alignments: Left Center Right Center alignments are visually the weakest

Repeated elements blend in Repeat some aspects of the design throughout the entire application. Repetition can be thought of as consistency. Appropriate repetition makes the application appear cohesive. Elements that repeat each page become visually persistent. As users move from place to place in your software, they need only to be able to see what’s changed.

Contrast communicates importance. Use contrast to focus the users attention, to guide him/her through the application. Contrast, or don’t. If two items are not exactly the same, make them different – really different. Subtle difference isn’t contrast, it’s perceived by users as tension in the screen and often looks like a mistake.

http://www.uxmagic.com	106
http://uxpractitioner.blogspot.com	68
http://wpfdesign.blogspot.com	47
http://carmelhassan.es	42
http://uxmagic.com	22
http://www.slideshare.net	8
http://www.carmelhassan.es	7
http://static.slidesharecdn.com	1

U Xmagic Agile Presentation

by www.donburnett.com on Feb 01, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

8 Embeds 301

Statistics

U Xmagic Agile Presentation — Presentation Transcript