Excel to Interface: A Strategic Approach to Transitioning Users from Excel to Custom Applications
When starting out in product design, no one ever tells you how much time you will spend looking at Excel spreadsheets and translating them into interfaces. That doesn’t even begin to cover getting your users onto their new application after spending their careers learning the intricacies of the database. Transitioning users from Excel to custom applications can be a complex process that requires careful planning and consideration. As a UX designer with a core base of Excel power users (who are more than hesitant to be separated from their spreadsheets), here are some important things to consider before you move your users from Excel to interface.
1) Why are we moving users off of Excel?
The user needs and business needs will tell you a lot about design requirements. As a product designer, it is important to align those requirements with the capabilities of both Excel and the new product you might be creating. If users already feel comfortable with Excel, what are the benefits and drawbacks to moving them to a new interface? There are a limitless number of reasons (data auditing, consistent data entry, cross data source comparison, etc.) why the idea of moving users off of Excel may seem like a great decision, but there are also reasons why Excel has worked for users for so long (mainly the versatility and flexibility around data manipulation). You need to balance that. Sometimes, the answer might just be to stick with Excel. Sometimes, it’s not. This question can help you look at the bigger picture and make sure your efforts are being directed in the best way.
2) What Excel features are my users currently using and why?
If you are rebuilding Excel and all the things it can do into your application, then something was missed while you were gathering requirements (and if users really do need everything then there is a strong case for sticking with Excel). By breaking down the features that are used at any given step of your user’s process, that can help you pinpoint what they actually need to accomplish and what a digital application can do to support them. For example, if you have a user base that relies on pivot tables, you might not need to build in formula functionality. Building extra features just because they exist in Excel is not the best way to support your users and may be a waste of time and money. Remove the distractions and focus on what things your users need to accomplish their goals. Otherwise, all you are doing is overwhelming your users, annoying your developers, and costing your company more money (yikes!).
Also knowing why your users need certain features can guide your design decisions. While standard databases might be familiar to users, it might not be the best solution. It is up to us, as designers, to find the right solution even if it might not be the most comfortable. This is where user research can really make the difference between a functional product and a fantastic solution.
3) How are we going to move users from Excel to the new interface?
This often gets overlooked with the excitement of a new application. We are so happy to have launched the thing, we forget that our users haven’t spent as much time with it as we have and now they need to learn it. Whiplash like this can leave a bad impression with users and hurt your adoption rates and user trust.
Maybe you need to ween users into an application with bite sized releases. This allows a user to get familiar with core features and navigation before they have to fully rely on the new application. This also helps with engaging users in feedback, which is a constant struggle in the enterprise space. If you are dealing with a lot of data, releasing a dashboard that helps to summarize the data can show users the benefits of the application without making them feel forced. By lowering the size and stakes around a release, users will feel they have more time to play with the application and start building habits around using it.
You can also try a hybrid approach that lets them fall back on excel as they are learning and building trust with the new application. I find this works very well for applications that know they will have a long development process because it allows users to keep doing their work, in and out of the application, while being less affected by updates and bugs that might become roadblocks. It also gives them a way to step off the application and keep working while the product team keeps building, which can sooner show how the project has added value to the business to the people paying for this new product.
Often users see moving to a new software as the need to start over. It is our job to make sure they don’t throw the baby out with the bathwater. There are many ways to build that trust into your application beforehand, you just have to take some time to think it through.
4) Excel can do it in one screen, maybe your application can’t.
Hear me out, Excel deals with a large amount of data, that users are constantly able to manipulate and view in different ways. Is that the best flow for your users? Or has that lead to a bad case of cognitive overload that your users don’t even realize they have? Knowing the why behind user actions can explain the reason they do what they do in their databases. It also allows the designer to separate these actions in order to build better user flows. I find that separating features into different steps within a flow can not only help reduce how overwhelmed users can get, but can also help with processing times!
Knowing what metrics you want to improve and are using for benchmarking can really help when you need to make this decision. For example, when dealing with thousands of rows of data in a spreadsheet, how much time does it take for users to double check and clean up their data? If you can chunk up what users see for each step, then there will be less distractions and less places for accidental key strokes. From an outside perspective, it may look like users are going from one step to ten steps, but if that increases data accuracy and helps focus users on the task at hand, then that is a win.
5) Where does the data go?
Once your application is launched, you’ve gotten feedback, and started working on your backlog, that is the last your users will ever need to look at Excel, right? Wrong. There are so many reasons why someone may need to look at historical data, whether it is used in your users’ process or simply for company-wide auditing purposes. There will always be a need to go back, so it is imperative that we think about how our users can do that. For some companies and situations it might be as simple as saving it to their corporate cloud storage (Dropbox, BOX, etc.).
Personally, I like to see how the data can be saved and used to make the new application even better. Your users have already done all that work, it seems a shame that it will just get shoved into someone’s Google Drive never to be seen again. Can your application use that data to learn and help better automate your user tasks? Can that work be used to compare year-to-year results to better guidance on future business decisions? Can it become a training sandbox that utilizes real world scenarios?
These possibilities may not be top priorities, but I can guarantee that data and information security is going to be a top priority for any company. It is always important to work with your business and product team to give past spreadsheets the rest in peace they deserve.
Excel (and other spreadsheet applications) will always reign supreme as the most versatile and flexible data processing software. As UX designers, it is important to recognize the intricacies of what tools our users have in their toolbox and why they have chosen them time and time again. It is by no means an easy feat, but thinking through these points can help you make intelligent decisions around getting your users off of their standard data spreadsheets and into more functional and efficient data processing applications.