Designing a SaaS application that can sustain growth, deliver new services, and establish on-going customer relationships, requires bringing together several levels of skills: experience, innovation/creative , and empirical/validation.
- Experience refers both to know-how regarding interface design and human behavior but also to understanding the unique demands of SaaS delivery and how it impacts the entire customer life cycle.
- Innovation is something I have touched on before.
- Empirical is about using data to understand how users/customers think and behave.
Empirical also means using data to build consensus and get beyond biases that we all bring to the table.
Biases that skew design priorities
One bias common to everyone, from UI architects and UI designers, to CEOs, product managers and development teams, is the availability heuristic - "if you can think of it, is must be important". Basically, stakeholders skew the importance of a feature/workflow scenario based on how easy it is to think of an example of someone (possibly themselves) who would use it.
The "typical user" we each know
It's common to be in meetings where the CEO of a company was just browsing a website that had feature X and so now thinks "users" of their application will need X. Or to find a product manager who clearly remembers an an email complaint about a product at his previous company and now makes the statement "users want Y". Or a UI architect who just worked on a mobile project and thinks that all "users" distract easily and can't focus on tasks. Or a visual designer that is really designing for one user they know really well - themselves.
The availability heuristic as a bias in application design is ubiquitous. One impact is that it can impede building consensus among stakeholders around what features to implement and the order in which to implement them. Fortunately there are a number of tools we use to reduce these biases and produce actionable information that maps to bottom-line profitability.
Distilling behavior patterns
Personas is one of these tools. In simplest terms, a persona is a distillation of a behavior pattern into an archetypal character. Personas tell you what people care about, what they do. Every SaaS application will likely have several personas. These might represent different demographics, different market segments, different work roles, different experience levels, or different conceptual models of how things work.
What a user wants to accomplish (behavior) and how they want to feel (emotion)
Personas are derived both by looking ethnographically at very objective behaviors and then seeing correlations that distill into a behavior pattern, as well as by observing how users "feel" (e.g. secure, confident, delighted, engaged, exploratory, etc.) and modeling these into a pattern. These data-derived behavior/motivational/emotional patterns are converted into characters, with a photo and name (e.g. Joe, Veronica) so that they can take on a life of their own, be empathized with and define the boundaries for the application design.
Disambiguity and prioritizing release cycles
Deriving personas is not some touchy-feely, creative writing exercise. but rather an effective way for design AND development teams to focus attention, remove bias and examine usage contexts and the opportunities they present. Instead of teams asking "How would I use the software" or "How would 'a user' use the software", they can ask "How would Joe use the software", "How would Veronica use the software". This reduces ambiguity and "squishy", "elastic" users. Proposed feature and design assertions can now be tested and validated against more closely defined user characteristics and goals.
We put these personas to work in scenarios in order to elicit key requirements that serve as the initial roadmap for application functionality and design. We can also plan priorities for SaaS release cycles. For example we might say: "Here is management's presumed list of 10 must-have features. But the personas that are the most important to our market, won't really care about features 3,7, and 9. So maybe we delay these features until the next release cycle."
Personas are just one in a toolbox of UX tools we use to remove bias, build consensus, identify functionality/design opportunities and tailor the SaaS environment to various user distinctions where the differences will have a meaningful effect on services and where service differentiation makes financial sense.
Categories: SaaS, User Experience