> For the complete documentation index, see [llms.txt](https://www.thinkinglikeyouruser.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.thinkinglikeyouruser.com/your-first-project.md). # Your first project The steps below lead you through your first UX project It is worth nothing that it can be helpful to get feedback before you begin. A great way to get feedback from other UX folks at any and all parts of this process is to [join online professional communities](/support-yourself.md#join-online-professional-communities), especially when you are starting out. ## 1. Pick your project Pick a project that is small in scope, where your proposed changes will be an obvious win. Don't pick the main function of the tool, since this is where you are likely to get the most push-back. Don't pick the front page unless what you are proposing is an obvious fix (see [Basic Visual Design and Design Systems](/evaluating-where-you-are.md#basic-visual-design-and-design-systems)). Ideally you want to pick a project where there is a metric you can measure to show the impact of your change (i.e. the number of users completing a certain analysis). It is possible that the change you're proposing is too small to have a measurable impact or your tool is not yet public, but it's still good to think about this. You may find that your first project is actually one that you were already going to do, but you are now going to approach it from a thinking like your user mindset. ## 2. Plan and prepare Go through the rest of this page and outline a plan. Hopefully you picked a project small enough that you won't need to ask for permission, but you may still have to. Plan for how you will do this and [pitch your idea](/bringing-ux-to-your-organization.md#advocating-for-ux). Lastly, ensure you have a way to [measure metrics](/researching-your-users.md) on your tool if you don't already have them so that you can show the impact of your work. ## 3. [Think like your user](/home.md) No matter your project, always start with a \[value proposition statement] for the whole tool. Then think like your user by [writing about your user](/thinking-like-your-user.md#write-about-your-user) or [creating personas/archetypes](/thinking-like-your-user.md#create-personas-archetypes). For subsequent projects you can reference or refine these materials to center yourself rather than create them. ## 4. Do a UX method Pick a method that you would like to do from [Evaluating where you are](/evaluating-where-you-are.md) or [Researching your users](/researching-your-users.md). ## 5. [Make a design](/making-a-design.md) Keeping in mind what you learned from your UX method, make a design. Depending on the size of your change you might skip this, but it is still good to consider. Perhaps a fix that seems obvious to you actually has more than one way that it could be done? ## 6. Implement your design ## 7. Follow up [Make a mini case study ](/bringing-ux-to-your-organization.md#mini-case-studies)to document what you did and any outcomes. Consider whether there is a conference, lab meeting, lunch series, or grant report where you can present your work. ## Example first projects ### Front page redesign I started working on a new tool where the home page was a block of text with no call to action. The data input section, which is where the user would begin to use the tool, was halfway down the screen. **Method used:** [Basic Visual Design and Design Systems.](/evaluating-where-you-are.md#basic-visual-design-and-design-systems) I focused on rearranging what was already on the screen, with almost no new text or buttons. I moved the data input section up and added some header text to draw attention to it. I also added some visual hierarchy using headers. There was a lot more that I could have proposed, but I kept the refinements simple and easy to understand. Remember: something is better than nothing. **Outcome:** I didn't have metrics set up when I did this project but metrics you could imagine measuring are a) how many users who go to the front page upload data, especially for new users or b) how long does it take between users arriving and uploading data, especially for new users **Organization logistics:** I did not ask permission and did the design quickly. I presented it to the group as a single image as part of a larger meeting. Later the team decided to implement it as is. ### Adding dedicated documentation and better error handling before publishing a new tool A graduate student developed a new tool and asked for feedback from me before they published. **Method used:** [Heuristic evaluation.](/evaluating-where-you-are.md#heuristic-evaluation) I started with thinking more about the user of the tool and what they would be looking for in the tool. I then spent an hour doing a heuristic analysis of the tool. **Outcome:** It turns out the tool didn't have documentation besides a few tips embedded in the interface itself. The tool also lacked error handling beyond the basics. I presented the report from the heuristic analysis to the graduate student. They took the feedback, made a few changes, and published. There were no metrics since the tool was not yet published. **Organization logistics:** The graduate student spoke about my report to their PI, and the PI ended up doing a heuristic evaluation for another tool. ### Redundant documentation I was working on a tool where documentation was embedded in the tool across several different pages and was pulled into the tool interface depending on the type of data being viewed. Unfortunately, much of the documentation was redundant, a state that had been reached because of confusion on when it was pulled into the interface. **Method used:** [Content overview](/evaluating-where-you-are.md#content-overview) on just the documentation that was being pulled for different types of data. I didn't spend as much time thinking like the user for this project, since it was so obviously confusing to the user. **Outcome:** Reduced documentation redundancy. No metrics were measured **Organization logistics:** I pitched it as a project by saying that it would make it easier for developers and content managers to keep track of documentation, reducing work for our team. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.thinkinglikeyouruser.com/your-first-project.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.