The fun thing about being a consultant is that you get to work with lots of different teams and lots of different companies. And that means you get to work on very different types of problems. With that in mind, let me tell you about my week.
I was coaching a firm that provides HR expertise. They have a number of different services and information resources, but in the end their value proposition is that they have knowledge that will keep you, the small business owner, out of trouble. Which makes for an interesting design problem: if your value is something so intangible, how do you package it and sell it to your customers?
Since I was coaching them through Contextual Design, customer data was part of the answer, of course. We tell people that you can design anything you like with Contextual Design—as long as it has a customer—and it’s true. But most of our clients are either designing a tangible product of some sort or designing an internal business process. This team needed a much broader solution.
So when we started to vision our design solutions, the team didn’t just vision software solutions. They envisioned services, processes for delivering those services, procedures, marketing plans, and communication mechanisms—as well as internal and customer-facing software systems to support all them all.
Which presented a challenge for the next phase of the project. A software system we can design and describe using the User Environment Design (UED). How to define these other elements of the vision? We needed to provide enough detail so the business could see the impact—could see what they would have to put in place to deliver these new services.
To deal with this, we designed a method to define services based on contextual data. For this company, the service description included the following:
- Service descriptions. Each service got a title, a short descriptive summary, then a list of the roles required to implement that service and the parts of the online system useful to support the service.
- Process definitions. Each new process that was part of the vision was described. Elements of the process definition were a title, short description, and services supported by the process. Then the process steps were described, each step including the roles involved in performing the step, the system support used by the step, and the documents needed for the step.
- Roles. Each new role created by the vision was defined. Roles were given names, descriptions, the services supported by the role, key skills required to perform the role, and primary activities of the role.
- Documents. Each document required by the vision was summarized with name, description, and required contents.
What this allowed us to do was to define the service and process elements of my client’s vision at a high level. The client could easily see what new roles and skills they would have to staff for; what new documents would have to be created; and what processes would have to be defined and implemented to enable the services we had envisioned.
We normally use user data to design products, or systems, or web sites—but the data is much more powerful than that. No product or system stands alone—bring in the right people and the data will help you design processes, services, marketing messages, and all the support structure you need to make your system successful.