UX Design | Internship | 12 weeks


Policymaker is a tool for conducting simulations as a part of a Public Policy course at the University of Michigan. This tool was the brainchild of Professor.Elizabeth Gerber in partnership with Digital Innovation Greenhouse where I was part of the User Experience and design team of Policymaker.


Policymaker was a new project and there was a need to translate the user requirements into product features and ensure it was meeting the needs of the course.


User research/design and Visual design consistent with other parts of Policymaker.

Design Process

The whole design process could be summed up as follows:

Focus Group


pm focus

The students who had taken the course in the previous semester were invited to participate in a focus group to help us understand the process that the simulation follows. There were about 7 participants with a moderator who intervened to clarify something or pose discussion topics. The focus group session was recorded for further reference during the development. We gathered a lot of requirements and the session gave us an overall sense of what the tool can be. We understood the motivations of the users to use such a tool as well as a general sense of what functionalities they were expecting from a tool like Policymaker. The discussion flowed smoothly without a lot of questions or topics from the moderator which was a good indicator of the immediate need for a tool for the course.

Requirement analysis

After the gathering of requirements, the team discussed the main and important aspects of the focus group that pointed to a feature of the tool. We prioritized the features according to the level of importance to digitize that specific part of the simulation. We also considered what features made sense to be included in an MVP. The features were grouped into categories and put into a Trello board to be started off in the design and development cycle.

Roles Notes / Explanation from the Focus Group
Individual Bio pages. link to existing (real) bio page for each role. Bio page needs: role name, name of student playing the role, description of the role, any groups/committees the person is a member of, all affiliations and public positions held. Also have a timeline for how the person is approaching an issue.
hierarchy of how important people are. This org chart could potentially live in two places (not necessarily exclusively): a “tab” under the simulation overpage page, or a way of viewing the bios section by hierarchy.
physical location of the person/group maybe a popup reminding them to update location every 30 minutes or so. Location could be displayed on the profile page. If roles are assigned to a specific place, perhaps show where that “home base” is.
Stakeholder profiles includes descriptions as well as positions held on an issue
Digital incentives for accomplishments. Showing a list of tasks to be completed and awarding (with some sort of badge, etc.) the user when they’ve met the goal. on the overview page? on the person’s bio?
see who’s online right now needs more thought about where to show this. Possibly a way of filtering the bios page by who’s currently online?
General Resources
Group public resources like background research Someone like a stakeholder wants to research how voting a particular way would benefit them financially. Multiple people want to contribute to this note document. Should collaborative document editing be part of the scope of our development or should we just lean on an existing tool like Google docs?
Documents, videos and maps
Business documents Do businesses / stakeholders have documents created about them already? Or do participants want / need to publish documents about their stakeholder as they go along?
Way to contact groups or people to invite them to meetings, Group Chat (but in-person contact is still important. It’s just hard to get questions answered)
Social-media posts (Requiring separate social media account was a barrier to participation). Also, it was hard to follow multiple platforms at once
“News” (memos, articles) is this part of the live feed? Or pre-existing resources?
Schedule of the simulation. Segment the schedule through the day; Schedule for each day – (maybe tailored by role) Countdown to next thing Interactive someday? What does that really mean? How about “live”? Do the authors currently input a schedule that is tailored for each role? Is that data available? Are deadlines set specifically enough in time that we could show a countdown to the next thing? Countdowns are probably different for different roles.

Sample of the requirement analysis



WhiteBoarding / Sketching

First, we whiteboarded our ideas and brainstormed the designs. This helped look at the designs from multiple perspectives. Then,  I sketched out the different ways of laying out the features on the tool’s interface. The layouts were modular and the different sections could be moved around as the tool is susceptible to change anytime during the development process. Modular layout also allowed creating mobile and tablet versions of the interface easier. Few different iterations were made to make sure that the interface was in line with the requirements.



Wireframing and Mockups


pm1pm2 pm4

The sketches were finalized and I converted them into wireframes and mockups. These mockups were presented to the project management team. Feedback was received as to what features could be grouped together under different interfaces. The mockups went through a series of iterations to ensure that the users could find all the necessary features in the tool. The usability of the tool as a whole was also kept in mind.

Rapid Prototyping

The mockups were converted into a clickable prototype using Invision. This prototype helped determine the user flow of the application. The prototype also helped determine the number of clicks needed by the user to reach a feature. One Click Rule was followed-  “Every click or interaction should take the user closer to their goal while eliminating as much of the non-destination as possible.” – Breaking the Law: The 3 Click Rule. After we were happy with the end result, these prototypes were handed to the developing team for the development cycle.

Design of front-end CSS


Inspecting the elements to change the CSS

After the initial development cycle, I was given access to the CSS codebase in order to improve the front-end of the tool and make it more usable. I ensured there was enough whitespace on the UI and also that the elements had breathing space. I also performed multiple walkthroughs of the tool to ensure that the tool was not only functional but also usable. This helped me make the tool more usable by tweaking the front-end design and improving the look and feel of the tool.

User testing


MPLP session 

There were two user tests- an initial test to ensure the users understood the tool and its features. The test was a success and we gathered a lot of feedback for further iterations. We also got some feature requests that would be incorporated in future versions of Policymaker. The feedback helped us improve the usability of the tool extensively.

The second user tests took place at Michigan Political Leadership Program training where Policymaker was used in a setting close to the actual classroom scenario. The response was very good and the test went smoothly.


Finally, the MVP of the tool was launched mid-July and it is going to be used this Winter semester as a part of Integrated Policy Exercise course.