Founders Grants
A site for early entrepreneurs and founders to find small grants
Role
UX/UI Designer
Duration
8 Week
Deliverables
User research • Wireframes • High fidelity prototype
UX/UI Designer
8 Week
User research • Wireframes • High fidelity prototype
Founders Grant is a site for early entrepreneurs and founders to find small grants. Before Founders Grant, there wasn't really a database for people to find grants. You either had to do a Google search or if you have some connections, you could find some grant spreadsheets. Founders Grant looks to even out the playing field and make it so everyone has access to this information.
The project came from a partner of the 1517 Fund, a fund for early entrepreneurs. The project was initially named "startup grant database" (awful name, I know), but that name was just a placeholder.
The goal of this project was to deliver a grant database where users can find grants. The goals were: a clean interface and a scalable platform for future developers.
Why was this particular database needed? Because grants are all spread out through the internet — all the grants aimed at this small group weren't in a single place to be searched and browsed. There were two ways to find grants, the first one is Google, of course, which returns every type of grant and article about them. The second one — a very exclusive one — were spreadsheets with lists of grants, but only people "in the know" had them and then shared them with others. It wasn't that they kept them secret, but they weren't out in the open either.
The users, as the name suggests, were startups. But they don't need to have a startup to use grants, they can just have an idea and need some funds to develop it or validate it. Learning this made us change our focus from startups to entrepreneurs. It also affected the name, which ended up being Founders Grant. More importantly, it changed our approach.
After interviewing some entrepreneurs, we confirmed that, yes, finding grants is indeed hard. One of them said the hardest aspect for him was:
Researching and finding the right one for my business.
Additionally, they also noted that while finding a grant is hard, the harder part is writing the application. One of them said:
Finding grants is hard, applying for them is harder.
While this falls out of the scope of our involvement in the project, it makes me curious to see if there are ways we, as designers, could solve what seems like a real pain point.
A study by Babson College and London Business School’s initiative called the Global Entrepreneurship Monitor found:
… that 27 million working-age Americans—nearly 14 percent—are starting or running new businesses.
27 million — I’d say that’s more than enough users. Also, this only in the US, the stakeholder’s goal is for Founders Grants to be a global site. Obviously, this requires some work to put the name out there and get grant providers, all over the world, to put their grants on the site. Unfortunately, that outside our purview.
When we performed the competitive analysis, the only site we found to be similar enough was from Singapore, which only helped Singaporeans. All the other websites we found offered their grants. So no "Google" for grants.
The stakeholder provided us with a scholarship site whose layout he liked. Based on this, I decided to do an indirect visual competitive analysis.
The site provided had a column of filters on the left side, and a list of scholarships, with a rectangular card format, that took most of the screen in the center. This pattern seemed familiar to me, but I couldn't place it. Until it hit me — job search sites!
The activity of searching for grants mirrors that of job-searching. Users navigate through a list, make sure the one selected applies to them and save it, and fill the application later. After a Google search, I took screenshots from Indeed, Career Builder, Glassdoor, and Google Jobs. What I liked better than the stakeholder's resource was how all those sites when you clicked on the job card they would display the job information on the same screen. No loading another screen, no confusion when clicking on the apply button, then closing it and losing the tab the user has been working on — everything in one place — concise.
One of the challenges we had was creating the style guide since we had limited time. So I went back to the 1517 Fund site and got the colors and typography from the site. But by using lighter shades and tweaking the typefaces, our site develops a style of its own.
The original typefaces used by the 1517 Fund were Proxima Nova and Adobe Garamond Pro. Both required either payment or a subscription for which we had no budget, of course. Luckily, Google Fonts has EB Garamond to replace Adobe's version, which left Proxima Nova. After searching around the web looking for articles that provided a list of suggestions for replacing Proxima Nova, which yield no results, I went back to Google Fonts. Eventually, I found a handful of san serifs that could work.
After making various versions with all the different san serif typefaces, we concluded that Nunito Sans (not to be confused with its rounded-ends counterpart Nunito) would be the replacement.
I got the color palette from the 1517 Fund site. It only had two grays, black and white, and teal for the accent. So during the first stages of design, I stuck with those colors until more shades were needed. Some time into the project, hover and pressed states were required, and by then, the site had developed enough design-wise that I could take the time to experiment and create those shades.
By the time we were designing the grant submission form, the need for error states had come up, and I went back to the style guide and developed those colors. An orange with a similar tone to the teal, not too bright, not too dull. Also, its hover and pressed states variations.
In the developing front, a team, we decided on the Google Material design system.
The grants list is where users will spend most of their time. The app wasn't big at this stage (or even by the end of the project), and this screen will have pretty much everything that entrepreneurs will need to search, filter, find grants and save them.
Drawing from the job search sites, I came up with this initial layout for the site. It has the grants lists on the left side. The information on the center changes for the selected grant. And lastly, the filter on the right side. Additionally, it has a search at the top to look for a specific grant in case they know of one.
This layout is economical in its use of space and contains all of the information on one page. Like the first draft, this page was a little sloppy, and through an iterative process, we ended up "beefing it up" with features and better information hierarchy.
'Kicking it up a notch by adding the colors and images. One of the good things about this project was that the stakeholder gave us the list of grants they were using, making it possible not to have dummy text from the get-go. Having it helped size the elements to hold enough information to help users gauge interest in grants. Also, having everything in one screen grant searchers don't lose their place in the list, which sometimes happens when navigating these types of sites.
After some preference testing and user testing, this was the final result. In the initial design, the grants cards had the grant's name and a bit of the description. That changed to have more relevant information, such as the grant's expiration date and amount of money. This change was due to the time it takes to complete the application. But also so they can gauge if the amount a grant offers is worth the effort.
Moving onto the description, here I decided to split it into horizontal halves to have the administrative(?) information on the top to be read at a glance, and the description in the bottom half. I made the page look a lot more organized and gives it a better hierarchy. The filter remained pretty much untouched — we decided to make the filter bar collapsible, and that's about it.
After working on the list page for about a week, I realized we needed a landing page of sorts. The idea of searching for grants and just landing on the list page didn't seem like a good experience for me. But what should be on it? Should we explain the site? It isn't a marketing page, after all. We put the following sentence:
Search lists for grants by choosing a category or as many as you are eligible for.
Additionally, we give users the option to either browse for grants or apply some filters and perform a narrower, targeted search. The other designer and I came up with our versions for this home page, and we had to decide which one was better. I did the first version (below), which, again, splits the page horizontally, which depending on the screen, could lead to the filters being under the fold.
The image above was my partner's version; she split it vertically, allowing the information to be on the screen without the user having to scroll.
We put together some tests and sent them out. The response was pretty clear, with 94% of users choosing my partner's vertical design. The people who took the test indicated that the winning design was easier to understand.
To allow people to save grants and access them on mobile or other devices, we added the ability to sign up on the site. Talking with the developers, they said users didn't need to sign up to save grants, but they'd only be accessible on that device, and the only way they would be able to access it elsewhere would be by emailing them to themselves.
One of the stakeholder's requirements was to have the ability to create and submit a grant. This way, it's not on them to keep adding grants but, almost, anyone could add their grant. This step came midway through the project and right before the admin side. The admin is a role needed to verify the accuracy of submitted grants, among other tasks.
After drafting up a couple of versions of the grant submission form, we moved on with this one before arriving at the final version. To design it, I had to go to the Google Material form documentation to make sure the style fits our design but that developers could use it as well.
At this point, we were pretty sure that this 👆 would be the final version. Then, one of the developers found this pattern that splits up the forms into "chunks" (why didn't I remember that!?), but it looked un-polished. So I took it and made it fit with the style of the site. When it came to the organization, I deferred to my partner to organize it into chunks that made sense. I had spent so much time on the form that all the information seemed related to me. My favorite part was the top indicator to let the user know in what step of the process they're at the moment. The submit button is also in an inactive state until the user fills all the required fields.
One detail we added was that once a grant was submitted, we give the submitter the option to include their email. This way, they can be updated about the grant's status if any issues arose or approval notification.
Here's another feature related to the admin — users can report grants. It could be something as big as the grant being a scam to something small — like a typo.
In the next section I'll go over how admins can fix reported issues.
The administrator role is the person who vets the submitted grants and deals with the reported issues or suggestions. At first look, the site looks identical to the user side, which was a conscious decision that allowed the developers to reuse those components. What changes in the context.
The grants list now has a more of a to-do list role with the newly submitted and reported ones at the top and marked with a green dot. Additionally, the bookmark icon on the top right corner got replaced because an admin wouldn't need it. Instead, I placed an edit icon here so the admin could have quick access to edit mode.
If there are various of these, they go to the top of the grant list with the older ones following.
Following the to-do concept, if a grant is marked because of a report when the admins go in, they'll see at the bottom reported issues. If they don't think the problem is justifiable, they can reject it, dismiss it or accept it. Then go into edit mode (at the top of the grant info or the grant card) and fix the reported issue. If, as it works on the user's side, the user-provided their email, they'd be notified once the admin chooses to reject or approve.
Upon revisiting this section later, I would've like to put some safeguards. An admin could approve (acknowledge) an issue but not fix it since the edit action is separate. In retrospect, I would've disabled the approve button until the admin goes into edit mode and save their changes. Then it can be marked as approved.
As mentioned before, admins are the ones who review and accept or reject grants. Additionally, they also edit and delete grants if something is deemed wrong with a reported grant. I added a modal at the bottom from where they can reject, edit, or approve new grants. Approve and reject are sort of seamless in terms of what happens after either action. If approved, users can now see it, if rejected, it disappears. The behavior changes when it comes to editing a submitted (reported, or needs-to-be-updated) grant. And here's how I tackled it by…
Well, look who's back! When designing the edit screen, since we were porting over from the user side and reusing those patterns, we ported over the broken up, 3-step form. But then the admin would have to go back and forth between the steps to verify and fix things. And on top of that, they would also have to wait for the next, or previous, step to load. In this case, it might be better to have everything on one screen — because scrolling is faster.
The other thing I added was a similar component as the one for accepting or rejecting grants. Except this one has canceled, to exit out, delete and save if there are changes. In the first design, I placed one on the top and one on the bottom, thinking this would make it easier. Then I remember this "thing" called sticky and just made it stick to the screen's bottom. Once the task gets completed, they could exit without having to scroll to the end in either direction.
Two or three weeks into the project, discrepancies between the design and the development came up. At this point, we expected it. We, the designers, went through both the design and the site and made a list of the discrepancies. Then, we put that list on Trello for the developers. Additionally, we provided the correct code for every wrong color that would replace it, same with the typography. As my first time working with developers, this was a teachable moment about priorities and our different perspectives and bars of quality.
For the next team to work on this project, their task will be to work on the moderator role. Which essentially is a junior admin. This was a requirement from the stakeholder, and without working on it, I can't say I understand the difference. Like what could an admin do that a mod couldn't. The main thing would be to define the role — then the design.
As my first experience working with developers, I learned a lot about both the design and development process. Out of all of the projects I’ve worked on, this was my favorite. I got lucky to be in a team where teammates respected and listened to each other. The final result it’s one I’m very proud of, probably my best work.