SaaS User Experience (UX)
What is UX?
Before getting started setting up UX processes, it is important to know what UX is, how it works, what processes are used, and what the end result aims to be.
PROTIP: It doesn’t matter great your tool is, if your users can use it you’re probably going to fail. So we must build a system with great UX.
UX is a value delivery system
Software systems do one or both of two things. They either save time, provide knowledge, or both and UX is the process of delivering that value. The value of a product, especially when compared to its competitors, is dependent upon its ability to deliver this knowledge or time savings, and the delivery of this information encapsulated within the user experience.
Like a well-built yacht, nothing in great software is extraneous. Everything has function and is crafted meticulously. Through the combination of function, craft, and art, paired with the experience of use, beauty is created.
A strong focus on UX is core to the success of any digital product with a user interface that is used on a regular basis.
Implementing UX
The process of implementing great UX is the process of questioning every aspect of a system.
This includes every button, every line of text, every shape, every size, every color, every space, every action, every state of every element, every process, and action a user takes for every kind of user within a system. This is done by analyzing every step critically, understanding the priority order of every element and every feature, and having a deep understanding of how people use software systems and processes.
The knowledge of how users flow through systems is not based just based on intuition, it is based on evidence and a study of usability. UX designers go through the process of understanding the needs of users more than those users understand it themselves and delivering a system that meets these needs in ways that customers often cannot express. Product deliverables are based on the specifications, data-driven decisions, critical thinking, intuition, education, focused training, and experience.
Statistics on the impact of UX
The list below was mostly pulled from this blog article.
ROI of Good UX
Research shows that, on average, every $1 invested in UX brings $100 in return. That’s an ROI of a whopping 9,900%.
The top companies leading in user experience outperformed the S&P index by 35%.
A well-designed user interface could raise your website’s conversion rate by up to a 200%, and a better UX design could yield conversion rates up to 400%.
If you utilize UX design to satisfy enough people to boost your customer retention by as little as 5%, you will be rewarded with a profit increase of at least 25%.
A 2016 design study of 408 different companies found that the more a company invested in and focused on design, the more sales they saw.
23% of customers who had a positive experience told 10 or more people about it.
When UX improves the customer experience, it raises a company’s KPIs up to 83% in conversion lift.
8 in 10 customers are willing to pay more for better customer experience.
Walker’s ‘Customers 2020’ report revealed that, by 2020, customer experience will overtake price and product as the key brand differentiator.
According to a report by Forrester, sites with a “superior user experience” can see visit-to-lead conversions up to 400% higher than those without.
A study by leading research and consulting firm Temkin Group revealed that 84% of companies expect to increase their focus on customer experience measurements and metrics.
Cost of Bad UX
70% of customers abandon purchases because of bad user experience.
67% of customers claim unpleasant experiences as a reason for churn.
91% of non-complainers just leave and 13% of them tell 15 more people about their bad experience.
Slow-loading websites cost retailers more than $2B in lost sales each year
62% of customers say they share bad experiences with others.
79% of people who don't like what they find on 1 site, will go search for another site.
UX Business Cases Stats
Jeff Bezos invested 100X more into customer experience than advertising during the first year of Amazon.
AirBnB’s Mike Gebbia credits UX with taking the company to $10 billion.
MacAfee saved 90% in expenses after integrating usability testing to learn more about its customers and their needs.
8% was the drop in sales incurred by Marks & Spencer after spending $220 million on their website redesign
User Testing Stats
85% of UX problems can be solved by testing 5 users
Only 55% of companies are currently conducting any UX testing.
There was a success rate of 80% when people used the navigation scheme structured according to most users’ mental model.
There was a success rate of 9% when people used the navigation scheme structured according to the company’s internal thinking
UX Design & Development
Fixing an error after development is up to 100x as expensive as it would have been before development.
94% of the factors that affect a user’s 1st impression of your product are design-related. These 1st impressions are extremely important, and unimpressed users are often unforgiving.
Investing in UX during a project’s concept phase reduces product development cycles by 33 - 50%.
Developers spend 50% of their time reworking projects because of poor UX.
Judgments on website credibility are 75% based on a website's overall aesthetics
83% of people say a 'seamless experience across all devices' is very important
Almost 40% of users will stop engaging if they find the content or layout of a website or application shabby
Video helps persuade 73% of people to buy a product or service
Visit-to-lead conversions can be 400% higher on sites with a “superior user experience”.
When a SaaS isn’t easy to use
If a SaaS system isn’t intuitive to use, for the most part, people won’t use it.
Even worse, a lot of times when SaaS users leave, they don’t tell you why they’re leaving. They just don’t renew their subscription, bow out, and disappear into the anonymous gray of the internet.
That’s not altogether terrible, seeing as how you don’t have to actually deal with them when they’re upset. But when they don’t tell you why they left, what they got frustrated about, or what they didn’t like it means you don’t know how to fix it for other users. Sometimes it’s price, sometimes it’s that they’re not using the system anymore, and very often it’s that they got frustrated about the use of some system because they couldn’t figure it out or it took too long to load and just decided not to use it anymore and left.
What do UX designers do?
In addition to actually creating designs, designers do a lot of things and bring a lot to a product team. Below is a list of some of the duties of a UX designer and the things they must consider when building a product:
Views and functionality differences on mobile, tablet, and desktop not just in the use of the system, but in the use of the device.
Competitor analysis
User interviews
Behavioral data analysis
Heatmap and usage analysis
Product market fit & product validation
Benchmarking
Heuristic evaluation
Cognitive walkthroughs
Conversion oriented evaluation
Content audits
UX reviews
User testing
A/B testing
Qualitative and quantitative interviews
User surveys
Card sorting
Eye-tracking
Lean product experiments
User onboarding and user activation
Navigation. Navigation. Navigation.
Multi-channeling
Animations
Spacing
Aesthetic-usability effect
Gestalt law of proximity
Performance and non-functional specifications
Content
Content distribution
Content readability
Typography
Content structure
UX copywriting
Information architecture
ZMOT - Zero Moment of Truth
Accessibility Compliance
AND SO MUCH MORE
UX designer information requirements
When working within an agile process to create an Iterative design process, a UX designer generally relies on the following data points:
User types
System architecture
Goals for the system and features
User flows
System elements
System usage analytics
User stories
Team and user feedback for iterative design
What to expect working with a UX designer
A lot of questions
To have ideas challenged
Feature ideas to be generated unexpectedly
To produce a great user experience and have happy customers
Information requirements for UX
These are the questions that a UX designer will often ask.
User types
Who are the users?
How are different user types different?
Why are different users using the system?
What are the primary uses of the system for each user type?
What are the different user types trying to accomplish?
System architecture
What are the variables used in the system?
What data points need to be viewed, entered, and/or extracted from the system?
What is the priority of each data point and why?
How do data points fit together with other system features and what is the priority of those data points in other features?
Improvement goals
What is the goal of what we’re doing?
Why are we improving this system?
What user type or types does the improvement apply to?
How will their experience be improved?
What are the quantitative and qualitative measures of success in this project?
User flows
How does a user flow through the existing process?
In what ways can this process be improved?
What data is available to examine existing user flows?
System elements
Are all elements necessary?
Can any elements be simplified?
Can any elements be removed?
Are system elements in ordered correctly?
Do top priority elements have the appropriate visual signaling to impress their importance?
Are elements easy to see and understand?
UX Designers need to know as much as possible about how the entire system works to make the best decisions, so at the beginning of a project, there are very often more questions than answers. But this is in order to make the best system possible.
Notes on Working with UX designers within development teams
User stories for designers vs developers
This may be one of the biggest differences that are not clear for Product Owners (POs) not used to working with designers. Designers are the problem solvers, not just the implementers. So stories should often be substantially broader and state the problem and expected solution, not necessarily the method of delivering the solution.
Story writing for designers
When writing stories for designers, the following items should be written:
User types involved in the story
Goal for the users
Save time
Easier usage
More intuitive design
More or different information
Etc.
Expected solution for users
Success metrics - very often the same measure as goals with the addition of clear measurements.
Information architecture
When writing architecture for designers, it is recommended not to explain the location of elements, just what will be on the page.
Elements should be clearly explained with the expectation that the designer may recommend through their design other methods of accomplishing the goal.
When development specifications should not be modified, it is important to note to the design that this is the case and not to stray from the architecture. Although, if this is the case, very often a designer is not necessary.
Benchmarks
These are examples from other applications that can be used to show what the story writer is trying to accomplish. Having a benchmark is an easy way to create a point of reference without actually designing anything.
Often times, the designer can be asked to help find benchmarks ahead of designing the system and present these back to the stakeholders or story writer. However, benchmarking is a time-intensive process and should not be overused if resources are constrained.
Design process timing in relation to the development
Very often, these broad user stories will be delivered to the designer months or weeks ahead of development and the designer will create variations of potential solutions to the problem which will then be reviewed by product owners, customers, and other stakeholders. These solutions will often go through multiple iterations before they are ready for development, where the product owner will write a set of stories that accompany designs.
PROTIP: Very often, the velocity of the team is elevated further by implementing a front-end development team that takes the UX design team’s work and develops only the interfaces while the ‘back end developers’ build the logic and database systems to implement the solution.
UX Design may be timeboxed
If you're not familiar with the term "Time Boxing" this just means that the activity is done within a certain amount of time, for example, a two-week sprint.
Designers don’t like being timeboxed any more than other production team members, but design too may be timeboxed. As long as incomplete stories are noted and forthcoming changes are checked with product owners and developers, timeboxing may be applied. It may seem apparent, but it is also very important to inform your designer that they have a set time to complete the task and to ask them if the allotted time is enough to complete the task.
Copywriting is part of UX
Explanation text should be built into the system that simply and concisely explains how to use systems, what features do, and what the outcome of an action will be. This can be a surprisingly large amount of text, and subject matter experts will be required to deliver this text clearly.
Product delivery delays due to UX team
Very often, UX designers will implement ideas into their designs that stakeholders, including customers, get attached to. This can cause friction in the product team because the ideas are good, but the team cannot implement the functionality due to time or money constraints. Product owners must be vigilant about this issue and balance the wants and needs of users.
Stakeholders
Stakeholders are often the product owner, company leadership, sometimes customers, and other team members. Within substantially complex products, it is important to have subject matter experts who clearly understand the customer needs to be involved at every step of the UX process, especially during the planning and iteration on designs. Like any other build team member, a UX designer benefits from being a subject matter expert, but they don't need to be one, so long as a subject matter expert is available to assist.
Stakeholders Meetings
Stakeholders in the design process should meet at least twice a week to review designs. These meetings generally follow this agenda:
Review the previous meeting’s action items
State and review the goal of the meeting
Designer to present the most recent designs and ask questions
Identify what questions must be answered by the team to move forward
Answer questions and create action items
Review new timeline and ensure it will meet goals
Wrap meeting
Design meetings are notorious for creating scope creep. It is important to have a decision-making process to quickly overcome disagreements. My recommendation for this company is a tie-breaking person between the team leaders.
UX Design Process
The design process is iterative, meaning that the designer will go through multiple reviews before finalizing their designs. The process of designing features comes BEFORE the development of said features in most cases. Adding a designer into the middle of a development process with the expectation they can iterate very quickly on designs and meet with stakeholders within that time is a recipe for failure.
This process often takes the following steps:
System discovery - Gathering all the information required to build a system or feature. Very often, this is the process of understanding users, roles, requirements, the problem, and researching potential solutions. Common deliverables include benchmarks via a mood board.
This also can involve multiple meetings to review benchmarks and prepare for the project.
Initial Draft - Take information noted in the section “Information requirements for UX” and build an initial draft or draft.
When a designer is getting started on a complex project, it is very helpful to have a senior designer review project specifications with the designer to ensure they have a thorough understanding of the project. Whether it is with a senior designer or a peer, this is a process that does and should happen often.
As expected, after the UX designer has been working for a substantial amount of time on the project, they will be able to operate with a design user story instead of all questions all the time.
Review drafts & ideas with peer designer - Just like developers, designers miss things and almost always need to ‘polish’ designs. This peer-review process is equivalent to a code review and QA for developers. Sometimes this means stepping away for a while and reviewing the work again the next day. But a better system is to have another designer review work. I cannot stress enough the importance of this practice.
Present initial designs to stakeholders - Depending on the project and complexity, this could be the first of many or the last presentation. Most often, it is the first of multiple presentations.
See the section entitled “Stakeholder Meetings” on how to run this meeting.
Iterate on designs - After the initial review of designs, secondary and tertiary reviews are often necessary to get to a final product.
Working with this process is very different than working with a development team.
During iteration, very often designers need to either step away and review a few days later or have a second designer review work if at all possible. This has a dramatic effect on the quality of work.
Customer review & user testing - After designs have been mostly completed, these designs should sometimes be presented to select customers for feedback and users should be put through at least basic user testing. If needs be, we can invest in a more extensive user testing system, but in the very least basic user testing should be done.
Finalize designs - Once stakeholders are satisfied with designs, they can be prepared in stories for developers by the product owner.
Story implementation oversight - While stories are being implemented into the code, the designer should give feedback on the success of this implementation. This is a critical step since very often the design, and thus the intent of the design is lost in development. Moving a page element from one area on a page to another can drastically decrease the usability of a system. Therefore the designer should be involved in daily standups and ask to see systems as they are implemented.
UX QA - Because the implementation of stories can change during QA, a final UX QA process must be done before a product can be signed off by the UX designer. Most often, these are changes that will be done by front end developers.
Success measurement - Understanding clearly if goals were met in the delivery of stories is key to continuous improvement. So each success measurement must be able to be tracked as best as possible and followed up on in the time after the implementation of new UX.
Product Owner and Team Education
To effectively implement great user experience into a product, lead team members should have at least some training in user experience design. Leadership comes from the top and product owners need to be driving user experience.
To accomplish this, it is my recommendation that team leaders take a course in UX. This could be a course designers take to learn UX design and would give team membres knowledge on processes expectations, methods, and much more.
Recommended Reading
Here is more information on doing user/usability testing: https://www.toptal.com/designers/ux-consultants/how-to-conduct-usability-testing-in-6-steps
Google Material Design: https://material.io/design/introduction#components
This is a great article I found during my research for this document on improving the user experience of an application: https://www.netguru.com/blog/how-to-improve-the-ux-of-your-application-extensive-guide
Last updated