Because Smartsheet gets kudos for its usability, I often get asked about how we decided on the fundamental design of the product. Keeping an application "easy to use" sounds simple enough. But when you've got powerful features, it's anything but. Believe me, the process was painful and made us question everything we thought we knew about software design-- but ultimately led us down a good path. For those interested in what we experienced, read on.
Under the best of circumstances, building an online business application capable of selling itself without human intervention (sales) is tough. Try it in a category like project management that has resisted a killer app for over 30 years and it's nearly impossible.
So what do you do when you know you have the right plan, core concepts and approach, but the people trialing your product just don't quite 'get it' often enough? You do what we did at Smartsheet. You swallow your pride and sunk costs, realize that it's you that doesn't 'get it', and you start over.
Well, not entirely over. By the fall of 2007, we had amassed 2 years worth of customer behavioral data, feedback, and usage patterns. The data strongly suggested we were in the ball park with our designs, but that they were still a little too complicated for the users. Turning "in the ball park" into "hitting it out of the park" would require the application to behave exactly to the customers expectations. Here's what we did:
1. Tighten the Definition of the Customer
We re-introduced ourselves to our intended customer. With the help of Tamara Adlin from UX Pioneers, we defined the personas of the people we expected should be buying our product. In our particular case, our key persona was named "Sandy". In a nutshell, Sandy was the 'go to' person inside her team, office or company.
After diligently whittling a couple hundred characteristics and attributes down we determined that she typically manages several projects with many moving parts. She coordinates lots of people, with many of them outside her company or group and therefore outside her control. And, she manages a diverse set of work that makes it difficult to find a one size fits all tool, so she usually relies on email and spreadsheets. These characteristics make her the president of a small business, the product manager in a large company, the executive administrator managing four VPs, and so on. Our product needed to make her life a whole lot better.
2. Design the Customer's Expected Experience
The customers using Smartsheet loved it. However, the period of time between first signing up and full utility was our killing field. In other words, once all the work being managed was structured in Smartsheet correctly, it was better than anything they'd previously used. Getting to that point was the trick.
We recruited a bunch of Sandy's to come in and use our app starting at the signup stage. They talked out loud as they attempted to set up a project and include their team members. This exercise shined a spotlight on why some of the most useful features weren't showing up in the usage data. Sandy's expectation for how things "should work" didn't map to our navigation. For example, she had to go "set up a user" before she could then "assign" a task to someone. She just wanted to type the person's name in, and often just the first name, and move on.
There were too many features competing for attention and too many concepts to learn to be effective. It was clear that core concepts were right, there were just too many of them.
3. Simplify the Design and Bury Features into the Application Behavior
Radically simplifying a feature rich application was a daunting task for a group of former enterprise software designers. Again, we needed some outside help, a set of fresh eyes that were good at complex problems and UX. Enter the JacksonFish team of Hillel Cooperman and Jenny Lam. With Hillel's help we wireframed a 67% reduction in core concepts, menus and workflow steps. We threw out a whole set of our former conventions, and ended up with a design that retained most of the key features, and they mapped to Sandy's way of working.
Jenny took the wireframes, and our description of what we wanted in a user experience, and she made them come alive graphically. She helped us meld features into the behavior of the application so that simply navigating about the app coached the user on utility. For example, entire rows subtly back-light as the mouse travels over them to signal that Smartsheet is about rows, which differentiates it from classic spreadsheets that are about cells. We successfully packed in the features without punishing the user.
See Evolution of the Smartsheet Brand here
4. Don't Compromise User Experience to Minimize Technical Challenges
We'd intentionally prevented the software architects from influencing the designs based on what was possible technically. This had tended to force the application away from Sandy's desired experience, and so naturally, some of the new designs didn't lend themselves to traditional software architecture. Some of them in fact were very difficult, but we held fast to the mantra of "not letting user experience be impacted by constraints in technical architecture". For example, Sandy commonly wanted to put text like "TBD" or "waiting on Mary to determine" into columns that had been designated for due dates. Allowing Sandy to type anything at all into columns that designate things like assigned to, due date, and status, makes it very difficult to code up a dashboard that shows things like "what do I have on my plate next week".
As it's turned out, the eventual solutions to some of these tough technical problems have become the foundation of what's made Smartsheet so versatile. New features and integrations can be added in days and weeks. As our CTO is fond of saying, "When things are designed correctly, new ideas and features just seem to always fit like they were intended to be 'right there' all along."
5. Make it Easier to Get Started
Most of our customers come to us because they are trying to solve a particular problem. They need a simple sales pipeline, or a marketing campaign management tool, or an easier to use Gantt chart, and so on. We match that intent with a preconfigured version of Smartsheet so that it feels like the answer.
How'd it all work out for us?
The product we launched the company with fared well. It won best of show in 2007 at Under the Radar and was well received by customers and analysts. It just didn't have explosive growth. The Re-designed version did! It took a few months for existing customers to convert to the new version and a renewed marketing push, but as those things took hold, paying customers took off.
There is no rocket science in the list of steps above, and likely nothing terribly new. In fact, we conducted many of the same steps during the maiden version of our product. The difference in round two was the quantity of actual usage data we could incorporate, and the addition of excellent specialists into parts of the design process. We're fortunate that our initial design was good enough to afford us runway for round 2.
- Brent Frei