Design your solution
After separating the need-to-have from nice-to-have features, you can start designing your solution.
Consider a scenario where you've talked to your customer's marketing manager. You've learned about everything that this manager needs in the new system and have designed the entire system based on their needs. After you've demonstrated your new system, the other marketers are dissatisfied with the entire system because it doesn't help them in their work. The reason why this system won't work is because it's based on the needs of one user.
By only talking to one user rather than all or most users, you risk not getting the entire story. Designing a system for your users means that they need to be involved in the entire process. You can't design a solution based on only one meeting, build the solution based on your designs, and then deploy the solution for all users. For example, if you're designing a financial solution, but your users aren't accountants, you'll need to find a way to design a solution that all people will understand and use.
Your best approach would be to first determine the obvious categories of users and then talk to a few from each group. For example, some users could handle new requests while other users handle modifications. Each category of users could have different needs and methods that they use to accomplish their work, and you'll need to consider all in your design. Next, consider people who have been using the legacy solution for many years versus new hires who don't have the same experience and shortcuts. Each user can offer insights that will help you design the new solution.
Each Dynamics 365 app has business processes that it performs in a certain way. You can tailor each app to match many different business requirements. However, occasions might occur where a user's current approach to accomplishing a task won't be optimal to use with Dynamics 365. If you tailor Dynamics 365 to work, like how the user worked with their legacy system, you might need to do extensive customizations and custom development work. While it's ideal to minimize changes to how a user accomplishes their tasks, sometimes change is necessary.
For example, you've made a few changes to how a user processes their work, which results in minimizing custom development that's required. This approach would commonly be a preferred approach than designing for how a user previously completed their work. This example shows the importance of making sure that you look at a problem through the lens of a user and the lens of the business and the app maker or developer.
Your design should maximize the benefit from all three perspectives:
User lens - They want the design to be user-friendly and as close to how they've been performing their work.
Business lens - They want higher productivity and greater customer retention.
App maker lens - They want the least custom code to implement the solution.
By considering each perspective in the design of the feature, you might discover that the design has swayed toward the most beneficial solution.
Many consultants know that when creating new solutions, they'll need to evaluate designs with the users. Going through the solution designs one more time is cheaper than going through the solution's build once more. Make sure that you go through your solution with the users multiple times. Start by creating a basic design based on what the users have told you. Next, go through this basic design with your users and then update the designs based on the feedback that you get. You can repeat this cycle continuously until you have a good design that everyone is satisfied with.
You also need to consider the amount of effort that goes into implementing the design. Estimate all tasks and then determine what you can implement given the budget and time for the customer. This approach is often referred to as the triangle of project management. You can never change one side without affecting the other sides. If your scope is bigger, then the two other sides need to be bigger as well.
When designing a system, you need to be aware of the budget, time, and resources that you've available so that you can set a proper scope. These three can't work without each other, and they need to work together. If you have 25 resources who are working on a project, you can have a bigger scope if you also have a significant budget. You can't have a large scope if you don't have enough budget and resources to get that project done. If you need a new system by the end of the year, you'll need to adjust the scope and/or budget of that project. Even when designing your system to work for your users, you'll need to be aware of this factor. If one feature is critical for the users, then it needs to be prioritized. Designing for users doesn't mean ignoring budget, time, or resources. It means to create the best possible system based on the user's needs within budget, time, and resources.
To help make understanding the design easier for users, you can create fictional personas. Characteristics of personas are that they're:
A typical user.
Not an actual user but a fictional cross section from your users.
Fictional people whom your users can relate to.
Relating to a story in a way that your users will understand.
Another way of making sure that your users understand what you're writing about in your design is to use a scenario. A scenario uses the persona that you created and tells a story of what the different features will do. For example, a story of a day in the life of the Accountant might involve the following information:
Everything that the accountant does in a normal job as an accountant
An explanation of what tasks the accountant completes
The systems that the accountant uses
A scenario can also include the best-case scenario or the worst-case scenario. Your design will need to handle all different scenarios.
Finally, your design can include use cases. A use case is the story of how one person who does a specific process will achieve a goal. Returning to the Accountant, the use case can be about how they can send paychecks to all employees. Use cases help you decide and explain the important processes that need to be in a solution. Use cases help you decide what needs to be done. Your use cases shouldn't only be the ideal scenario, called the happy path. Instead, make sure that you create use cases for the happy path and alternative paths if something goes wrong. It's as important to plan for mistakes as it is to plan for situations to work.
When you start writing your design, you'll have several considerations. You need to write the document in a way that your users will understand. You don't need to complicate the design or use complex jargon that your users might not understand. Write the design document in the same way that you'll create the solution: with your users in mind. Your users should be able to read the document and find everything that you've previously discussed. No surprises should await the users in the design document. It's imperative that the users understand the design document so that they can give feedback about it.