J.D. Meier's Blog : Design

Customer Connected Engineering

J.D. Meier — Tue, 19 May 2009 20:00:41 GMT

I posted slides on how we do Customer Connected Engineering at patterns & practices to Shaping Software. Customers Connected Engineering (CCE) is how we engage customers throughout our product development. We formally engage customers during the planning, development, and release of our deliverables to help make sure our deliverables are customer-driven. Customers supply the scenarios, help prioritize, and provide feedback helping reduce the gap between what we build and what customers actually need. It's effectively a prosumer model where the producer pairs with the consumers to improve the results.

Find out more about Customer Connected Engineering including key activities and guiding principles.

Model-Driven Approaches

J.D. Meier — Fri, 01 Aug 2008 19:05:00 GMT

When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and the machine.

Key Points

Model for humans. For humans, I find using a whiteboard (whiteboard modeling) works well -- it's universal.
Model for machines. For machines, I find speaking closer to the code is a good thing and design is rarely a clean model.
Model to learn. I've found modeling more useful when you throw it away -- it's a learning tool. Model so you get it, then go to it. I think the key is that the model is a map, not the actual territory. The usefulness of a map is actually decoupling from the complexity and creating a simpler lens.
Model to share. I think the real value of models is when you create a way to share the problem or solution in a simplified way. This helps for sharing a vision of the end in mind, as well as getting more sustained thinking around the problem.

Model-Driven Code
I've never experienced an effective modeling approach that turns visuals of systems into code, where the model doesn't get in the way. At some point, the model stops being useful for humans or stops being useful to the machine. As a result, I've never really been a fan of model-driven approaches that are coupled to code in practice, although they're always interesting in theory. While I'm open to the idea, I just haven't seen it. Am I missing out?

Effective Modeling for Shaping Software
While I'm not a fan of most visual modeling tools, there’s some very real modeling approaches I find to be effective (which is more about modeling for the humans to understand what matters.) I find that light-weight, human-oriented models are particularly effective for shaping software around quality attributes. For example:

Performance. For performance design, I've found Performance Modeling to be effective. See patterns & practices Performance Modeling
Security. For security design, I've found Threat Modeling to be effective. See patterns & practices Threat Modeling
Reliability. For reliability design, I've found Fault-tree modeling to be effective.

My Related Posts

Designing an Authentication and Authorization Strategy

J.D. Meier — Wed, 25 Jun 2008 21:35:46 GMT

What are the key steps to designing an effective authentication and authorization strategy? The keys are knowing your user stores, role stores, and who need to access what or perform which operations. In this post, I share the approaches we've used in two of our patterns & practices guides. These are the approaches we've used to help customers design successfully design their authentication and authorization approaches.

Designing an Authentication and Authorization Strategy - v1
When we first wrote Building Secure ASP.NET Applications, here's the meta-process we came up with for working through your authentication and authorization strategies:

Identify resources
Choose an authorization strategy
Choose the identities used for resource access
Consider identity flow
Choose an authentication approach
Decide how to flow identity

For elaboration, see Authentication and Authorization.

Designing an Authentication and Authorization Strategy - v2
When we recently wrote Improving Web Application Security, we made some revisions:

Identify your user stores.
Identify your role stores.
Identify resources you need to access and operations you need to perform.
Identify which identities need to access the resources and perform the operations.
Choose your authentication and authorization strategies.

Personally, I've found it really cuts to the chase if you start with your user stores and role stores, since they tend to be somewhat fixed.

Identities
When you think through the identities, I've found it helpful to think in terms of who needs to access which resources or perform which actions. Consider the following:

Original caller
Process identity
Service account
Custom identity
Role

Resource Types
When you think through the resource types, I find it helpful to think in terms of:

System
Application
User

Authorization Strategies
When thinking through the authorization strategies, I find it helpful to consider:

Role-based
Resource-based
Operation-based

Resource Access Patterns
When thinking through the resource access patterns, I find it helpful to consider:

Trusted subsystem model
Impersonation/delegation model

Designing authentication and authorization can be a gnarly topic. I hope the scaffolding above helps you find a path that works for you.

Four Stages of Market Maturity

J.D. Meier — Tue, 01 Jan 2008 02:28:33 GMT

You can tell the maturity of a market by the consumer patterns. If you know the life cycle stages of a market you can better anticipate what level of "needs" your product needs to match to be successful. (I always think of needs in stages like Maslow's hierarchy.)

The Four Stages of Market Maturity

Stage 1. Survival
Stage 2. Quality
Stage 3. Convenience
Stage 4. Customization.

From Survival to Customization
In the Autumn Special Edition of "strategy+business" magazine, Alonso Martinez and Ronald Haddock describe how a country evolves from developing nation to industrialized nation:

"As a country evolves from developing nation to indusrialized nation, the population's basic needs pass through four distinct stages. In developing countries, most of hte population is preocupied with basic survival - obtaining adequate food, shelter, and clothing. (Much of sub-Saharan Africa is in the stage right now.) As a middle class emerges, people seek greater quality in their food, housing, and clothing (This is currently happening, for example, in much of China and India.) Once a transitioning market's population can afford relatively high quality, they begin to seek convenience; they buy time-saving appliances and processed foods, and they may move closer to work. (This stage is emerging today in Eastern Europ and Latin America.) Finally, as the market graduates into the realm of developed nations, the population wants customization; with needs for survival, quality, and convenience now met, people will spend a premium (as many do in North America, Japan, and western Europe) to satisfy individual tastes and desires."

Key Take Aways
I think to successfully anticipate global market needs, you need to understand where in the stack, various consumers are. I've noticed a lot more attention on customization, particularly in social software and personal devices.

Kano, Satisfiers, and Dissatisfiers

J.D. Meier — Tue, 01 Jan 2008 01:24:00 GMT

If you're looking for yet another way to help you prioritize your backlog or to help you shape your product's design, consider the Kano model. One concept in the Kano model is satisfiers and dissatisfiers. You can think of satisfiers as features you might ask for. You can think of a dissatisfier as an unmet need. It's something you wouldn't necessarily ask for (latent need.) You just expect it. It's absence is a dissatisfier.

Examples
Here's a few examples:

As a colleague put it, if you buy a new car, you might ask about features of the engine or luxuries, but you just expect it to have a speedometer. If there's no speedometer, you'll be dissatisfied.
Spelling more words correctly won't make your article great. At the same time, consider the negative impact of spelling a bunch of words incorrectly (dissatisfiers)

Key Points
Here's the keys:

At some point, adding more satisfiers doesn't necessarily increase satisfaction.
Addressing a dissatisfier doesn't necessarily increase your satisfaction.
Not addressing a dissatisfier can exponentially decrease satisfaction.

Applied Use

You can imagine the impact on a product design. You add a bunch of features (satisfiers), but ignore some dissatisfiers (performance, security, reliability, usability.) That's a common pattern in failed product designs.
You can think in terms of your job. Do you deliver satisfiers or do you reduce dissatisfiers? Some "dissatisfier"jobs are undervalued or unappreciated until disaster strikes, then their exponential value becomes obvious.
You can think in terms of your life. Do you add satisfiers or do you decrease dissatisfiers? could reducing a few dissatisfiers exponentially improve your life?

My Relates Posts

Human Shepherds and the Law of Relevancy

J.D. Meier — Sat, 10 Nov 2007 23:14:00 GMT

Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places. It's the law of human relevancy.

The Law of Relevancy
No matter how relevant the information is, it's more relevant with the help of the right people.

The Human Shepherd
All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need. There's always a place for the human shepherd.

Usage / Examples

The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web. There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

A Story
In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc. We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.) I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork. We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

Scenarios in Practice

J.D. Meier — Mon, 15 Oct 2007 05:21:00 GMT

Scenarios are a practical way to organize and focus your product design, development and release. (We use scenario-driven engineering in patterns & practices)

Key Benefits

Business value. You can use scenarios to evaluate business value. What pain does that scenario address? ... What opportunity does it create? ... etc.
Chunking and prioritizing. You can use scenarios to chunk up and prioritize your product. You can think of versioning in terms of releasing incremental value or scenarios.
Effective design. Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design. It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective. It also opens the door to more precise questions about user experience or engineering challenges..
Focal point for perspectives. You can use scenarios as a focal point for user experience, business and tech perspectives.
Requirements in context. You can use scenarios to put requirements in context. A requirement makes a lot more sense when you see it in action.
Architectural trade-offs. You can use scenarios to evaluate and make architectural trade-offs. You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios. There's several flavors of scenario-based evaluations you can leverage.
Customer value. Your customers can appreciate how well you did (or didn't) address their scenario.
Tests for success. You can use scenarios as tests for success. By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

Chunking Up a Project Using Scenarios
If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals. What's the minimum set of tasks your user needs to perform with your product? That's your baseline release. What's the incremental value from there? That's how you start to shape your versions and releases.

User Experience, Business and Technical Perspectives
Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives. For the sake of example, let's say your scenario is "User views the product catalog." From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait," From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership." From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc. Well, no wonder getting software right is tough! Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

Constraints Make More Sense In Context
Constraints are boundaries to operate within, or what the solution must or must not do. In software, I see a lot of generic constraints passed down as policies. When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint. You can also measure whether that scenario is actually meeting the constraint. You can perform scenario-based testing against a set of scenarios with specific constraints.

Walking the Scenarios
Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful? Obviously, that's the extreme case, but it happens to me. It happens less now because whenever I go to buy something, I walk my usage scenarios. Doing a dry run against a scenario is very revealing. This approach works great on the engineering side too. It's one thing to have generic technical requirements for security or performance. It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective. Suddenly, generic technical requirements no longer seem as helpful, do they? They still have their place, but when you're engineering your job is to make the right trade-offs.

Scenarios and Solutions
Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation. As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

More Information

My Related Posts

Roles and Goals

J.D. Meier — Tue, 13 Mar 2007 05:44:00 GMT

The next time I need to get a set of requirements, I'm simply going to start with roles with goals.

I made the mistake of asking for a set of scenarios. What I ended up with is a list of user tasks. Tasks aren't the same as goals. Flying a kite is not the same as having a goal to discover electricity. One is what you're doing, the other is what you want to accomplish.

Since I didn't have the benefit of direct customer interaction for this case, I'm using that as a challenge. What is the most precise, reliable way to get the information need? Roles with goals. I realized, iterating on a list of roles with goals, would get me closer, faster. I can always drill into the stories or scenarios from the goals. The reverse doesn't seem to be true.

Requirements Perspectives

J.D. Meier — Sat, 10 Mar 2007 02:00:00 GMT

Here's a simple set of perspectives I use for rationalizing requirements:

User
Business
Expert / Technical
Industry/Standards

Believe it or not, simply identifying these perspective helps a lot. You'd be surprised how many debates happen simply because nobody explicitly identified the source or perspective of the requirement. You'd also be surprised how quickly this helps you make more deliberate decisions and understand what you trade.

How does this help? Your business goals might be a n orders per hour. Meanwhile, your user wants sub-second response time. Well, that's what your users want, but what will they tolerate? Can your business afford the resources for an idealistic experience? Design is always about trade-offs.

In practice, I generally see industry/standards trump business trump expert/technical, trump user. Unfortunately, a lot of software has unconsciously catered to the expert/tech/business at the expense of it's users -- making a lousy experience. On the flip side, some software has catered to users at the expense of the business or industry goals. See the dilema?

You can make a difference. If you build software, know the perspectives, know the goals, and know the scenarios. In some contexts, some tech/expert reccomendations simply do not make sense. Know what you're optimizing. In some scenarios, industry/standards reign, while in others user experience is king. Make sure you have the right representation at the table. Don't ask your patient to prescribe the medicine, or your doctor to rate the taste.

Scenario Frames for Guidance

J.D. Meier — Thu, 22 Feb 2007 10:26:00 GMT

When I tackle a problem domain, I first frame out the space. To do this, I list out scenarios and sub-scenarios. I group the scenarios under categories. Sometimes categories come first, sometimes scenarios do. I call the result, a Scenario Frame.

I use Scenario Frames to evaluate platform, tools, and guidance. I also use them for product design, innovation, competitive assessments, subject matter expert reviews, arch and design reviews, and as a way to build shared understanding of a problem space.

Here's a Scenario Frame Example my team is creating to enumerate and evaluate Source Control scenarios in VSTS 2005:

What's your favorite tool for framing out problem spaces?

Task-Analysis Grid for Communicating Product Design

J.D. Meier — Fri, 09 Feb 2007 23:16:00 GMT

How do you communicate design decisions? … Srinath sent me a helpful link on the Task-Analysis Grid. A Task Analysis Grid is effectively columns of scenarios along with sub-tasks to complete the task.

Here's the key points:

The columns are organized by Before, After, and Future
The sub-tasks are prioritized and color coded.

In practice, I think the Task-Analysis Grid is useful for communicating user experiences and high-level product design. For driving engineering and project management, I use Scenario Grids. Scenario Grids are useful for figuring out baseline releases, incremental releases, dependencies, as well as doing scenario-based evaluations and competitive assessments. I'll post more on building Scenario Grids another day.

Actors, Personas, and Roles

J.D. Meier — Mon, 05 Feb 2007 00:39:00 GMT

In user modeling, I usually come across actors, personas, and roles (user roles). I thought it would be helpful to distinguish these so that I can use the right tool for the job, or at least understand their relationships, strengths and weaknesses.

Summary
Actor

Defined - someone or something that "acts" on or with the system.
Sample- customer, fulfillment, credit approval.

Roles

Defined - a set of needs, behaviors, and expectations.
Use - develop an initial task model.
Keys - three Cs of context, characteristics, and criteria (i.e. overall responsibilities, patterns of interaction, and design objectives)
Sample - regular buyer, incidental buyer, casual browser.

Personas

Defined - fictitious characters that represent user types.
Use - create familiar faces to help inspire and focus project teams.
Sample - The Enterprise Architect is Art, and is a Programming/Platforms Expert who influences the technology direction, defines technology standards, and oversees (from a technology perspective, not a managerial perspective), the design of several applications in his business unit.

Analysis
Personas

Pros - They can encourage empathy among technology-focused designers and developers.
Cons - They can encourage projection and overly concrete thinking. They may not be truly representative. It can be tricky for the engineer or designer to figure out what matters and what doesn't.

Roles

Pros - they abstract the user roles efficiently and make them easy to work with.
Cons - they can be abstract to the point where you lose empathy.

They All Have Their Place
At the end of the day, actors, roles and personas have their place. I like the example from forUse: The Electronic Newsletter of Usage-Centered Design
#15, August 2001: http://www.foruse.com/newsletter/foruse15.htm

"For a simplified example, a business-to-business e-commerce application might be modeled with three actors: Customer, Fulfillment, and Credit Approval. The Customer might be differentiated into several roles: Regular Buying Role, Incidental Buying Role, and Casual Browsing Role. The latter might be described as: not necessarily in the industry and buying may not be sole or primary responsibility (CONTEXT), typically intermittent and unpredictable use, often merely for information regarding varied lines and products, driven by curiosity as much as need (CHARACTERISTICS); may need enticements to become customer, linkage to others from same account, access to retail sources and pricing (CRITERIA)."

What to Do
In practice, I've found the following guidance helpful: Create your full range of user roles, then create the personas for selected roles.

References
I've found the following references helpful on this topic

forUse: The Electronic Newsletter of Usage-Centered Design #15, August 2001: http://www.foruse.com/newsletter/foruse15.htm
Use Case Fundamentals, by Alistair Cockburn: http://members.aol.com/acockburn/papers/AltIntro.htm
Personas in Wikipedia: http://en.wikipedia.org/wiki/Personas
Personas: Moving Beyond Role-Based Requirements Engineering, by Granville Miller and Laurie Williams:
http://agile.csc.ncsu.edu/SEMaterials/Personas.pdf

Personas at patterns and practices

J.D. Meier — Sun, 04 Feb 2007 23:42:00 GMT

At patterns & practices, we introduced personas a few years back to help design user experience for our deliverables. Personas helped with a few things:

Understanding demographics.
Building empathy by putting a face behind the user role.
Building a common set of customer examples we can all talk about in meetings. (...Is this for "Art", "Bert","Mort" or "Elvis"?)

I think of a persona as a specific (yet generalized) instance of a role to "personify" and represent what users that play that role, might be like. While we originally argued over the details of the personas, a great by-product was that we focused on the distinctions across our various customer sets. This helped reduce ambiguity during product design. It also helped us make calls on where to put our resources and effort.

One important lesson we learned was that personas weren't as reusable across groups as they originally seemed they might be. In other words, we couldn't just grab a set of personas from another group, and call them our own. Instead, it meant time and effort to build a set that had specific meaning for our group in the context of what we build. While our naming overlapped with other groups, we had our own set of reference examples.

Here's the core personas we originally used:

ART (ARCHITECT / PLATFORMS AND PROGRAMMING EXPERT)
BERT (DEV LEAD / CORE COMPONENT DEVELOPER)
MORT (DEVELOPER)

Here's additional personas we used:

ELVIS - THE PRAGMATIC PROGRAMMER
ISAAC - BUSINESS APPLICATION DEVELOPER
SIMON - SYSTEM IMPLEMENTER

For sharing the persona information, we used a simple template

Persona
Background
Environment
Job Description
Attributes
User Experience goals
Information Sources
What does it mean to create a patterns & practices deliverable for this persona?

While that was a practical set of info for quick sharing, the research behind the personas included:

Overview
Household and Leisure Activities
A Day in the Life
Work Activities
Communication and Collaboration
Skills, Knowledge, and Abilities
Goals, Fears and Aspirations
Primary Roles
Secondary Roles
Fears
Career Aspirations
Computer Skills, Knowledge and Abilities
Technology Attitudes and User Experience Values
Tools
Issues
International Considerations
Opportunities
Market Influence
Demographic Attributes
References

Since our earlier days, I think we've shifted from persona-based design to more customer-connected engineering. We have a lot more direct customer involvement throughout the engineering.

Avoiding Do Overs - Testing Your Key Engineering Decisions

J.D. Meier — Sun, 04 Feb 2007 04:41:00 GMT

I noticed Rico has a Performance Problems Survey. From what I've seen, the most important problem is failure to test and explore key engineering decisions. By key engineering decisions, I mean the decisions that have cascading engineering impact. By testing, I mean, doing quick end-to-end tests with minimal code that gives you insight into the costs and glass ceilings of different strategies.

When I was working our developer labs, I would work with around 50 or so customers in a week. I had to quickly find the potential capability killers. To do so, I had to find the decisions that could easily result in expensive do-overs. If I took care of the big rocks, the little rocks fell into place.

Here's the categories that I found to be the most useful for finding key engineering decisions:

Authentication
Authorization
Auditing and Logging
Caching
Configuration
Data Access
Debugging
Exception Management
Input and Data Validation
Instrumentation
Monitoring
State Management

As you can see, there's a lot of intersection among quality attributes, such as security, performance, and reliability. One of my favorite, and often over-looked capabilities is supportability (configurable levels of logging, instrumentation of key scenarios, ... etc.) This intersection is important. If you only look at a strategy from one perspective, such as performance, you might miss your security requirements. On the other hand, sometimes security requirements will constrain your performance options, so this will help you narrow down your set of potential strategies. In fact, my challenge was usually to help customers build scalable and secure applications.

By using this set, I could quickly find the most important end-to-end tests. For example, data access was a great category because I could quickly test strategies for paging records, which could make or break the application. I could also test the scalability impact of flowing the caller to the database or using a trusted service account to make the calls.

To contrast this approach of end to end design tests versus typical prototyping, it wasn't about making a feature work or showing user experiences. These architectural proofs/spikes were for evaluating alternative strategies and litmus testing capabilities to avoid or limit downstream surprises and do-overs.

Idioms and Paradigms

J.D. Meier — Sat, 06 Jan 2007 08:44:00 GMT

John Socha-Leialoha wrote up a nice bit of insight on how Users are Idiomatic. John writes:

"First, different users will have different definitions of "intuitive." ... Second, and this isn't conveyed directly by the definition of idiomatic, users actually expect inconsistent behavior."

In my experience, I've found this to be true (user experience walkthroughs with customers are very revealing and insightful).

I first got introduced to idiomatic design for user experience several years back. One of my colleagues challenged me to improve my user interface design by trading what might seem like intuitive paradigms for more useful idioms. He used the example of a car. He said the placement of the gas/break pedals was not intuitive, but idiomatic.

He argued that what's important is that the pedals are placed where they are efficient and effective, not necessarily intuitive. His point was that I should make design decisions by thinking through user effectiveness/efficiency in the long term vs. just thinking of up front discoverability of intuitive models. He added that sometimes intuitive placement makes sense, as long as you're not trading overall user experience.

User experience in software is challenging so I enjoy distinctions like this that make me think of the solution from different angles.