The Rapid Research Method is a way to speed up your product research. It’s also a way to speed up ramp up time when you are leaning a new domain. The Rapid Research Method is also a key for rapid innovation and rapid product design and development. Lastly, the Rapid Research Method is also a great way to map out a space and perform competitive assessments.
One of the challenges with product development is doing effective research for your product design to make sure you have the right map of the pains and needs, the top concerns, and the key desired outcomes. Another challenge is actually making this information actionable and simple to share.
I’ve had the benefit of driving several projects end-to-end, so I’ve been through the research and exploration stage multiple times. I’ve learned a lot of tricks for speeding up research and making it more effective. I’ve had to use these techniques to play catch up in various domains from application architecture to security and performance, to even the cloud. They work.
I’m going to share a few techniques in this post. Collectively, I”ll refer to using them as the Rapid Research Method. It’s the approach I’ve used for many, many projects over many years, and as a way to perform competitive assessments.
What’s important about the techniques is that they make it easy to rapidly organize and share vast amounts of information in an actionable way. Looking back, one of the big surprises for me is how just about any domain can be broken down into questions and tasks. If you know the questions that people ask and the tasks they need to perform, you’ve effectively mapped out the most important information within that domain. This helps you prioritize all the rest of the information, such as concepts, principles, patterns, and practices. Another way to look at it is that all the information is either going to be action or reference. For example, a checklist would be actionable, while a whitepaper on a key topic, tends to be conceptual.
Software, like an information product, tends to suffer from information management problems. It’s tough to share “castles in the mind.” Then there is the people factor. Not everybody can slice and dice information the same way, or with the same skill. The real issue though is sharing “state.” The problem with research is that it’s like climbing a mountain. How quickly can you get others to make it up the mountain, after you? What sort of trail or spikes can you leave along the way? That’s where these research tools that I’m about to share come into play. They help you not only get you and your teammates up the mountain faster, but they leave a trail that others can follow.
About the Approach
The approach is fairly easy. It involves creating simple lists. The power comes from how you create and share these lists. It’s actually the information architecture of the research that unleashes the power of your research. The single best thing you can do with your research is produce output that can easily be used by others, so that you can easily bring in more brains on the problem. When everybody can see the lay of the land, it’s easier for people to find a faster way forward, get resourceful and solve problems.Here is the approach in a nutshell:
- Gather the Questions. In this step, simply start gathering the user questions. Questions are everywhere. The trick is to capture them and put them down on paper. My favorite questions are “Why" and “What is XYZ" and “How does XYZ work” or “When do I use XYZ.”
- Gather the Tasks. In this step, simply gather the user tasks. You can interview users. You can watch them in action. You can survey. You can play and explore the domain yourself. You can analyze search queries. What’s important is that you capture the user actions. This compliments the user questions. Questions are the “conceptual.” Tasks are the “actionable.” When gathering tasks, I find it helpful to write them down individually using the pattern “How To XYZ.”
- Identify the Hot Spots. As you organize your questions list and tasks list into more meaningful buckets, you’ll start to see common categories. Consolidate the categories as best you can. This will help you focus and refine your research and funnel what you learn. These “Hot Spots” will make it a lot easier to slice and dice the domain into actionable nuggets.
- Create a Frame. Use your “Hot Spots” to create a “Frame” for your domain. One way to do this is to create a simple table of your “Hot Spots” and a description of each “Hot Spot.” This creates a quick lens for looking at the domain, and puts a focus on the most important categories of information. When you need to share your research with others, you now have a fast way to show how you broke the information space down and made it more actionable. Experts will quickly validate or correct your frame. That’s the beauty of this approach. You can’t lose. You are always improving it based on what you learn. It’s a true learning system.
- Gather User Stories. User stories are a great way to really take things to the next level. They help to up-level the tasks, build empathy, and really put things in context. I like to manage these as simple lists, and I use the language, “As a user, I want to …”, or “As a user, I need to …”
You can browse the examples below to see what these question lists, task lists, hot spots/frame, and user stories look like.
Key Guidelines to Keep in Mind
- The value of your solution is the value of the problem solved. So the better job you do of capturing the right problems, the better chance you have at a successful product or solution.
- Experience is the short cut. Find the people with experience. You can save yourself exponential time, money, and resources by finding the right people who have the experience who can quickly share the questions, tasks, and scenarios that matter within a given domain.
- Relevancy is king. The best solutions don’t matter if they aren’t relevant. You stay relevant by staying connected. The trick is to stay connected to the key opinion leaders and influencers within a given domain. You want to know the movers and the shakers as well as the folks that play in the domain on a daily basis.
Hot Spots and Frames
“Hot Spots” are simply the key categories or areas of focus. They represent the categories that are key choice points. They are actionable. They are “Hot Spots” because they are 80% of where the action is. They are the 20% of the domain that accounts for 80% of the activity. I use “Hot Spots” as a way to slice a domain down to size and quickly get to what counts. Each “Hot Spots” represents an area that is either a key opportunity or a key pain point. The “Hot Spots” are a great way to organize actionable information such as principles, patterns, and practices.The Frame is simply a lens for looking at a problem. It’s what’s in the picture and what’s out. How you frame a problem domain can either simplify the problem space, or make it more complex. When you frame the problem space well, it makes it easier to act on it. It makes it easier to identify opportunities for innovation. It makes it easier to research the problem space with better focus. Focus is your friend.
The problem is that you usually don’t know the key areas up front. Framing out the space is part of the challenge and it’s part of the by-product of your research. What I’ve found is that when you start to collect questions and tasks, that “Hot Spots” start to emerge. You will quickly start to see patterns and things will naturally start to cluster. This collection of “Hot Spots” becomes the backbone for your frame. Rather than be complete, it’s about being effective. You can use the 80/20 rule to your advantage here, which is how you both gain speed, but also amplify your impact by focusing on the highest priorities.
Frame Example
This is a simple example of a frame using security Hot Spots. By using this collection of Hot Spots, it was very easy to collect questions and tasks within the security domain. It was also easy to walk different technologies and evaluate their security profile. We also used the frame to quickly gather and organize threats, attacks, vulnerabilities, and countermeasures. Organizing the information using this frame made it more actionable, and it made it a lot easier to deal with information overload.Security Frame with Hot Spots
Categories
- Auditing and Logging
- Authentication
- Configuration Management
- Cryptography
- Exception Management
- Input and Data Validation
- Sensitive Data
- Session Management
| Category | Key Considerations |
| Auditing and Logging | Who did what and when? Auditing and logging refer to how your application records security-related events. |
| Authentication | Who are you? Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password. |
| Authorization | What can you do? Authorization is how your application provides access controls for resources and operations. |
| Configuration Management | Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues. |
| Cryptography | How are you keeping secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity. |
| Exception Management | When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully? |
| Input and Data Validation | How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. Consider constraining input through entry points and encoding output through exit points. Do you trust data from sources such as databases and file shares? |
| Sensitive Data | How does your application handle sensitive data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores. |
| Session Management | How does your application handle and protect user sessions? A session refers to a series of related interactions between a user and your Web application. |
Question List Example
A “Question List” is simply a list of the key questions that people ask. You can find the key questions through surveys, going through forums, looking through blogs, and through hands on experience. Hands on experience helps you build empathy for what really matters, which will be essential when you are trying to rank, rate, and sort your list. It also helps to organize your questions into “Hot Spot” areas or buckets.Architectural Frame Questions List
Contents
- Authentication and Authorization
- Caching and State
- Communication
- Composition
- Concurrency and Transactions
- Configuration Management
- Coupling and Cohesion
- Data Access
- Exception Management
- Logging and Instrumentation
- User Experience
- Validation
- Workflow
- What are the approaches for identity store?
- What authentication mechanism will be used?
- What are relevant authentication and authorization patterns?
- How do I decide if I need to implement single sign-on?
- How do I design frontend single sign-on?
- How do I design for backend single sign-on?
- How to I flow identity to backend?
- What is impersonation and when should I use it?
- What is delegation and constrained delegation?
- How do you refresh your cache?
- How to design effective caching mechanism?
- What are common architectural pitfalls with caching?
- Which layers should implement caching?
- What data should be cached? (presentation, business and data access layers)
- How to choose a cache be store?
- How to cache data with different logical scopes?
- How to cache data on client side?
- How to cache user specific data?
- How to decide whether caching data will improve performance?
- How to manage expiration policy and scavenging mechanism?
- How do I protect cached data?
- How do I structure my application to optimize communication efficiency?
- How do I protect my communication channels?
- How do I choose appropriate communication protocol?
- How to flow identity across layers (tiers)?
- What are the common architectural pitfalls with communication?
- How do I structure my application to optimize communication efficiency?
- How do I protect my communication channels?
- How do I choose appropriate communication protocol?
- How to flow identity across layers (tiers)?
- What are the common architectural pitfalls with communication?
- What are effective techniques for communication between the tiers?
- What are effective techniques for exchanging data between the tiers?
- How to secure communication between the layers?
- When should I use synchronous communication?
- When should I use asynchronous communication?
- What are effective transaction management strategies?
- How do I determine concurrency requirements?
- What are the common architectural pitfalls with transactions?
- What’s the right level of granularity of transactions?
- How do I manage distributed transactions?
- What are the common architectural pitfalls with concurrency?
- How do I manage per app configuration?
- How do I manage per user configuration?
- How do I synchronize configuration across distributed environment (solutions)
- What are the effective configuration management patterns?
- What are the common architectural pitfalls with configuration?
- How to determine effective layering strategy?
- What are effective design patterns for coupling and cohesion?
- How to determine appropriate coupling between components and between layers?
- What are the common architectural pitfalls with coupling and cohesion?
- How do we pass data through the layers (tiers)?
- How to design effective data abstraction layer?
- How to model the data?
- How to page records?
- How to design for very large databases?
- What are the common architectural pitfalls with data access?
- What is domain-driven architecture?
- What is a database-driven architecture?
- How do I choose between domain-driven and database-driven?
- Which technology should be used to access data store?
- How to manage database connections?
- What logic should be implemented in the data helper components?
- How to handle transactions?
- How to handle concurrency?
- How to design for a multi-tenant database?
- How to choose between in-line SQL and Stored Procedures?
- How to design effective exception management strategy?
- What are effective exception management patterns?
- What are the common architectural pitfalls with exception management?
- How to design effective exception management strategy?
- What are effective exception management patterns?
- What are the common architectural pitfalls with exception management?
- Whether to design custom exception handling logic?
- Which layers should implement exception management?
- How to deal with unhandled exceptions?
- How to display exception info to users?
- How to design logging of exception data?
- How to propagate exceptions through layers?
- How to design effective layering strategy?
- What are effective design patterns for layering?
- How to separate layers into areas of concerns?
- How should layers interact?
- What are the common architectural pitfalls with layering?
- How to design effective layering strategy?
- What are effective design patterns for layering?
- How to separate layers into areas of concerns?
- How should layers interact?
- What are the common architectural pitfalls with layering?
- How do I migrate my existing architecture to layered architecture, for example monolithic to layered architecture, from 2-tier to layered architecture or 3-tier to layered architecture?
- How should I structure my development teams i.e. group by layers or group by functional modules?
- How will my solution and project structure look like when using Layered Architecture?
- How to design effective logging and instrumentation strategy?
- What are effective logging and instrumentation patterns?
- What are the common architectural pitfalls with logging and instrumentation?
- How to design effective logging and instrumentation strategy?
- What are effective logging and instrumentation patterns?
- What are the common architectural pitfalls with logging and instrumentation?
- Which layers should implement logging?
- When do I need a custom logging mechanism?
- How to make logging configurable?
- How to secure of logged data?
- How to design effective State Management?
- What are common architectural pitfalls with state management?
- Which components should be stateful?
- Which components should be stateless?
- Where should I store state?
- What information should be cached?
- How to manage state in a web farm?
- How to protect state data?
- What are the effective strategies and patterns for structuring the applications?
- How do I divide the application into sub-system?
- How do I factor the applications into layers, components and services?
- How do I factor the application into tiers?
- What are the common architectural pitfalls with Structuring?
- What are the effective strategies and patterns for structuring the applications?
- How do I divide the application into sub-system?
- How do I factor the applications into layers, components and services?
- How do I factor the application into tiers?
- What are the common architectural pitfalls with Structuring?
- Where do you perform validation?
- What do you validate?
- How to validate business rules?
- How to protect against malicious data?
- How to handle data validation exception?
- What are the common architectural pitfalls with validations?
- How to design client side validation?
- How to determine trust boundary for validation?
- What are the different types of workflows? What are the differences between them?
- What are common workflow scenarios?
- What are effective workflow patterns?
- What are effective the tools for designing workflow?
- What is workflow modeling and how does it help in system design?
- What are the common pitfalls with using workflows?
- What is “workflow persistence”?
- How does workflow communicate with the system?
- How design for error recovery in a workflow?
- How do I manage workflow instances?
- How do I host workflows?
Task List Example
A “Task List” is simply a list of the tasks that users perform within a domain. I find it helpful to use the language “How To.” This forces people to think in terms of goals. Sometimes it’s helpful to know the goal. Sometimes it’s more helpful to know the specific tasks. When you need to up-level it, simply ask “What are you trying to accomplish?” When you need to drop down a notch, simply ask, “What are you trying to do?” You can collect tasks from users through interviews, surveys, etc. Again, I find that hands-on is one of the best ways to really build empathy for the pains and needs. The real power comes from transforming from the problem side (the pains and needs), to the solution side (the specific goal or task that would address the pain or need.)Architectural Frame Tasks List
Categories
- Authentication and Authorization
- Caching and State
- Communication
- Composition
- Concurrency and Transactions
- Configuration Management
- Coupling and Cohesion
- Data Access
- Exception Management
- Logging and Instrumentation
- User Experience
- Validation
- Workflow
- How to identify trust boundaries
- How to design single sign-on strategy
- How to design role-based authorization
- How to design resource-based authorization
- How to design claims-based authorization
- How to design a trusted sub-system
- How to flow identity across layers and tiers
- How to improve performance with caching
- How to decide what data to cache
- How to decide where to cache data
- How to cache data on client side
- How to cache user specific data
- How to manage expiration policy and scavenging mechanism
- How to protect cached data
- How to implement thread safety for the cached items using locking
- How to cache data proactively
- How to cache data reactively
- How to design caching for distributed environment
- How to design caching for web farm scenarios
- How to structure an application to optimize communication efficiency
- How to design for remote communication
- How to protect communication channels
- How to choose a communication protocol
- How to pass data across layers
- How to flow identity across layers (tiers)
- How to secure communication between the layers
- How to design for synchronous communication
- How to design for asynchronous communication
- How to design fire and forget (one way) communication
- How to design for transactions
- How to manage distributed transactions
- How to design for atomic transactions
- How to design for long running transactions
- How to design for distributed transactions
- How to choose isolation level
- How to design configuration
- How to choose for configuration store
- How to separate application data from configuration data
- How to synchronize configuration across distributed environment
- How to protective sensitive configuration information
- How to enable changing configuration information at run-time
- How to design for loose coupling across layers
- How to design for high cohesion within layers
- How to design message based interfaces
- How to design your data access layer
- How to design data abstraction
- How to pass data across layers and tiers
- How to model your data
- How to page records
- How to design for very large databases
- How to design a domain-driven architecture
- How to design a database-driven architecture
- How to manage database connections
- How to handle transactions
- How to handle concurrency
- How to design for a multi-tenant database
- How to design exception management
- How to design for unhandled exceptions
- How to design structured exception handling
- How to design for appropriate display of exception data
- How to plan and design for exception logging
- How to propagate exceptions in a distributed design
- How to design for notifications
- How to design layering
- How to choose communication options between layers
- How to design message based interfaces for remove layers
- How to separate layers into areas of concerns
- How to design logging
- How to design for instrumentation
- How to design logging for distributed environment
- How to design logging for web farm scenario
- How to configure logging
- How to secure logged data
- How to choose the appropriate state model
- How to flow call context data across application layers
- How to design State Management
- How to store state
- How to manage state in a web farm
- How to protect state data
- How to design for passing data across tiers
- How to choose patterns for structuring your application
- How to factor security requirements when structuring your application
- How to factor performance and scalability requirements when structuring your application
- How to factor the applications into layers, components and services
- How to factor the application into tiers
- How to identify trust boundaries
- How to design a centralized validation solution
- How to validate input and data against business rules
- How to validate input and data for security
- How to validate the integrity of data
- How to handle data validation exceptions
- How to design workflow
- How to choose a workflow technology
- How to choose authoring mode
Summarizing Task Lists
I’ve found it especially helpful to organize massive lists of tasks into simple two-column tables. This creates a nice view that makes it very easy to prioritize, cut, or elaborate, in a fast and simple way. You can color code your lists. You can bubble key things to the top. You can make whitespace where you need it. You can group your tasks under sub-items within a row. The choices are endless, but the two-column tables does make dealing with massive mounds of information a breeze. The way it compacts and frames information makes scanning very easy, which is important when you are trying to get the “bird’s-eye view.”| Category | Items |
| Authentication and Authorization | |
| Caching | Design
|
| Communication |
|
| Concurrency and Transactions |
|
| Configuration Management |
|
| Coupling and Cohesion |
|
| Data Access | Design
|
| Exception Management |
|
| Layering |
|
| Logging and Instrumentation |
|
| State Management |
|
| Structure |
|
| Validation |
|
| Workflow |
|
User Stories at a Glance Example
One of the most powerful techniques I use to rapidly gather user requirements is user stories. I find that capturing user stories with the language, “As a user, I need to” .. or “As a user, I want to …” really helps add context and clarity, while keeping it amazingly simple. I also find that organizing the user stories by Hot Spots helps go a long way, especially when you are dealing with a large amount of information. Below is an example where I was collecting user stories to rapidly figure out the top concerns of business leaders and Enterprise Architects when it comes to cloud computing.The beauty is that when you capture the user stories well, it is very easy to deal with both timeless stories and timely ones. In this particular example, even though it’s a few years old, you can see that the top issues that it exposes are alive and well. One additional point on this example is that I used another information pattern. I call it the “View More” pattern. I use it to bubble up the short-list and then push the rest of the list below the “View More …” heading. It’s highly effective for organizing very large information sets, especially if you alphabetize the list.
User Stories for Cloud Enterprise Strategy
Categories
- Awareness / Education
- Architecture
- Availability
- Competition
- Cost
- Governance and Regulation
- Industry
- Integration
- Operations
- People
- Performance
- Planning
- Risk
- Security
- Service Levels / Quality of Service
- Solutions
- Sourcing
- Strategy
- Support
| Category | Items |
| Awareness / Education |
View More…
|
| Architecture |
View More…
|
| Availability |
View More…
|
| Competition |
|
| Cost |
View More…
|
| Governance and Regulation |
View More…
|
| Industry |
|
| Integration |
|
| Operations |
View More…
|
| People |
View More…
|
| Performance |
View More…
|
| Planning |
View More…
|
| Risk |
View More…
|
| Security |
View More…
|
| Service Levels / Quality of Service |
View More…
|
| Solutions |
View More…
|
| Sourcing |
|
| Strategy |
|
| Support |
View More…
|
No comments:
Post a Comment