I love Starbucks!!! It has been my go-to place during my consulting days not just for the coffee and food but also for the casual client conversations. One of the best things about Starbucks is that it allows you to go crazy on your order. “Can I get a Triple, Venti, Half Sweet, Non-Fat, Caramel Macchiato“. “Sure, your name“, says the barista and that too smilingly. Well, it goes to show that baristas provide an excellent user experience and are able to accommodate all what’s requested by the client (end user). However, when it comes to gathering requirements during UX research sessions, I suggest that you refrain from playing a barista’s equivalent.
Your UX requirements gathering stage is a very crucial stage before you start designing your UI. There are various types of requirements – business, user, functional etc. But for the sake of simplicity, I am just clubbing them all as UX requirements for this article. The following are some of the best practices that you can follow to ensure that your requirements gathering phase is as successful as possible –
- Get a clear understanding of the business requirements. Without those, the project is just a rudderless ship. A clear picture of – why are we building a certain application or product will pave way for a better UI. “Sir, just to confirm – it is a “Triple, Venti, Half Sweet, Non-Fat, Caramel Macchiato”
- Prioritize the business requirements with the client so that you get a sense of what the must-haves and the nice-to-haves are. You can also use prioritization techniques such as MoSCoW (Must, Should, Could, Won’t), or even use a simple priority matrix. Once you have your prioritized list of requirements, you will get a sense of what should be included as base requirements and what as ‘enhancements’.
- Gather user requirements not just by perusing documents but in an interactive manner that is user-centric. Conducting interviews and workshops help you understand and articulate the users’ requirements and pain points in a more elaborate manner.
- Requirement workshops are mostly pretty effective but sometimes can be aggressive or plainly funny. People can get very creative in offering solutions for solving problems – problems that are not part of the original scope. So be wary of scope creep.
- If a particular requirement is not clear, ask questions. Remember “There’s no such thing as a stupid question”. In a barista’s parlance- “Sir – By half sweet? Do you mean with sugar or with a sweetener?”
- In most cases, a web solution is already in place before a client opts for taking that solution mobile. In that case, clients try to push all the features available in the web solution as requirements for the mobile solution. The author Emrah Yayici mentions such a scenario in one of his books in which a client from the banking industry requests for specific web banking features to be available in the mobile solution. In this case, adopt ‘Worse is Better’ or the ‘New Jersey Style’ (my NJ friends, please don’t be offended). This basically means that quality does not necessarily increase with functionality. So, sometimes less functionality is preferable. One of the analogies that we use in-house for this situation is – ‘Moving from a house to an apartment’ which means that you should ideally be taking only the most important stuff with you from your house into your apartment (and from web to mobile). Again, clear business requirements will help you prioritize the features that need to go in the app. “Sir – Your requirements state that you want an app that can help you with printing, scanning and copying documents, scheduling meetings, organizing your desk and reminding you of events?? Sir, in that case all you need is a copier and an admin assistant.”
I hope that these practices help you in your requirement gathering phase of the project. And by the way, I never said that Baristas don’t make good UX analysts so don’t try to pin that on me!!!