In a previous post I wrote about some of the reasons why enterprise software is so notoriously hard to use. Here are my 3 recommendations that product managers can act on immediately to start making a change.
1. Define Your Evolution Path Based on Rigorous User Research
Do you know what specific aspects of your user interface would yield the highest ROI if updated? Often it’s the usability and flow of screens like dashboards and main pages that users interact with on a daily basis to accomplish primary tasks, or the overall “Wow Factor” of the application that will attract new clients. The only surefire way to discover this information is to conduct the appropriate user research. Proven research should guide the evolution path, not just internal stakeholders, user forums, or large-scale surveys.
Who Are the Primary Personas for the Evolution of the Product?
Enterprise Software systems are often large and complex because they serve too many types of users — sometimes 20-30 different groups — without prioritization. As a first step, clearly define User Personas, and then use this information to select the main targets to guide the product line. Don’t forget the mobile and SaaS versions!
As Steve Johnson points out in Buyer and User Personas, you’ll often find that some features have been designed for Buyer Personas — procurement managers, CIOs, and so forth who do not actually use the software once it is purchased. While it’s important to be aware of these personas, a product line’s evolution should focus on people actually using the system.
Make Part of Your Research Observation-Based
Talking to end users is necessary to glean true customer insight, but it’s not enough by itself. You need to put the ideas you get into a wider context by using data from other research techniques, like observational research. Proven user observation techniques are the key to discovering the differences between what users say they want and what they actually need.
Don’t Reinvent the Design Wheel
Current industry leaders have shared many standard design and interaction patterns. While this is no substitute for User Experience professionals and won’t help you innovate beyond the competition, they are a fundamental starting point. SAP, for example, shares their knowledge of problem/solution patterns they encounter in ERP. Oracle and Endeca have partnered to build a large set of UI design patterns for BI and Analytics systems.
Consider What Will Happen if You Don’t Change
You should consider the risks of evolving your product, but also factor the risks of not doing it, into the equation. Staying with the status quo might look like the safe option, but if you want to grow your user base, not updating might be the bigger gamble. Don’t guess at good design or leave product management to chance.
2 Get A Technical Analysis To Determine Your Options
One of the biggest constraints product teams face is the existing code base and software architecture. The code base is often a tangled mess of legacy “spaghetti” code, silos (separate tables that can only be retrieved independently), and most recently stateless protocols that are not aware of what is happening in different parts of the screen. All of these architectural structures served a technical purpose over the evolution of the product, but all are now hampering the improvement of design and usability.
The plan you put together to evolve this code base is critical. It will affect timelines and costs for feature or design updates, and migration to new platforms such as SaaS and mobile.
Assess Your Ability to Develop an API
One of the first things your team should look at is the ability to put all the system’s business logic into a separate code layer and wrap it with a clear APIOnce you have a well formed API, it can power new features, design changes, and extensions of the product onto new platforms.
This is easier said than done. For example, often the UI code is intertwined with the business logic. If you have a Unit Test framework or automated test framework, this is where the investment will pay off as you evolve the code towards a more structured format with an API.
Put together a plan to present to upper management:
- Find the pieces that can be isolated. Could you build an interface on top and keep them?
- Have PMs work with a UX designer to prioritize the usage scenarios most critical in the evolution of your software. It’s possible some features will not be a priority, and the supporting code could be dropped altogether.
- Identify the scenarios first-time users need. You now have a minimal feature set for the 1.0 release of your next generation system. That scope will be easier to manage, and if you start with only new customers, migration of legacy data will be less of a concern. You can come up with data migration tools later.
- Replace stateless patterns with code that is aware of what is being displayed. This will result in a more maintainable system than hacking it progressively to satisfy individual design tweaks.
- Consider the future of in-memory computing, like SAP’s HANA program.
The new system should be designed with most of the code being a common API. This allows you to keep desktop, web and mobile clients as thin as possible, minimizing the investment per platform.
3 Get Your Product Managers, Designers, and Developers Working Together As One Team
For any software organization serious about competing in the shifting Enterprise market, the biggest key to success is getting the right design, product management, and development competencies working together as one team with a common goal — amazing software that doesn’t just aim to be first-to-market, but best-to-market.
Poor software execution is often the result of structural and process-oriented problems. If you’ve got a major redesign or new release in the making, these struggles will cost your organization time, re-work, and missed opportunities.
Communication Accelerates Success.
Software leaders like Apple, Facebook, and Google can afford to use hundred page style guides and detailed design docs but most organizations don’t have the time or budget to write such a detailed guide. In our experience, the fastest, most cost-effective and most efficient way to ensure the final design looks as great as what the PM and designer envisioned is to communicate as one team.
Daily, detailed communication can only happen when all stakeholders are included as part of the team. Daily team communication ensures:
- Product strategy and design intent are maintained throughout development.
- Designers can quickly explain complex interactions verbally, eliminating the need to draft diagrams to encapsulate every detail.
- Developers get the answers they need to stay on track and communicate technical roadblocks.
Working in Parallel
The first generation of software planning processes were termed “Waterfall” and have been severely derided for heavy, time consuming, and wasteful. The second generation took on various forms of “Agile”, where many teams abandoned upfront planning and jumped right into short sprints or iterations.
What we’re seeing now is the emergence of a third generation involving just the right amount of upfront planning, followed by all team members working in parallel. There are a couple of reasons functions can’t “take turns” sequentially designing and building a product:
1. The steps are not sequential. Designers need to test that a design is working over the course of development. PMs need to adapt requirements as they get updated competitive data.
2. Designers need room to be creative, and that means the ability to fail and iterate.
3. Part of success is releasing in time to capitalize on a market opportunity. Working in parallel with daily communication is much faster than working sequentially.
- This post is part of a full-length whitepaper, Has the Usability Revolution Left Enterprise Software Behind?
- For details on how teams can communicate effectively together and work in parallel, see our paper How To Get Amazing Software Out The Door Fast.
About the Author
Didier Thizy has been a software professional for 13 years, holding a variety of positions in Software R&D and Product Management.
At Macadamian, Didier is Macadamian's VP Consulting, responsible for a cross-functional unit of design and development consultants specializing in healthcare software. His focus areas include healthcare software, usability of complex systems, and modern mobile and web technologies.
Didier is an active member of HIMSS, the Toronto Product Management Association, Silicon Valley Product Management Association, and the Ottawa OCRI association for technology.
Follow on Twitter