I can clearly remember the first ever sign up to my HR SaaS project - it was a small company in the UK with about 10 employees. What a thrill that was. Over the next couple of years, we signed up more companies of even greater size, until we got a pretty good base of customer companies that were around the 100 employee mark each, on average.
Until this month, when we landed a deal for a major UK manufacturer with over 1000 employees! That was a 10x jump on our average customer size. Yikes!
Now, initially, I wasn’t at all worried. I am a tech guy by nature, and had designed my SaaS from the ground up to be scalable. We have multiple load balanced servers, replicated data stores, separate queueing services for background tasks etc. This wouldn’t even have caused a small sweat on our hardware infrastructure.
However, a designer I am not, and I quickly realised that our actual user interface would struggle under such a vast amount of user data.
Let me give you an example. On the main dashboard of our HR app, when the user first signs in, there is a little widget which show all the upcoming birthdays for your staff. It actually shows you all birthdays for the past 7 days, and the next 14 days coming up. This helps the HR manager to plan for office parties etc. or to send greetings out to the team.
Now, in a company of about 100 employees, this list really never grows to more than about 7 or 8 people on the list at any one time. This makes the widget a nice sized box on the page that stays ‘above the fold’ on a single page. Everything else on the dashboard fits around that quite well.
However, after we finished assisting the new company to upload all 1000+ employees into our system, I was horrified to notice that the birthday list was about 60 employees deep. In fact, the law of averages say that in the 3 week time span that the widget shows birthdays for, there will be an average of about 58 employees on it at any one time, in a 1000 employee company.
This made the widget overly tall, and pushed everything down the page. Users would have to scroll down quite a way on the page to see other critical dashboard data. Oops.
I learned the hard way that test data and expectations of low to medium data volumes had dictated some pretty serious limitations as to how I designed the widgets and most of the interface in general.
Thankfully, we have some great designers on my team now, and we put our heads together to work out how to best resolve this issue. We could
Dynamically reduce the number of weeks spread for the birthday list depending on the volume of employees in a particular company
Let the customer specify the date spread to show the birthdays for, or
Set a hard limit on the number of birthday that we would show on the widget and show only those close to today’s date
All of these were discussed and dismissed as being a bit too limiting. After all, our other users loved this widget and frequently told us how it helped them to relate to their staff better.
In the end, we went with - incorporating a mini scroll bar within the widget. Anything up to 10 birthdays on the list and it would show like it always did (so therefore no difference to nearly all our other customers). More than 10 on the list and the widget would peg itself to 500px in height (which still fits on most screens), and a little scroll bar would appear on the right of the widget allowing the user to scroll down the list of birthdays.
My rule #1 for interface design is “Don’t change anything that customers would be already used to unless it is absolutely necessary”, and I think this design choice fits that well.
So far so good with this new customer, as they seem to be loving the system. We will be working closely with them over the next few weeks to ensure that all other elements of our interface are capable of handling 10x the data presentation that we are used to.
How are things with your SaaS? Have you come across similar situations? Or were you smart enough to design ‘defensively’ and cater for these sorts of edge cases?