‍CoProcure is an early-stage startup on a mission to make government procurement easy. It's a huge market - after all, every local, state, and federal government organization needs to buy goods and services - but its processes are often painful and full of friction. Procurement officers tend to spend too much time on paperwork and herding cats, rather than on other areas that could be more beneficial (like coordinating better contracts and saving money).

The challenge was to figure out the best way for CoProcure to gain a foothold; the founder had already built relationships and amassed lots of user research findings. We used this information to brainstorm blue-sky ideas, then narrow down these ideas into MVP ideas, and then prototype some of the best ones.

Contribution

‍I worked with the founder, a product manager, and an engineer on early ideas, prototypes, and pitches.

Timeline

‍I've been involved since September 2018 on a part-time, as-needed basis.

Output

‍Low-fi wireframes, high-fi mockups, InVision prototypes, Figma prototypes, a searchable database prototype

My tasks were varied, depending on the needs of the company at that given moment. Startup life! Keeping it quick and light is crucial at this stage.

1. Learning about government procurement

Despite majoring in government and legal studies in college, I didn't know anything about the nitty gritty of government procurement. I learned a lot about how it works from discussions with the founder - its constraints, its opportunities, and its players. This is definitely a space where you want to do your homework before trying to "fix" it.

2. Wireframing and prototyping

We narrowed down all the ideas to a couple good starting points, and I spent some time exploring them with mockups and clickable InVision prototypes. One of them got built into the beta that went live and started generating user feedback.

For the next stage, I designed more detailed variations to test with our users to determine what should or shouldn't build first. It was a good thing we did, too, because certain features were completely overlooked by users, upending some of our hypotheses. For this phase, I chose to use Figma because of its built-in prototyping capabilities, plus the "observation mode" that made it easy to work remotely with the rest of the team as well as with our users.

3. Polish when necessary

Since it's an early-stage product, there was initially much less focus on achieving polish. We tried to be judicious about pushing something to a highly polished, high-fidelity state, since we knew that we needed to stay focused on making the tool work well, and gaining traction and trust with our users.

The goal: to use a lean approach to finding the best way to improve government procurement.

We're running a pilot with a small group of users with the current prototype: a database of contracts that's easy to search through. The problem was that although contracts are technically available to the public (and thus to all agencies as well), they were often scanned in, or lived in databases that didn't work very well or were difficult to update.

By starting with this user-friendly database, we're hoping to solve a big pain point for our users and encourage the sharing of contracts in one convenient location.