Here are eight basic steps I’ve found to keep the user in the process and build successful solutions when working with Business Analysts. (This is a mod. of classic 5 stage design thinking geared to the way BA’s tend to approach a problem)
1. Understand the problem
Describe the problem, not the solution. Make sure you understand the underlying problem; even if the direction given from the Product Manager is specific about the solution they want (This could include screenshots). Communicated solutions tend to be myopic in their approach; often the solution is a reaction to a specific symptom rather than addressing the root problem. Jumping directly into the solution space may not directly or fully address the underlying problem. To be sure the solution you design is complete you must understand the true nature of the problem.
2. Who is your user, your target audience
Personas. Draw upon personal experience and site visits to develop and maintain personas – both are key to understanding the nature of the people using your solutions. Personas help us anticipate and expose limitations and constraints users may encounter within their working environment. Also, use your personas to help developers visualize the solution in its intended context. Don’t have a persona for a specific user? – Host a persona workshop to generate them with your team.
3. Understand and document the workflow or process
Look to as many sources as possible when documenting workflows. Use this information to refine and identify the core or minimum information needed to get the job completed – often asking how users they do their jobs when the power goes out answers this question directly. Identifying the main user’s workflow(s) will serve to pinpoint functionality that is not necessary (The 20%), and later serve to simplify the interface. Remember, your Process Map should also include direct audience and customers. Be sure to document where the work came from, and who consumes it once it’s done.
4. Be aware of upgrade paths
Acknowledge and document all related workflows from previous versions. This includes any changes made to the current release going forward. Users will need to re-learn how to use the new version of the tool after an upgrade, and aside from the possibility of a bad experience, big changes can require extra documentation and training. The approach you choose should fit the overall roadmap for the product.
5. Understand the data
Yes really, data. You don’t need to understand data relationships as a DBA would, but you do need to understand data as it relates to the user’s process. Identifying required fields, parent-child relationships and what-drives-what information is crucial to keeping your approach simple and useful. Understanding the data can also help identify how your solution touches (or breaks) other areas of the application.
6. Keep it simple
Evaluate every feature for its relevance to the main simplified workflow. Identify the primary purpose of what you are building, and design to support that purpose. Be diligent to ensure that secondary actions are not forced into the main solution – as a rule of thumb; something that takes place twenty-five percent of the time should not typically be front and center. Tools work best when they address the problem simply – make sure that you are not trying to put too much into the solution. Keep in mind though you will likely need a method to include features for the 20% as well. (The Laws of Simplicity, offers an interesting approach to addressing the 20%)
Paper is cheaper than code. Anticipate large-scale changes when prototyping, be sure you are not making heavy time or code investments when prototyping by going directly from idea to code. There are many techniques for constructing prototypes that do not involve writing any code at all, often a storyboard or a wireframe is enough to visually walk through the workflow and communicate your ideas. The medium of your prototypes should never be what limits the number of changes you make.
8. Review and iterate
Iterate using feedback. Customer-based feedback is great when you can get it, but often it’s not possible. If you have no access to actual users, leverage your peers (using the personas) to iterate your designs. Include your whole agile team in the review process. Be sure to use the feedback process to help verify and maintain the simplicity of your design rather than as a forum to add in bloat.
Be prepared to go back to any of the previous steps and rework any or all of your original ideas.