Designing for Progressive Disclosure Part II: Product design workflow
After writing our first article about progressive disclosure, Michael Lee Kenney and I were able to present its content in several contexts to hundreds of participants. While our first write-up addressed what progressive disclosure is and why it’s valuable, in this article we will provide concrete steps and metrics for success in terms of how to bring progressive disclosure into your product team’s workflow and get buy in from teammates and stakeholders. We received a lot of requests for how to truly implement progressive disclosure on a product team.
Progressive disclosure should not be owned by any particular discipline. It is a cross-discipline responsibility that spans product owners, marketers, user experience designers, content designers, developers and support teams. Depending on the phase in the product design process, progressive disclosure will alternate between a hand off and a series of collaborations between the various disciplines on a team.
Developing a robust progressive disclosure model: the importance of user research
All too often, we move from a defect in the product experience directly to user experience design or content design without doing the proper user research and context gathering. The most important thing for the user research team (or another member of the team if you don’t have any user researchers!) is to look at a defect or noted issue through the lens of a particular user scenario or a persona’s job to be done. When we view perceived defects in isolation we often present quick but incorrect or only partially correct solutions.
Whether you are working on a legacy product or a new product, dedicate some initial time for your team to properly identify your primary users’ jobs to be done, and allocate time in your product development cycle to review these users’ jobs and add to or update as you continue to learn more. A job to be done is not necessarily product specific; it is specific to your user’s job role. Without properly identifying jobs to be done, your team will not understand how the various tasks in a product work together to fulfill an actual user need.
Jobs to be done should be intimately connected to persona understanding. Some examples are outlined below.
Again, the only way to properly understand your personas and their respective jobs to be done is through user research. One-on-one interviews and/or usage analytics are likely your best bet here. A good strategy is to curate a group of users that you can reach out to regularly or have a usage analytics platform you can access. Have your team set up a cadence to monitor your users’ ability to accomplish their jobs to be done through the development of your progressive disclosure model in your product.
Keep in mind that it is rare for a given persona to access 100% of your product’s functionality. There are several persona types whose workflow is serviced by a product’s features, but an individual persona will usually only access 20% of a product’s features. If you get one-on-one interviews scheduled with users, be sure to ask, “what are the things you do every day? Or as soon as you open the app?” These kinds of questions will help you uncover their top jobs to be done and how to design appropriately with that in prioritization in mind.
As we move from understanding personas towards progressive disclosure in product design, we have to move from a broader level to a more granular level. Jobs to be done can be broken down into tasks. Tasks can exist both inside and outside of the software or offering. For example, one task may be uploading image folders to a data set but another task may be cropping all the images before upload. The second task may not exist in the product itself, but it is still a critical task to map for your team’s understanding of the user’s entire process. Next, tasks that occur within the software or offering can be broken down into steps. Steps are your most discrete element and are literal interactions between user and product. An example of a step could be, click the upload arrow to bring in a zip file of images. If you still feel unclear about the distinction between tasks and steps, I go into more detail about the difference between the two in my Complexity Analysis article.
Steps are typically where your progressive disclosure strategy is defined and applied. Info icon verbiage is unclear; an icon is in an unusual location; a user did not realize they had to paginate to get to the next step. The problem is, identifying and diagnosing the problem at at the granular step phase without understanding the entire progression to this point will result in a fractured, unsuccessful progressive disclosure model. Simply rewriting two lines of text, moving an icon from left to right, or including an on-boarding widget will likely not be the best design solution for long-term product experience success.
A common issue that teams have is this idea that building a successful progressive disclosure model is primarily about adding more information for the user. But we can use this same model, moving from jobs to be done down to steps, to remove any user interface elements that don’t directly contribute to a discrete step or larger task. If there is information in the UI that can’t be mapped to a task, you have to consider whether it is really adding value to the product. Clutter can cause just as much confusion as lack of information and always defaulting to adding more guidance is often not the answer. This is where your user experience designers can really shine. They can design a flow that maximizes the relationship between information and navigation to provide context in a way that reduces steps, verbiage, and cognitive load. Remember, your progressive disclosure model is about designing your product so that it meets your users’ jobs to be done.
Use Case: Generating a REST API in PowerAI Vision
Let’s take our method and apply it to a real product use case. My current product PowerAI Vision is a computer vision product for both non-technical and technical users to label, train, and deploy deep learning models for image and video data.
In this example we will:
- Identify two key personas and their jobs to be done.
- Break down jobs to be done into tasks that exist both within and outside of the product.
- Break down tasks into discrete steps that map to actual interactions in the product user interface.
- Assess elements of progressive disclosure at the step level and ensure they feed into the larger goal of a user’s job to be done.
1. Identify two key personas and their jobs to be done.
Through hours of user research and one-on-one interviews, we’ve been able to identify two key personas: the data scientist and the subject matter expert. While one of these personas is technical and knowledgeable about AI and the other is not, they can both have the same job(s) to be done. This is why it’s critical to understand progressive disclosure at this high of a level. The information that will ultimately need to be surfaced in the product for the data scientist will not be the same as the information needed for subject matter expert, even for the same job to be done.
In this scenario, the job to be done is: generating a REST API for an object detection model that properly identifies broken electrical insulators. Both personas have the ability to accomplish this job in PowerAI Vision, but will do so in slightly different ways with different levels of understanding.
2. Break down jobs to be done into specific user tasks.
So let’s take our job to be done, generating a REST API for an object detection model that properly identifies broken electrical insulators, and break it down into discrete tasks. These tasks are outlined in the diagram below:
3. Break down user tasks into discrete steps as UI interactions.
Now, let’s take an individual task and break it into discrete steps. Remember, steps are your most granular state, and the point at which actual progressive disclosure content is typically implemented. But diagnosing and designing for the step level, without the contextual understanding outlined above, leads to fractured, short-term solutions that introduce complexity into a user’s experience and ultimate product understanding.
For the task, “import a set of images into a PowerAI Vision to create a data set” the discrete steps to perform the same task, as part of the larger goal of completing the same job to be done, vary somewhat between our two key personas. This is because of their different levels of technical expertise and workflow processes both inside and outside the product.
4. Assess elements of progressive disclosure at the step level.
It starts to become pretty clear how progressive disclosure can be implemented at each of these steps. Navigation placement and proximity, the use of icons and text, a sense of progression, knowing to bring in the right file types at the right time, and ultimately receiving feedback from the system that a success or failure has taken place are all ways in which progressive disclosure can manifest in a product.
But we can also see that we have to progressively disclose for step variations based on persona. This is where we can look to some standard methods outlined in our first article to achieve a “Goldie-locks” level of information that best meets the needs of a diverse user group. We need to empower the subject matter expert without overwhelming them with technical information, while still providing easy access to advanced features or technical information for the data scientist who may be accomplishing the same overall task, and job to be done, but in a different step variation.
On Your Product Team: recap
Does your product team already have validated personas? If not, set aside some time to conduct 3 to 5 user calls, regardless of whether or not you have a dedicated user researcher on your team!
If you do have personas, outline a few of their key jobs to be done and choose one to start with.
Break the job to be done down into tasks. Don’t worry so much about your product. Think about the user. Think about the conversations you’ve had with them and the research you’ve gathered. What do they need to get their specific job done?
Next choose a task that does take place in the product. Do a quick check to make sure the task is not a step. Can it be broken down further? The answer should be yes.
Now that you have a task, you can get granular. Break your task down into steps aka literal user interactions within your product. Think “click this” or “navigate here” or “view message.” This is where you want to implement the majority of your progressive disclosure methods.
Now that you have your steps, evaluate any relevant existing feedback you have from users. Design a testing feedback session to get the feedback you need to ensure users are not lost, confused or disoriented at any of these steps. Start to understand how to live between the high level perspective of a job to be done and the granular perspective or a step when faced with user feedback or needs. Doing so will ensure you have a robust, well-designed progressive disclosure model that starts with your user, not with an info icon.
All thoughts expressed are my own. Co-written with Michael Lee Kenney http://www.gabriellacampagna.com/
