Comment on page
Think about the user
Knowing who will use your tool will help the tool be easy-to-use
Before beginning, it is important to spend some time thinking about the user and the context under which they'll be using your tool. Spending even a short time doing this now will save you development time, especially since you may realize that your final tool can be quite simple, or that adding one small feature, like a new API call, will satisfy your user's needs.
Below is a list of questions to help you start thinking about this.
And don't just say 'Everyone!' The more specific your answer is, the easier it will be for you to create a design that really works for them.
Sometimes we really are designing a tool for more than one type of user. In this case, list out who each of your users are. Then pick one, or at most two, types of users who you are going to focus on for this round of design. Add more users you will support as you continue to develop your tool.
Focusing on just a few users will ensure you will serve some users really well and you are likely to be able to serve your other users decently. It is better to have a small but solid user base, rather than have no user base since you didn't meet the needs of any of your users well enough to hook them into using your tool.
Why do they need my tool? What is their short-term goal? What is their medium-term goal? What is their long-term goal?
What is the skillset of my users? Do they have experience with the command line? Do they prefer to use R or Python or something else? Do they use Linux or Mac or Windows?
What tools will feed into my tool? What do those outputs look like?
What tools will take results from my tool and do further analysis? What do their input requirements look like?
What administrative privileges do my users have for the computer my tool will be used on? Will they be able to install the tool themselves or will they need IT to do it for them? Will they only be able to access certain web browsers or web browser versions? Will certain websites be blocked, either by an institution or by the country?
What are the security requirements for my tool? Does it need to run in a secure environment? What are the security requirements for the data inputs and outputs?
Will the user be running this tool on a shared computer or cluster? What requirements will that put on the tool?
Will they be publish using the results from my tool? Are there any requirements for publishing?
Will they be sharing results to coworkers/PIs/etc? Who are they? What is the best way to share results with them?
When are the users going to use my tool? At the beginning or end of a project? How long will it take to run my tool?
Think about the user's social networks, broader career, professional goals, and personal goals. Will they tweet/post about your tool? Are they a far along in their career or just getting started? Will they teach about your tool? Is their home life such that they will need to easily leave and come back to your tool?
If you have time and access, talking to your users is one of the best ways to understand them. That said it is important to note that what people say and what they do can be wildly different. It is best to stick to questions about a specific instance, such as the last time they ran an RNAseq analysis, rather than asking them more generally what they do. Ask them what went well and what was difficult for them.
When asking them about the last time they did an analysis, keep a lookout for workarounds and hacks. These point to places where there is need for improvement. Similarly, when someone makes a mistake or an error, this also can point to places for improvement.
Last modified 2yr ago