J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

August, 2010

  • J.D. Meier's Blog

    Now Available: Windows Azure Security Notes PDF


    Windows Azure Security Notes (PDF) is a collection of our notes and learnings from exploring the cloud security space and working through Windows Azure security scenarios.   Note that this is not a guide and it’s not a Microsoft patterns & practices deliverable.  It’s simply a way to package up, hand-off, and share what we learned during the exploration stage of our patterns & practices Windows Azure Security Guidance project.

    The key things you’ll want to explore in the notes are the various application scenarios, the cloud security threats and countermeasures, and the checklist.


    Contents at a Glance
    Here is a quick look at the Windows Azure Security Notes:

    • Ch 1 - Our Cloud Security Approach
    • Ch 2 - Cloud Security Threats and Countermeasures
    • Ch 3 - Design Guidelines for Improving Cloud Security
    • Ch 4 - Choosing Web Application Security Architectures
    • Ch 5 - Web App Security Scenarios
    • Ch 6 - Choosing Web Services Security Architectures
    • Ch 7 - Web Services Security Scenarios
    • Ch 8 - Choosing Data Security Architectures
    • Ch 9 - Data Security Scenarios


    • Security Checklist for Cloud Applications
    • Visual Threats for Web Applications
    • Visual Threats for Web Services
    • Cheat Sheet - Web Application Security Threats and Countermeasures
    • Cheat Sheet - Web Services (SOAP) Security Threats and Countermeasures
    • Cheat Sheet - Web Services (REST) Security Threats and Countermeasures
    • Cheat Sheet - Data Security Threats and Countermeasures
    • How To - Use Forms Authentication with Azure Table Storage
    • How To - Use Forms Authentication with SQL Azure
    • How To - Enable SSL with a Self-Signed Certificate on Windows Azure

    Many thanks to the following folks for sharing their time and expertise along the way:

    • External contributors and reviewers: Adam Grocholski; Andy Eunson; Bill Collette; Christopher Seary; Jason Taylor; John Daniels; Juval Lowy; Kevin Lam; Long Le; Michael Smith; Michael Stiefel; Michele Leroux Bustamante; Norman Headlam; Rockford Lhotka; Rudolph Araujo; Sarang Kulkarni; Steven Nagy; Terrance Snyder; Will Clevenger
    • Microsoft contributors and reviewers:  Akshay Aggarwal; Alik Levin; Andreas Fuchsberger; Babur Butter; Bharat Shyam; Dave Brankin; Danny Cohen; Diego Dagum; Don Willits; Eugenio Pace; Gabriel Morgan; Jeff Mueller; John Steer; Julian Gonzalez; Mark Curphey; Mohit Srivastava; Pat Filoteo; Rahul Verma; Raul Rojas; Scott Densmore; Sesha Mani; Serena Yeoh; Sriram Krishnan; Stefan Schackow; Steve Marx; Stuart Kwan; Terri Schmidt; Tobin Titus; Varun Sharma; Vidya Vrat Agarwal; Vikram Bhambri; Yale Li
  • J.D. Meier's Blog

    Patterns and Practices for Improving Personal Productivity, Time Management, and Effectiveness


    I’ve been coaching individuals, teams, and leaders on getting results.  Basically, for several years I’ve tested and applied various patterns and practices for improving focus, improving motivation, improving time management, and improving personal productivity.  I’ve also applied these practices to distributed team settings for several years (I’ve lead distributed teams since 2001, working with Argentina, UK, India, etc.).  The system itself is a combination and synthesis of proven practices learned from project management, software management, positive psychology, and sports psychology.  It’s also battle tested in some of the most extreme scenarios.  It’s ultimately a simple system for meaningful results that scales up and down, from individuals to teams and leaders.

    At the heat of the system is a story-driven approach or a “3x3” approach:

    By using three stories to drive your day, your week, your month, and your year … you identify your most important results, you connect to your values, and you flow value on a regular basis.

    I’ve wrapped up and shared this getting results system as a guide.  The book is called Getting Results the Agile Way and you can read the testimonials which includes people inside and outside of Microsoft (it’s generalized to work beyond the Microsoft context.)  It’s one of my most important contributions back to the community … distilling all the of the best of the best of what I’ve learned about getting results from my various mentors, my multiple projects over many years, and from the school of hard knocks.  It’s the playbook I wish somebody gave me when I started.

    For this month, I’ve been doing a Monthly Improvement Sprint to help teach you the system and to learn how to improve personal productivity, improve energy, and improve time management.  Basically, I want you to get the system on your side.  Monthly Improvement Sprints are one of the core practices from the system, so I’m effectively, using the system to  teach the system.  Each day, I share another nugget in the form of a post on my personal effectiveness blog.  Each nugget is self-contained so you can pick up from anywhere. 

    Here is a description of the project:

    Here are the daily lessons so far on improving personal productivity, time management, focus, and prioritization:

    Join anytime and pick up from wherever you are.  The most important theme is this:

    Be the author of your life and write your story forward … a day at a time, and a moment at a time.

  • J.D. Meier's Blog

    Success Patterns for Web Sites


    So many Web sites fail at helping users complete tasks or find the information they need in a simple way.   E-Commerce sites like Amazon tend to do a better job than a lot of sites here because they have a tight feedback loop for customers completing their tasks.  Basically, they keep the score on their customer success against their goals.  If customers can’t find what they need, perform their transactions in a fast and simple way, easily give feedback, or provide useful reviews to the community at large, then Amazon fails and customers look for alternatives.  It’s a self-re-enforcing loop and Amazon does a lot of A/B testing to find the most effective way to improve customer success on their Web site.

    The good news is  … Success leaves clues in the form of principles, patterns, and practices.

    There’s really no reason for Web sites to fail at basic user experiences, given that so many problems are already solved.  Not only are the problems solved, but user experience solutions even have names in the form of patterns.  Better yet, you can check each pattern against live examples on the Web.   It’s effectively a living catalog of success.

    Lessons Learned on Site Design
    While working on one of my information architecture projects, I analyzed more than 350 Web sites, mostly in the consumer space, to learn interaction patterns, site design, and user experience patterns.  I apply these lessons to many of my CodePlex sites, Wikis, SharePoint sites, and blogs within the bounds of things that I control.   For example, on my personal effectiveness blog Sources of Insight, I regularly test site design principles, user experience, and interaction patterns.  The downside during all of my research is that I didn’t think to name all the patterns I learned.  Because I didn’t name the patterns, it’s difficult to share the lessons learned or to create a simple catalog of the cornerstone concepts.  All is not lost though …

    User Experience Patterns for Effective Site Design
    When you need to design effective user experiences for Web sites, you don’t have to start from scratch.  You can model from the success patterns of existing sites.  However, distilling all the successful principles, patterns, and practices can be a challenge.  One of my favorite guides that does the distillation for you is The Design of Sites.   It’s a comprehensive catalog of proven practices for designing effective Web sites in terms of customer-centered design, information architecture, interaction patterns, and task-completion.

    Patterns Catalog from The Design of Sites
    You can actually browse the full catalog of patterns from The Design of Sites book.  I like to be able to scan the patterns in alphabetic order by category, so I put them into a summary table to do so:

    Category Patterns
    Site Genres
    • BLOGS
    E-Commerce Basic
    Navigation (Simplifying)
    • SITE MAP
    • TAB ROWS
    Page Layouts
    Search Relevancy and Speed
    Task Completion
    Trust and Credibility
    • ABOUT US

    Not only are the names intuitive but when you use the book, you can drill into each pattern for concrete examples, as well as the design philosophy behind it.

  • J.D. Meier's Blog

    30 Days of Productivity and Getting Results the Agile Way


    Today was the final day of 30 Days of Getting Results, based on my book Getting Results the Agile Way.

    It’s basically free training on many of the key skills for:

    • Making meaning / Finding purpose
    • Focus
    • Productivity
    • Time Management
    • Energy Management

    It’s the synthesis of what I’ve learned at Microsoft in the trenches and my travels in life, as well as from many very good mentors.  Mostly, it’s what I’ve learned from the school of hard knocks, trial and error, and necessity (I think of it as a collection of Microsoft Survival Skills in a box.)

    Agile Results
    Agile Results is a personal results system for work and life.  It’s a simple system for meaningful results that you can apply whenever you need it.  It’s a way to help you make the most of what you’ve got.  It’s a way to be the author of your life, and write your story forward.

    Problems Addressed

    • How to improve your personal productivity and personal effectiveness
    • How to achieve work-life balance
    • How to find your motivation and drive
    • How to find your purpose and your passion
    • How to deal with being overloaded or overwhelmed
    • How to change a habit and make it stick
    • How to focus and direct your attention with skill
    • How to manage your time
    • How to spend more time on the things that really matter to you
    • How to play to your strengths and spend less time in weaknesses
    • How to make the most of your your moments, days, weeks, months, and years

    It’s been a fun ride and I’ve heard some amazing stories from people around the world.  I’ve enjoyed the emails and stories from people who have used the system to enhance their life, a day at a time, a story at a time.

    30 Lessons on Getting Results the Agile Way

    Key Links

    If you visit just one lesson, check out Day 27 – Do Something Great.   If you check out two, check out Day 10 – Feel Strong All Week Long.

  • J.D. Meier's Blog

    30 Days of Getting Results the Agile Way


    "Don’t count the days, make the days count." - Muhammad Ali

    If you've ever wanted to learn the key principles, patterns, and practices for getting results, now's the time.  I'm making August a focus on Getting Results the Agile Way.  It's a simple system for meaningful results.  It's been helping individuals, teams, and leaders improve their results and get on top of their game (see reviews and success stories.) 

    Throughout August, I'll write a new post each day on Sources of Insight to help you adopt Agile Results, a nugget at a time, starting with 30 Days of Getting Results.  If you want to follow along, subscribe to the RSS feed for Sources of Insight.

    Here are some of the key topics I'll be addressing:

    • How to get "on path," make meaning, and find your purpose with skill
    • How to be the author of your life and use three stories to drive your day, your week, your month, and your year
    • How to deal with being overwhelmed and deal with information overload
    • How to inspire yourself with skill, and find your motivation and drive
    • How to bounce back with skill
    • How to make more time for the right things and stop spending time on the wrong things
    • How to break out of analysis paralysis
    • How to create a rhythm of results that supports you in everything you do
    • How to let things slough off, instead of adding the straw that breaks the camel's back
    • How to achieve work-life balance while growing your capacity for results
    • How to enjoy the journey AND the destination
    • How to use your super skill to get more done in the same amount of time with less effort and better results
    • How to spend more time in your strengths, and less time in your weaknesses
    • How to use some simple practices from positive psychology for feeling good, finding happiness, and a peaceful calm
    • How to add power hours to your week, a day at a time
    • How to design your day with skill and set yourself up for success
    • How to get a fresh start each day and each week to get a new chance for your best results

    Agile Results is the system I talk about in the book, and it's a simple system for meaningful results.  You can think of it as a personal results system for work and life.  It's based on both studying success and applied research over a number of years, and it draws from a number of disciplines, including positive psychology, project management, software development, etc.

    It's not about software development, but it is the same system I've used to mentor others, coach teams, and lead distributed teams for more than 10 years.  You can think of it as "Scrum for Life" or "Story-driven results" or "Lean for Life."   You can use the system to improve your mind, body, emotions, career, financial, relationships and fun.  It's ultimately about writing your story forward, driving from your "why", and leveraging proven practices for thinking, feeling, and taking action.

    I know a number of people are going through significant changes in their life.  Having a system and science on your side, helps you stack the deck of success in your favor.

    If you want to get started fast without reading the book, here is a One-Page Guide to Getting Started with Getting Results the Agile Way.

  • J.D. Meier's Blog

    Site Maps, Storyboards, and Schematics for Site Design


    When you’re prototyping sites in the early stage, the three main artifacts are: sitemaps, storyboards, and schematics.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, and Jason I. Hong describe the three artifacts as follows:

    • Sitemaps - a high-level diagram showing the overall structure of a site.  You use it to reflect an understanding of the information structure or architecture of the site as it's being built, and the navigation structure or flow through the entire site, at the macro level.
    • Storyboards - a sequence of Web pages depicting how a customer would accomplish a given task.  You can use storyboards to show important interaction sequences or flows through  a site.
    • Schematics - represent the layout of the content that will appear on individual pages.  They don't usually include images, instead they have placeholders and labels.
  • J.D. Meier's Blog

    Information Architecture, Navigation Design, and Graphic Design


    There’s often confusion over the distinction between information architecture, navigation design, and graphic design.  One of my favorite books that explains what these terms are and the distinctions is the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong.

    Van Duyne, Landay, and Hong define the terms as follows:

    • Information Architecture - Identifying, structuring, and presenting groups of related content in a logical manner.
    • Navigation Design - Designing methods so that customers can find their way around the information structure.
    • Graphic Design - Developing the visual communication of information, using elements such as color, images, typography, and layout.

    Note that information and navigation design are typically done before graphic design. 

    Also note that the authors mention that there's often a debate in the design community about the boundaries between information architecture and information design.  They point out that information architecture focuses more on structure and language, while information design focuses on presentation and perception.  At the end of the day, the key point is that the two disciplines are about helping customers find, understand, and manage complex information.

    It’s also worth knowing the terms “Information Model” and “Data Models” since they often come up in discussions regarding information architecture:

    • Information Model -    A model of the concepts, relationships, constraints, rules, and operations for a given domain, and it can provide a sharable, stable, and organized structure of information requirements.  See Information Model (Wikipedia)
    • Data Models – Describes how the data are represented and accessed and defines the data elements and relationships among data elements for a given domain.  See Data Model (Wikpedia)
  • J.D. Meier's Blog

    Project Plans in a Nutshell


    "I love it when a plan comes together." -- Colonel John "Hannibal" Smith, The A-Team

    Project plans are tough.  No matter how many times you do them – they are always tough.  I’ve been doing them for years, and yet the path from zero to a "good enough" plan is always a lot of work.  But it's worth it.  It's often what separates the failed projects from the successful ones.  When a project fails, you can usually find clues in the plan (or lack of.)

    Regardless of how you get there or how you share the plan, the following are essential elements:

    • Problem statement
    • Customer / who’s it for
    • Vision / strategy
    • Goals
    • Outcomes
    • Deliverables
    • Timeline
    • Tests for success
    • Measures / metrics
    • Scenarios / stories
    • Resource map
    • Risks
    • A map of the work (work breakdown structure)

    In question form, some simple checks are:

    • What are the most important outcomes?
    • Do we know what good looks like?
    • Who's doing what when?
    • What's the minimum we need to accomplish or it's not worth it?

    It's worth noting that projects often fail because

    • Lack of clarity on the goal
    • Lack of understanding the work (work breakdown structure)

    Interestingly, I know of some executive reviews that boil down to two cutting questions:

    • What's the investment?
    • What are the results?

    It helps answer the higher question -- “Why are we doing this and does it make business sense?”

  • J.D. Meier's Blog

    The Design of the MSDN Hub Pages


    This is a behind the scenes look at my involvement in the creation of the MSDN Hub pages. 


    The MSDN Hub pages you get to from the main “buttons” on the MSN home (pictured above.)   Specifically, these are the actual pages:

    The intent of the MSDN Hub pages to create some simple starting points for some of our stories on the Microsoft developer platform.  For example, you might want to learn the Microsoft cloud story, but you might not know the “building blocks” that make up the story (Windows Azure, SQL Azure, and Windows Azure platform AppFabric.)    A Hub page would be a way to share a simple overview of the story, a way to get started with the technology, common application paths and roadmaps, and where to go for more (usually the specific Developer Centers that would be a drill down for a specific technology.)

    Why Was I Involved?
    If you’re used to seeing me produce Microsoft Blue Books for patterns & practices, and focusing on architecture and design, security, and performance, it might seem odd that I was part of the team to create the MSDN Hub pages.   Actually, it makes perfect sense, and here’s why -- They needed somebody who had looked across the platform and technology stacks and could help put the story together.  Additionally:

    • The purpose of the MSDN Hubs was to tell our platform story and put the platform leggos together in a meaningful way.  This is a theme I’ve had lots of practice with over the years on each of my patterns & practices projects.
    • I was already working on the Windows Developer Center and the Windows IA (Information Architecture), and the .NET IA, so I was part of the right v-teams and regularly interacting with the key people making this happen.
    • I shipped our platform playbook for the Microsoft Platform – the patterns & practices Application Architecture Guide, second edition.
    • I had put together a map of our Microsoft application platform story, as well as created maps, matrixes, and drill downs on our stories for key clusters of our Microsoft technologies including the presentation technology stack, the data access technology stack, the workflow technology stack, and the integration technology stack, etc. 
    • I had previously worked on specific projects to create a catalog to organize and share the patterns & practices catalog of assets. (Internally we called this the “the Catalog Project”.) 
    • I had worked on an extensive catalog of app types, which served as the backbone for some downstream patterns & practices projects while influencing others, including factories, early attempts at MSF “app templates”,  our patterns & practices catalog (so we could  enable browsing our catalog by application type), and then of course, the Microsoft Application Architecture Guide.
    • I teamed across product teams, support, field, industry experts, and customers to create a canonical set of app types for the App Arch Guide.  Here’s what Grady Booch, IBM tech fellow, had to say about the App Types work -- “an interesting language for describing a large class of applications.”  Naturally, this work fed into the MSDN Hub pages since we need to map out the most common application patterns, paths, and combos. 

    My Approach
    My approach was pretty simple.  I worked closely with a variety of team members including Kerby Kuykendall, Howard Wooten, Chris Dahl, John Boylan, Cyra Richardson, Pete M Brown, and Tim Teebken.  I started off working mostly with Kerby, but eventually I ended up working closest with Tim because he became my main point of contact for influencing and shaping the work.  That said, it was still a lot of mock ups, ad-hoc meetings, whiteboard discussions, and group meetings to shape the overall result.  Tim did a stellar job of integrating my feedback and recommendations, as well as sanity checking group decisions with me.

    I also sanity checked things with customers, and I worked closely with folks on the Microsoft Developer Platform Evangelism team including Tim Sneath and Jaime Rodriguez.  They were passionate about having a way to tell our platform story, show common app pathy, and how to put our leggos together, and make technology choices.  I tried to surface this in the design and information model for the Hub pages.

    The Hubs
    For the Hubs, at one of our early meeting in November of 2009, I recommended a we use “deployment targets” as a way to help slice things up and keep it simple.  Specifically:

    • Cloud
    • Desktop
    • Games
    • Mobile
    • Server
    • Web

    As you can see, it maps very well to the App Types set I created circa 2004, but I evolved it to account for a few things.  First, I included learnings from working on the App Arch guide (such as moving away from Rich Client to just “desktop.”) Second,  I tried to pin it more directly to physical deployment targets to keep it simple.  As a developer, you can write apps to target the Web (a “Web” browser app), a desktop (such as a Windows client, or Silverlight, or WPF, etc.), a game (game console), etc.   Third, I aligned with marketing efforts, such as recommending we use the “deployment target” metaphor and I renamed the “Mobile” bucket to “Phone” (which worked, because it extended the “deployment target” metaphor, was still easy to follow, and kept things simple.

    I also kept the physical aspect of the “deployment target” metaphor loose.   For example, “Web” could run on server, or “desktop”, etc.  Instead, I wanted to bubble up interesting intersections of application types plus common deployment targets, and keep it simple.

    The Server Hub
    For the server hub, I recommended addressing our story from a few lenses.  First, we have server-side products that can be extended, such as SharePoint, Exchange, SQL Server, etc.  That lens is pretty straightforward.  Second, I recommended focusing on “Service.”  Here’s where it’s hard for folks to follow if they aren’t familiar with server-side development.  While you can lump “service” under “Cloud” (as a cloud developer, I can write a Web app, a service, etc.), the “service” story is a very special one.  It’s the evolution of our “middleware developers” and our “server-side developers.”  It’s the path that the COM builders and server-side component builders shifted to … a more message-based architecture over an object-based one, as well as a shift to replacing DCOM with HTTP.

    So if we had a Server Hub, it realistically should address building on our server-side products/technologies (SharePoint, Exchange, SQL Server, AppFabric, etc.) and it should address “Services.”  Sure you could also lump SharePoint under Web or Services under Cloud, but you can also bubble up and give focus to some of the fundamental parts of our Microsoft application developer platform.

    To be fair, a lot of folks moved around during the MSDN Hub page project, and as new folks came on board, the history, insights, and some of the work may have gotten lost.

    How To Solve the Issue of Too Many Hubs
    This was my suggestion for dealing with too many Hubs:

    “I think one thing that helps to keep in mind is that different people will want different views – but I think it’s simpler to choose the most useful one across the broadest set of scenarios.   That’s why Burger King and McDonald’s have a quick simple visual menu of the most common options … then you can drill in for more with their detailed menu if needed.  I like that metaphor because it addresses the “simple” + “complete”  Platform is a pretty solid bet – with an orientation around “tribes” (I’ll walk you through when we sync live) – after all, we do competitive assessments against platforms and that’s where we need to win.”

    I also made a few additional recommendations to deal with the problem of “simple” + “complete”:

    1. Add an “Office/SharePoint”, and a “Server” (SQL Server, Windows Server, Exchange) – the Office/SharePoint platform tends to have a tribe of customers that speak the same language and share the same context … different than your everyday .NET dev.   It’s like BizTalk in that it’s a specialized space.
    2. Use a carousel approach to feature the main 4, then a “view more…” pattern so show the full 6 or so top level – and leave breathing room.  I would go to a page that shows the full set at the top, but then shows the full set of products against a durable backdrop.  This would address the “AND” solution of both “Simple” and “Complete”

    This would provide a “durable” + “expandable” … AND… “simple” + “complete” … and in the end, a “platform guidance” approach.

    While I’m not a graphic artist, I had done some mockups to help illustrate the point …

    Home with “View More >>”


    View More … (full dev center against a durable backdrop, full tech stack, Roadmaps)


    This is blowing up a section of the “Microsoft Developer Products and Technologies” map above that I had created to illustrate the point:


    … etc.  and the map of course, continued with the technology stack, but used a robust backdrop.  The map would need to be vetted across product teams but that’s just the point … have a common map that shows our “catalog” of technologies that customers could easily browse, and that product teams stand behind, while providing simple jump points to either MSDN Developer Centers or Product Team sites.

    The Information Model for the Hub Pages
    I tried to be inclusive in the information model and I wanted to address and integrate customer pain points I’ve heard about how we tell our story over the years, as well as keep the pages simple and useful, based on what I know about customer usage patterns.   These are the main sections I recommended:

    • Key Technologies
    • Overview
    • Common Paths
    • Download and Install
    • Build Your First Apps
    • Arch / Design
    • Roadmaps
    • Developer Centers and Home Pages

    A picture is worth a 1000 words (note this is a picture of the “Information Model” – NOT the page mockups):



    My key customer scenarios and questions I used for test cases were:

    1. Can I quickly make sense of the particular story? (cloud, web, etc.)
    2. Can I figure out what technologies are relevant?
    3. Can I figure out how to choose which technology combination to use?
    4. Can I quickly install whatever I need to get up and running?
    5. Can I build a quick Hello World app to get my feet wet and some quick confidence?
    6. Can I figure out the roadmap for the technology or technologies?
    7. Can I get a quick sense of the most common application patterns, app types, and design patterns?
    8. Can I figure out my key architecture and design issues if necessary?
    9. Can I figure out where to go for more? (which Dev Centers, which landing pages, which resources, etc.)

    My key recommendations included:

    • Provide  the most common application paths for the given stories (based on the App Arch guide and DPE feedback.)
    • Start with text-based articles and if feasible, add video.
    • If we have video overviews, then have the PG teams create them so that they stand behind them and connect with customers
    • Keep the areas repeatable across the Hub pages
    • For a metaphor, think of the Hubs as the centralizing story for our “building blocks” … and think of our building blocks as the technologies and the “Developer Centers”
    • Name the articles “How To –“ and make them actionable and step-by-step
    • Name the videos “Explained” if they explain a concept and “How To” if they provide a set of steps.
    • Eventually create “Getting Started Guides” for each of the Hubs.

    Tim Teebken and I had many late night discussions and drill-downs, which made the work interesting and exciting.  It’s always great to work with smart people.  We pushed each other, challenged each other, and ultimately we stayed on the same page on the journey.

    Well, that’s the story in a nutshell.   That’s a behind the scenes look at the making of The Design of the MSDN Hubs and the role that I played.

    If you have feedback on the information model, please feel fee to send my way.  You can use the contact form on my blog.

  • J.D. Meier's Blog

    Paper Prototypes Over Computer-Based Tools


    When it comes to prototyping Web site design, paper prototypes tend to have an advantage.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong, the authors explain some of the advantages.

    Iterate and Explore the Design with Paper Prototypes
    Van Duyne, Landay, and Hong write:

    "Research shows that designers who work out conceptual ideas on paper tend to iterate more and explore the design space more broadly  whereas designers using computer-based tools tend to take only one idea and work it out in detail."

    Low-Fidelity Prototypes Over High-Fidelity Prototypes
    Van Duyne, Landay, and Hong write:

    “Nearly every one of the designers we have talked to has observed that the discussions is qualitatively different when people are presented with a high-fidelity prototype.  Clients often respond with comments like, 'I do not like your color scheme,' or 'These two buttons need to be aligned correctly.'  When presented with a low-fidelity prototype, however, clients are more like to say something like, 'These labels on the navigation bar do not make sense to me,' or 'You're missing a link to the shopping care here on this page.'  In other words, with low-fidelity prototypes, which lack irrelevant details like color, font, and alignment to distract the eye, people focus on the interaction and on the overall site structure. “

    However, it's worth noting that software that emulates paper prototyping can be very helpful.  One example is Balsamic Mockups.

  • J.D. Meier's Blog

    Slides for The Rule of 3, Hot Spots, and Monday Vision, Daily Outcomes, Friday Reflection


    At the end of the day, if I’m going to throw my time and energy at something, I want to know that it will make impact.  I also want to make sure that I’m on path, meaning it connects to my values and my purpose, and that I’m using proven practices to make things happen with skill. 

    There is a lot of science and wisdom of the ages but it’s tough to pull everything we know about thinking, feeling, and taking action in the most effective way.  Add to that the challenge that we’re all different and we have to apply any principles, patterns, or practices to our specific scenario or context.

    Getting Results the Agile Way is a way to pull it all together and get the system on your side.  It’s the system I’ve honed over years and it’s principle-based, which means you can tailor it very easily to yourself or the situation.

    To make it easy to learn some of the key ideas, I created three short slide shows to share the three key parts of Agile Results:

    • The Rule of Three Slide Show - The Rule of 3 is a simple concept.  Think in three’s.   The Rule of 3 helps us deal with information overload.  It’s a simple way to set limits and chunk things down.
    • Hot Spots Slide Show - Hot spots are a simple metaphor for thinking about what’s important.  Imagine your life as a heat map with Hot Spots.  Hot Spots are the key investment areas or choice points that need your attention.  Hot Spots are a lens and each Hot Spot can represent pain or opportunity or pleasure.
    • Monday Vision, Daily Outcomes, Friday Reflection Slide Show - Monday Vision, Daily Outcomes, and Friday Reflection is a simple pattern for weekly results.  It's a way to use stories to make your week more meaningful and spend more time achieving what you want.

    For August, I’m putting a strong emphasis on sharpening and honing my execution skills – a tune up of the system.  As part of the process, I decided to make my August theme all about getting results.  You can follow along at 30 Days of Getting Results where each day I will share another nugget from the book of getting results.

  • J.D. Meier's Blog

    Expert Reviews Using Heuristic Evaluation


    Heuristic evaluation is one of the most common types of expert reviews for Web sites.  It was developed by Jakob Nielsen.  In the book, The Design of Sites, by Douglas K. Van Duyne, James A. Landay, Jason I. Hong, the authors explain heuristic evaluations.

    What Is a Heuristic Evaluation
    Van Duyne, Landay, and Hong write:

    “The basic idea is to have three to five expert judges independently evaluate a site, using a list of usability heuristics or principles.“

    How To Perform a Heuristic Evaluation
    Van Duyne, Landay, and Hong write:

    “In a heuristic evaluation, the judges go through the site, often with a set of sample tasks as a guide, looking for violations of the heuristics.  They note each violation and make a suggestion for fixing it. ... The judges also rate each violation with a level of severity.  Severity levels are usually assessed on the basis of the expected customer impact and frequency of the violation.”

    7 Design Principles / Heuristics (The Design of Sites)

    1. Be consistent throughout.
    2. Offer informative feedback.
    3. Rely on recognition over recall.
    4. Help customers prevent and recover from errors.
    5. Support customer control and freedom.
    6. Help frequent customers use accelerators.
    7. Strive for aesthetic and minimalist design.

    10 Usability Heuristics (Jakob Nielson)

    1. Visibility of system status.
    2. Match between system and the real world.
    3. Use control and freedom.
    4. Consistency and standards.
    5. Error prevention.
    6. Recognition rather than recall.
    7. Flexibility and efficiency of use.
    8. Aesthetic and minimalist design.
    9. Help users recognize, diagnose, and recover from errors.
    10. Help and documentation.

    For an explanation of Jakob Nielson’s 10 usability heuristics, see Ten Usability Heuristics.

  • J.D. Meier's Blog

    Results, Social, and Process Lens for Organizational Culture


    I've been sharing this lens with some of the people I mentor and they've been finding it helpful.  It's a simple lens for looking at the organizational culture you’re in and helping make sense of what you see:

    • Results - This is a focus on results (what, why, outcomes, measures/metrics, tests for success, scorecards, etc.)
    • Social - This is a focus on the people (It's who knows who, friends, enemies, politics, and agendas, etc.)
    • Process - This is a focus on the process of things (how, charters, roles, policies, procedures, etc.)

    You can usually get a sense for what an organization values by looking to the writing on the wall.  The key word here is “valued.”  You need to know what’s valued so that you can tailor your behavior and expectations for the context.  It helps you more effectively adapt your behavior, adjust the situation, or avoid situations with skill.

    The ideal scenario is a balance of the results + social + process.   In my experience, I’ve found that usually an organization tends to be out of balance – they lean more towards one end than another.   Here are some of the symptoms you see when an organization is skewed toward one end:

    • Too much “Results” focus -- leaves too many wakes and a trail of bodies
    • Too much “Social” focus -- turns into the “old-boys club”, “mafia management”, favors, and back-door deals.
    • Too much “Process” focus -- comes at the expense of good people, death by 1000 paper cuts.

    When you know the context of the org you are in, you know what counts and what does not.  This helps you reshape your expectations and your behavior accordingly which leads to your success.

  • J.D. Meier's Blog

    CRUD for Content


    While we’ve been thinking through content strategies and content experiences, one of the phrases I started using to quickly share an idea is “CRUD for Content.”   It’s modeled after CRUD operations for applications – CREATE, READ, UPDATE, DELETE.  It’s simple, but it quickly helps folks relate to the simple operations you can do with content as a user:

    • Browse it
    • Search it
    • Save it
    • Share it

    Sure there are plenty of variations off of that, but it’s a helpful backdrop to start from when thinking through experiences for finding, searching, saving, and sharing content on MSDN.

  • J.D. Meier's Blog

    Employee Engagement on Getting Results the Agile Way


    David Zinger has shared his take on Getting Results the Agile Way in a review on his blog at http://www.davidzinger.com.  You can check out David’s review of Getting Results the Agile Way at:

    If you don’t know David, he’s a writer, educator, speaker, consultant, and all around good guy, that lives and breathes employee engagement, which is all about how individuals, teams, and leaders can be more engaged in the work that they do.   His passion and super skill is helping people get more out of their work, and unleash their passion on the job.

    You can see David in action at The Employee Engagement Network and you can check out his amazingly concise and insightful book, Zengage.  In a nutshell, Zengage is a short powerful book to help you get more out of your work by getting more into your work.

Page 1 of 1 (15 items)