
In the first part of this cheat sheet, we covered securing the right professionals, starting with an MVP mindset, and preserving existing solution strengths. This second part continues with equally critical but less obvious lessons: onboarding data analysts who understand enterprise data structures, planning for performance issues with large datasets, aligning decision makers early, delivering best practices users expect, and ensuring your design team is properly resourced.
Securing business support through subject matter experts is expected. However, bringing in someone who understands data structures proves equally important but less obvious. Every department typically has a person responsible for generating main reports for their unit. This individual possesses the most knowledge about available data in the company’s databases, knows whom to contact for specific details, and understands the cadence and timing of data updates. The value of having someone who knows where and how to source data cannot be overstated.
Financial databases store vast amounts of data, particularly transaction data sets. Most reports will likely rely on these large data points, which can lead to performance issues. Slow report loading times decrease user interest in the report’s value and increase frustration among project sponsors. To mitigate these issues, plan for performance challenges from the beginning. Aim for the fastest data rendering possible and insist on a scalable architecture that supports progressive data rendering. Setting up the architecture correctly from the start is crucial, as significant changes may not be possible later.
Gathering information to deliver a product involves various activities and methods. However, designing a working tool requires a different approach. It is crucial to obtain business approvals for the instructions provided to professionals within the business process created through the software product. Use strategic sessions wisely, as opportunities to get everyone on board with a new or updated process are limited. If all the decision makers are not in one room or their approvals not secured early on, significant challenges will likely arise. Ensure that key stakeholders are present and engaged to streamline the decision-making process and facilitate smoother implementation.
Whenever possible, implement standard design practices such as following user behaviour rather than imposing restrictions and incorporating extensive autosave features. Corporate users expect applications to perform with the same speed and ease as the most popular B2C apps. They won’t be concerned about your lack of resources or time to match the UX of mature billion-dollar products. Start by identifying the right type of interface and finding similar products. Market leaders have outlasted the competition and set the standards and expectations for your user base. By adopting their best practices and adhering to established patterns, you will align with users’ habits and save considerable time.
With the rise of design thinking courses, the popularity of UX checklists, and numerous available frameworks, many people feel capable of taking on the role of a software designer. This often leads to delegating design responsibilities to front-end developers or BSAs to save resources. However, while this approach might save on designer costs, it can result in developers having to redo poorly planned products and missed opportunities. Engineers tend to focus on frameworks they are comfortable with or that are trendy, rather than pushing the boundaries to meet user needs. Engineers are typically preoccupied with controls and data streams, causing user goals to slip from their attention. A good rule of thumb is to have at least one designer for every five to ten developers.