Join Drew Bridewell for an in-depth discussion in this video Designing for context first, part of Practical UX Weekly.
- When it comes to designing world-class user experiences, you may have come across many outstanding techniques and best practices to execute your new world-class design. You might have heard of designing content first, or even designing mobile first. I've also experienced an all-at-once design approach where you look at mobile, tablet, and desktop all together. Now if you have found a process that works for you and your team, then don't break it if it's working for you. Today I want to hand you one more technique that you can add to your process when it comes to designing for a multi-device, multi-use case world.
Consider this approach to be a compliment to your process and design thinking regarding when a user will experience your product. My goal for this episode is to help you determine when your product will be used, so you can design the right features and experiences for your users at that moment in time. Not all features need to built across devices and screen aspect ratios. I'll help you determine how you can decide if the feature needs to be there, as well as keeping it simple, so you don't over-engineer a solution.
When it comes to getting started on any project, it's easy to throw in the coolest and most complex features the product has ever seen. However, teams are required to move fast, be efficient, and not compromise on quality or craftsmanship. With that said, we must do our due diligence to make sure we're building the right features within the right context. For example, on LinkedIn Learning and lynda.com's course page, we have a transcript feature. The transcript feature displays a written version of what the author is saying so the learner can follow along.
However, the feature was not meant to be on iOS or Android because a learner's watching full screen on their mobile phone. They wouldn't be able to see the script. This is just one example of when you would not build a feature because it wouldn't work very well. There are also times when a feature could definitely work, but it would take a substantial amount of effort to execute. From this point, a team would need to decide how to prioritize this feature by looking at the user activity and usage data.
Then check what device the users are most active on and when they're most likely to sign in to the product. And think about the technical debt and costs of building features across the ecosystem. If you work at a larger organization, you might decide as well if the feature needs to become a component so that it can be shared across the engineering teams. Designing a feature with context in mind helps you gain a wider perspective of your organization and who might be affected by this change.
Start by sharing your product decisions across the organization to make sure they understand when and why you don't include a feature across all platforms. Sharing this could help alleviate customer support questions and comments which save everyone time and energy. Poor communication ends up costing you and your team more time in the long run, which can cost you and your organization money. Consider a transparent approach about your feature updates so the whole company can benefit.
Once you've formed the initial strategy about where and when the feature will show up, you'll be able to monitor the usage of the feature throughout its existence. Then you can measure its use, which can help you prioritize your future investment into the feature. After a few months of solid data, you might find out that the timing isn't right for the feature, so you might ramp it down and start prioritizing the next feature that can make an impact. When designing the strategy of your new feature, consider that the feature could be desktop only or a premium feature, meaning you would have to pay a small fee to get access to it.
One example would be exercise files. If you pay a premium price, you get access to them.
To continue the conversation started in this course, with Drew and other user experience professionals, join Drew's Practical UX: Lessons from the Trenches LinkedIn group.
Skill Level Intermediate
Q: Why can't I earn a Certificate of Completion for this course?
A: We publish a new tutorial or tutorials for this course on a regular basis. We are unable to offer a Certificate of Completion because it is an ever-evolving course that is not designed to be completed. Check back often for new movies.
Q. Where can I ask the author questions about practical UX?
A. To continue the conversation started in Practical UX Weekly with Drew and other user experience professionals, join the LinkedIn group at https://www.linkedin.com/