UX designers play a significant role, especially in enterprise companies. Tech companies are also realizing that it’s not enough to just solve a problem, they should also keep the customers engaged, satisfied and tailor their products based on user needs. This is easily reflected in the changing designer:developer ratios and to their continued evolution from engineering-driven to user-centered organizations.
But, does having a large design team guarantee the products are user-centered? Maybe not. There are innumerable products in the market with sub-standard user experience even with large design teams. This is because a product is shaped by people from different teams with different backgrounds, motivations and challenges. So it becomes very important that every team in the company understands the users’ point of view, their problems, goals, challenges and context while they are contributing to developing a product.
Any product in a company is co-created by all the involved stakeholders and it's not designed just by the designers. Therefore it is important that all the involved stakeholders talk and understand the user goals in order to create a product for the user instead of building features and functionalities. An important part of it is building user-centered artifacts by every team. This is because every member in every team will refer to one or the other documents(along with attending meetings) to understand what they are supposed to do. In this blog I am sharing ideas on how each role/team can create user-centered artifacts and how it will help drive user-centered mission.
This is where the vision of a product starts getting shaped in the form of a product specification. This is a document which will be referred to by all the teams to build the product. What a great source this could be to set the stage for user-centered design.
The product managers put a great deal of effort into understanding the product/market fit by studying the user base, the competitors, the business goals, etc., before coming up with the product specifications. So when the PM writes the product spec, they should pass along all the information they have gathered to the downstream consumers of the product specs - designers, engineers, QA, Marketing, customer success and sales. Because each of these teams will refer to product spec to decide what to build.
Product spec is a great stage to set the ball rolling for UCD. Make sure to include all the information gathered in the document - the user, the problem, the competitors, the challenges, the solution, the scope and then comes features.
As designers, the artifacts we produce play a huge role in driving the users’ first mission.
In a fast paced, ever-changing setup, designers often focus on cranking designs based on never-ending requirements. As a result, the output we produce are generally mocks (one or more sets of screens which visualize the requirement) which are then attached to a ticket in jira/excel-sheet/wiki-page. The problem with sending the mocks in isolation is, they do not tell the person who is referring - who the user is, what the overall workflow looks like, what are the entry and exit points, success and error scenarios, etc etc.
Mocks are necessary to visualize a single screen(or a subset of a workflow) in terms of layout, CTA’s, Information architecture, navigation and visual design, which may be sufficient for immediate stakeholders who know what's going on in that project. But the design artifacts will be used beyond the immediate stakeholders, so it becomes crucial they too understand the complete story and know what they are building, who they are building it and how the user will eventually benefit from it.
Depending on the scope, time and priorities, designers should try to produce the below artifacts along with the mocks, as much as possible;
Personas - A representation of a cluster of end users who represent similar behaviors, goals, motivations, and needs.
User Journey Maps - A visualization of a user’s experience to complete a task over time and across channels.
Sitemaps - Sitemaps are a hierarchical diagram showing the structure or major templates of a website.
Flowcharts - A diagram that represents a workflow or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows.
Wireframes - A visual guide that represents the structural framework of a website.
Prototypes - Prototypes are interactive representations of product ideas.
Usability Reports - A report or slide deck that communicates findings and recommendations from various usability analysis exercises.
Wireflows - A report or slide deck that communicates findings and recommendations from various usability analysis exercises.
Engineers are extremely important stakeholders when it comes to turning an idea of a product into a reality. The product team might define the requirements and set the priorities but its the engineers who execute it. So it becomes super important that the engineers have a good understanding of the problem they are solving and whom they are solving it for. It is important they see their work beyond backend code, frontend code, api’s, databases, etc., and see it in terms of how the end user would interact with a feature or functionality they are building.
Having user-centered artifacts from the product definition and design phase helps the engineers understand the requirements from the user point of view. Additionally, if there are any technical limitations to implement a feature, it is easy to have a conversation by mapping how that feature will affect the users.
The QA process is the final gateway where the product is certified for release or where issues are found to be fixed. Similar to the engineers, it is important that the QA team have full knowledge of the user base, user needs and problems and how the product is helping solve the problem. So when they test to assure the quality, they don't just test the quality of a feature, they also test the quality of the user's experience.
Test cases are the artifacts that the QA team produces to test a product. The test cases, instead of being centered around features or functionalities, should also be around the user workflows. Having a product spec, design details around the users will help the QA team write the test cases, as well, around the users.
The users are not the buyers and oftentimes the success to the product is generally measured in terms of its sales, especially enterprise companies. Seldom one measures the success by user satisfaction. Well, sales is important, but if we want to truly be a user-centered company, we should also celebrate the success-story/feedback of the user along with celebrating good business.
How to Create A User Centered Product
No matter how serious the company is to make their product user centered, until the last person understands the meaning of it, the job is not done. Hiring designers and practicing User-centered design is a good start, but we should also make sure every person in the company who is responsible to build the product has empathy and understanding of the user. As they say, it takes a village to raise a kid, it takes the efforts of the entire company to delight the user!