Feature design checklist

Questions that ensure you consider e̶v̶e̶r̶y̶t̶h̶i̶n̶g̶ a few things when designing a new feature

As the UX designer of a team working on a relatively young application, I mostly get to design entirely new features, as opposed to improving or revamping existing features. (My product owner keeps promising me that this will change once we are “feature complete”. Considering the reality of our agile world, that just might be product development’s equivalent of the twelfth of never, amirite?)

When we (the communal designer we) are churning out features it is easy to miss crucial aspects, because the things we design are complex — that’s what makes our work so wonderfully exciting!

To alleviate this, I’ve been collecting a list of questions — more like a harangue of questions— that keep recurring in our team discussions. This is in the hopes of us catching the bulk part of potential pitfalls of a feature before any code is written. It can also be seen as an attempt to formalize some of the considerations that go into planning software features. Think of it as a preliminary heuristic evaluation of sorts.

In terms of process, the most appropriate time to look at these questions is when you have an idea of both:

1. what user need is that you are attempting to address (ideally verified to be a real user need)
and
2. how you are planning on solving it.

Since one should never go for the first idea, you’d ideally have explored a few different solutions. Maybe these are in the form of rough sketches or lo-fi prototypes, or you may ask them at the refinement stage, before any code implementation commences. Hopefully, by the time development is halfway through you’ll know the answers to most of them. They might also help you figure out which one of the proposed solutions is the best fit.

With this established, let’s get to the questions!

1. Goal
What is the goal of using the feature? Why is the user choosing to do this? Define this in the beginning to avoid losing sight of the intention. This will come in handy later on, when nose-deep in a pile of details and scope creep setting in.

2. Existing patterns
Is this a common function in other applications? This could be for instance, managing a list of items, including adding an item, re-sorting the list, or executing a bulk delete on several items. For a typical functionality such as the list of items, the follow-up questions would be: Is there an established way to do this (that the target user group is familiar with)? Is there a known pattern or guideline for the platform that the application is running on? (This holds especially true for iOS or Android devices.)

3. Conceptual parallels
If this is an entirely new concept, can you abstract it to more general terms? Does a similar functionality exist somewhere that shares the same approach as your solution? Are there metaphors in the real world or from your users’ everyday life that you might be able to apply?

4. Prior knowledge
It might also be relevant to think about what certain user cohorts bring to the table from previous experiences: Is there a ubiquitous tool that they are experts at? Does this influence their expectations of how, let’s say, import works? Or to what extent are they used to auto-save over clicking “save”?
To put myself in those shoes, I just think back to four years ago when I transitioned from Illustrator to Sketch: Handling anchor points in Sketch felt both limiting and uncontrolled at the same time. Honestly, I might have given up if Sketch hadn’t had a lot of other advantages motivating me to keep at it.

5. Complexity
How advanced is this feature? Is this an action the users will come across on their first visit to the UI, or is this exclusively for experts? How prominently should this feature be placed: Should a yellow brick road be leading straight to it or should it be tucked away so that beginner users don’t accidentally stumble over it and break something?

6. Physical context
What is the context of using the feature? Could the users’ surroundings influence the way they are able to process information or operate the interface? How may the design help compensate for this? Can you reduce complexity or the number of elements, increase contrast or click/tap areas?

7. Temporal context
What happens before? What have the users typically been doing before they get to this feature? Which part(s) of the application could they potentially be coming from? Can you provide a clear path back to safety in case they realize they are on the wrong track?

8. Trigger
What triggers the use of that feature? When or why does the need occur? The trigger could be time-based. For example, that there is new content updated weekly, or figures that have to be reported at the end of each month. Or it could be the system itself prompting the user to act.
If so, how intrusive does the prompt have to be? How can you prevent the application from crying wolf unless it absolutely has to?

9. Settings
Are there settings that need to be configured before the feature can be used? Does the system remember them for the next time? (The answer should be yes in 99% of cases.) Is the user aware of where to change these settings later on?

10. Preconditions
Are there preconditions that need to be in place first in order for the feature to be enabled? I still remember the frustration of trying to learn Photoshop half a lifetime ago: It felt like 80 percent of the tools didn’t work, because I didn’t realize it was necessary to select a portion of the image first in order to apply a filter or transform. How do you communicate such a prerequisite to the users?

11. Need to know
Does the user need any information in order to make sensible choices before embarking on this workflow? Is there anything that they need to be able to see to make appropriate choices? If you are taking the user to a different view, could it be helpful to provide the required information?

12. Progress
Are there operations that take time to execute? Does it take time to load certain information or initialize a process? How can you show this progress to make the users feel in control? Can the users continue working in the meantime or is it necessary to prevent them from changing anything?
If an operation takes longer than a few seconds, providing a way to cancel is a good idea. Where is the user taken after canceling? Can you ensure that the system is able to return to its previous state?

13. System feedback
How do users know whether an operation was successful? Is the feedback unobtrusive but still clear enough? Is there a clear way for the users to undo the action?

14. Errors
What sort of errors may occur while using the feature? If they have varying degrees of severity, is this reflected in how these are communicated? How are you helping the users fix these errors? Have you included shortcuts to further information or a help section? We have a running joke in my team about how we’ll include the personal mobile numbers of our customer support staff to solve technical edge cases, but really you want to provide all the necessary tools and information into your users’ hands so that they can help themselves.

15. Frequency
How frequently will this feature be needed? Is it something the user does ten times a day, once a month, or something they configure once and never look at again? As a consequence, how many clicks, taps or swipes should it take to execute? Can you provide keyboard shortcuts or bulk actions to eliminate navigational excise?

16. Accessibility
To what extent should accessibility be taken into account? Is the feature accessible with a screen reader? Is there a workaround for operating without a mouse? Don’t forget to double check for sufficient contrast, text sizes, and color blindness.

17. User roles
If you have different user roles in the system, is everyone allowed to access this feature? Or does it involve sensitive information that only certain people should be privy to? Should non-privy roles be aware that there is more to see, so that they have a chance to ask to be upgraded?

18. User onboarding
What is the first-use experience going to be like? How should users be onboarded to this feature? How are you going to make them understand (and care) what the purpose of the feature is and what the value to them is? How are you going to provide just enough support in the beginning without getting in the way? New playlists in Spotify, for instance, clearly state that “this playlist is currently empty” followed by a clear call to action of where to find new music to add.

19. Empty states
How should the feature behave when there is no data, i.e. its empty state? Can you help users understand what the view in question is about by foreshadowing the type of content they’ll find here? How can you leverage this moment to demonstrate how they may populate the view?

20. Technical constraints
Have you factored in suboptimal hardware or connectivity issues? Does the proposed solution still work when used on slow machines or low-resolution screens? Is there a way to degrade gracefully? A classic example of this is to switch off auto-play of videos on slow connections.

21. Design system
If the feature warrants a new interaction pattern, do you need to update your design system or component library?

22. Simplify
Is it possible to simplify the feature even further? Does it match the rest of the application?

BONUS CONSIDERATIONS

23. Naming
A feature has no name? Well it should. Be deliberate about naming things from the onset, both in internal and external communication (and make it the same — writing the user documentation or providing support is difficult enough without having to juggle conflicting nomenclature). If you don’t, someone else will label it something random — and these things tend to stick.

24. Publicity
How will people learn about this feature? Is it going to be via a newsletter, an update on the website, or perhaps a notification in the app? Based on that, what will their expectations be? Will they already be aware of the value this update brings them or do they have to try it in order to fully understand it?
The inherent risk of elaborate marketing material is setting the wrong expectations about the capabilities or look and feel of the feature. So how well does the external communication match the experience in the product?

25. User feedback
How may users leave feedback about this feature? Is it easily available should they go looking for it? How can you request feedback without getting in the way?

Of course, some of these questions may not be relevant in certain cases. Simply disregard them for this time around and go on to the next one. But do take comfort in the fact that this was a conscious choice of yours, rather than missing something important until after the release (Because trust me, that’s not a particularly pleasant sensation).

I intentionally didn’t talk about how to answer these questions: This will vary from case to case: You might know the answers right off the bat, you might discuss them with your team (actually that’s not optional — your developers and testers will have valuable insights), and you’ll hopefully ask some of your users or do some other kind of research. But that’s a topic for another day.

Do you use similar checklists? Did I miss a question? Or do you have a different way to ensure you are considering all important aspects from the get-go? Share below!

Thanks to Elise for ploughing through the first draft of this harangue of questions with color coordinated sticky notes.