All solution design is contextual. It is impossible to know the right design unless you know why you are designing. Therefore, ensuring you are clear on the scope of a solution is the first step when creating a solution architecture. In Wittij Consulting's People-Centric Architecture process, people are always the context. We design solutions for one and only one reason - to help people do something. That is why we start every solution design activity with this people-centric diagram: the solution user diagram.
Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.
TIM BROWN, EXECUTIVE CHAIR OF IDEO
You can learn about design thinking, including its history, at Wikipedia (of course) or educate yourself at the IDEO Design Thinking site. IDEO is largely credited with the modern popularity of design thinking. Our people-centric solution user diagram takes inspiration from the first 2 stages of the Design Thinking process:
In the People-Centric Architecture process, we talk to the users of the solution we are designing - whether it is a business process solution, a technology solution, or both - and create a visual presentation of the users and the actions they will perform with the solution. Through this exercise, we understand the functionality by identifying who needs it and why they need it.
While we use more formal notations for more technical diagrams, we use a simple box-oriented approach for the solution user diagram for a few reasons:
They look like Monopoly Cards1I am hopeful I am not dating myself with this reference!:
You title each card with the functional role of the user. The activities the user will need to perform with the solution are bulleted on the card. It seems simple because it is!
We call each card a "User Card." I know. Duh.
The title of each card is a functional role, not a department or organizational title. One hint is that functional roles usually end in "er." If you are experienced at use cases, you may recognize the functional role as being similar to a use case actor. This should only be the end-users of the solution, and should not include project delivery (roles required to create the solution) or operational (IT roles required to operate the solution). The only time you would include a developer or engineer on one of these diagrams would be if you were designing a development or engineering tool.
The bullets on the card are the actions performed by the user using the solution. Actions should be stated in use case naming convention. Use case naming convention is VERB + NOUN, with as few additional modifiers as possible. There should also typically be five or fewer bullets on a card. Remember, keep it simple! You can control the number of items by managing the level of granularity of each action.
Although it is a simple notation, it still offers plenty of options for adding additional dimensions of information. Here are some strategies we employ to add extra details. Always remember, however, that keeping it simple is essential.
Card colors. You can use colors to categorize cards. The most typical approach is to color the title of the cards to group the roles. We most typically use two colors in two shades each to group users.
Card Grouping. Cards can also be grouped using placement, labeled rectangles, or delineated columns/rows.
Font Styling. Title and action text can also be styled (bold, italic, etc.) and colored to indicated additional information. We sometimes use gray italic text to indicate a future action that is not currently in scope but desired in the future.
As with all diagrams, always include a legend describing your notation, including keys for any use of styles, for your audience.
We don't have many advanced techniques because the solution user diagram works best when kept simple. However, I sometimes use two types of arrows to depict relationships between roles on a solution user diagram.
You can use a dotted-line arrow to signify a transition from one role to another, with the label indicating the transition.
You can use an open-head arrow (like the UML specialization relationship connector) to show that one role inherits all the actions from another role. This is most useful when roles share many actions but also have a few unique ones. It is often more straightforward to understand if you repeat the shared actions in each card instead.
What *can't* you do with solution user diagrams!? If you said, "Dan, you can only create one diagram for this" (say it isn't so), the solution user diagram is what I would create because without clarity around scope, it is not possible to be successful.
No requirements. No problem. A solution user diagram is a perfect place to start to agree on the scope. You can then map the roles and actions to requirement categories, process models, use cases, user stories, or features.
Existing requirements. Not all requirements are created equal. Creating a solution user diagram is a quick way to make sure you understand a set of requirements (regardless of their format) and validate that understanding with others "in the know." I often find creating one for an existing set of requirements identifies gaps and inconsistencies in the requirements, so the diagram provides added value instantly.
Solution architecture. Ensuring a solution architecture addresses all the user needs and requires that the solution architect analyzes those user needs. A solution user diagram is a foundational first step to defining the solution by who needs it and what they will do with it. It creates a valuable inventory of needs, which you can use to identify architecturally significant use cases.
Process design. Solution user diagrams are not just for technology because not all solutions are technical! Creating a solution user diagram can also be the first step in process design activities. People always know who they are and what they do, so it is easy to elicit a baseline catalog of activities, then pivot to process design from there.
Any initiative. The solution user diagram can be a great tool to identify the scope for anything involving people, which pretty much means anything. I have used it in all sorts of situations, including understanding a new business area and getting started on a business capability model.
Expectations are the key to success, and understanding scope is foundational to understanding expectations. A solution user diagram is a fantastic tool for understanding scope because:
That's why it is step one in our solution architecture process. Give it a try. You can start simple and layer in more advanced practices as you build skill. If you'd like some help scoping a large, complex solution or getting your teams trained on doing this themselves - drop us a line!
