Dealmaker

Company Overview

What is Dealmaker?

Dealmaker is a Shopify like storefront for businesses to manage investments & crowdfunding.

More Information About Dealmaker

The earliest time you can invest in a company and receive shares is usually during an IPO, unless you fall under specific circumstances such as having a million dollars in the bank.

Enter Dealmaker, a company that opens up the ability to invest and support organizations or businesses and lowering the barrier to entry for the process. Through this process Dealmaker manages different raise types such as Reg CF & Reg A+ or provides services such as being the broker dealer for licensed jurisdictions in Canada and the US.

Created by two lawyers who specialize in financial law, it simplifies this process and acts as a cloud intermediary for the business and an investor. Letting investors and supporters order securities as quickly as ordering a pizza instead of weeks of legal work.

Now that you understand the company we can begin to dive into who exactly the users are with a bit more context.

Dealmaker's Users

The Investor & The Issuer

Who are the users?

This project currently focuses on the Investor. However, Dealmaker has 2 distinct user groups.

Dealmaker acts as an intermediary for its 2 distinct users user groups: the businesses using the Dealmaker platform and those investing or supporting businesses via Dealmaker and managing their shares through the platform.

On the B2B side, this would be CEOs, CFOs or legal teams. These would be the individuals directly acting in the investment deal or doing Investor Relations & Marketing for the firm. This group of individuals would be more familiar with the process due to a direct relationship with Dealmaker. If we return to the Shopify storefront example, the seller possesses an informational advantage over the buyer in terms of understanding the relevant terminology and key concepts. In this situation, we would would potentially need to adjust our language used as well.

Primary User: The Investor

What are Investors looking for on the support page?

Furthermore we need to think about how some of these different requirements come across to users. These are all different things that I kept in mind after understanding the users.

Exploring the Current State

What can we learn from the User Interface?

Exploring the UI with user requirements in mind helps us better understand the user flow we'd like to reach. We can then use these findings to address tangible how might we questions

Landing Page

One of the biggest problems is the lack of information and direction for the user. We're missing a clear hierarchy and navigation guidance. Even with this aspect ratio, you're probably squinting to see it 🔬. This is the first page a user is landing on when looking for support with a problem.

Cognitive Load & Applying Visual Hierarchy to Lower Complexity

We can begin to approach this with ideas about improving the hierarchy. As you can see a pretty uniform button set. We're lacking a hierarchy to guide the user throughout the page here and they're coming in with a problem and no idea how to fix it. You can also imagine the user's cognitive load trying to understand what their problem is from here.

Handling investments and having complex terminology while lacking context and a distinct visual guide. Would increase the complexity of navigating, and that can provide us direction for improvements. We'd want to lower things like complexity to ensure we're on the right side of Hick's law.

Based on these we can note the potential of adding more context to the page, as well as work on the contrast & the colour scheme to improve legibility.

Categories & Articles Pages

Both of these pages share some of the same issues we've seen on the home page, indicating that the style issues weren't limited to the home page. There is a lack of ideal colour usage for contrast as well as missing context on a few of the evaluated pages.

For example, in the eligibility to invest page, found above, I don't think the user would be satisfied with the above. With limited information, if they haven't chosen the correct page their only solution would be to continue clicking through these options.

There might be an opportunity to evaluate the content grouping, as well as condense the information provided on articles. "Do we truly need a page for under 400 characters?", this question can help us flatten the architecture based on the stakeholder response. As well as condense related articles into a better content grouping.

When taking a look at the user flow, we notice that for a user to navigate through the categories. There are a few more hoops to jump through, and each bad search results in them landing back to the very sparse categories page. Helping validate our hypothesis regarding the search path vs. the categories option.

Furthermore, there are parts of the page we can repurpose such as related articles. We can potentially include previews for potential sub-headings within the articles.

For specific articles, such as the one shown we can also identify that there is a lack of content, which will definitely impact a user's experience as they would have to return to the categories page or the home page and repeat the process.

How to improve Contrast & Colour

For improving Contrast, I'd use tools to check the legibility of the fonts with different backings. There would be tools like Coolors.co or WebAIM's Contrast Checker ensuring we atleast meet an AA rating. Although each of the following colours fall in that rating (3.46 to 13.95), we'll try and use the darker shades to improve contrast

What I learned from the UI

A few of the things i was thinking about

Problem Solving

What exactly are we solving for here and what is the scope?

With what we've learned the problems we're solving are the lack of context and guidance which will improve user experience as they can better navigate the page structure.

Problems

I tried to order these problems in terms of high-priority, to medium and low. As certain changes might require more of an in-depth content revamp.

Wireframing

Working through the layout

I went through a lot of stages of wireframes, and progressively improved upon them. Some of these issues would have been solved with improved process, but it was a learning experience.

Addressing Context

Improving the Wireframes

I wanted to find a specific solution that would help with navigating the different pages. I began taking inspiration from a lot of the documentation that I had been working with lately. As well as evaluating other large support pages to provide a bit of inspiration.

I began experimenting with what these sorts of layouts would look like. As well as thinking through the implementation on platforms like Mobile. This lead to a sidebar which improves navigational speed for the user. By making content more easily accessible.As well as a potential in page table of contents on the right hand side of articles on desktop.

With this current layout we can take advantage of some of the mental models around documentation and support pages more easily. This is because we're able to provide a more easily navigable layout and potentially decreasing the total amount of area we need to cover by reducing the page contents and organizing them more effectively.

Issues in The Process

What does this format solve?

I was quite happy with the current look of the wireframe, but I wanted to see how it looked in a bit more higher fidelity. As this format had made improvements on the previous by the creation of things like the sidebar borrowed from documentation as well as improving the area for context as well as CTAs for the user.

Mock-ups

Prototypes and Refinement

High Fidelity Drafts

For the first version of the high fidelity drafts, the problem that I ran into was spacing & color. Initially, I had used the colours like the off-white to enhance readability. However when asking for some feedback, I heard the dreaded words, the colour choice looked dated... rather than a more readable professional look 🤦🏾‍♂️

At this point, we've removed some of the excess information provided and split it between the different elements and specific areas. We've also added an introductory callout, focused on maybe leading first time users to an appropriate place. For example, a user like Michelle or Alex might explore things like these to understand more on the process. Rather than blindly navigating the landing page.

Getting towards the final designs.

You might notice how the spacing changes, one of the mistakes I had made was not identifying a robust layout prior. I had been slightly inconsistent with how I worked with the spacing system. However, I landed on using a relationbased spacing system. I designed with a standard spacing system in mind, the one we can use is based on strong & weak relation to the content.

I had also done some content grouping as well and tried to group the various articles together under common groupings to lower the amount of searching for the user and decrease the time spent in user flow.

With this design and the consistent improvements, we're getting closer to the final designs. Realistically if this was a true project, this section might be more related to feedback and taking in stakeholder opinions in regards to distinct design changes.

Final Designs & Handoff

How does it look?

After improving the design and distilling everything down I would work towards ensuring a smooth handoff. This is a little bit of a sneak peak as to how I would handle this or try to.

Colours

I began to convert the colours into things such as rgba values to make it easier to manipulate and work with.

/*Base Colors*/
--primary-color:rgba(35, 113, 107, 1);
--secondary-color:rgba(46, 153, 144, 1);
--tertiary-color:rgba(24, 78, 72, 1);
--primary-text:rgba(51, 51, 51, 1);
--secondary-text:rgba(128, 128, 128, 1);
                    

Fonts

/*Base Font Family*/
--ff-base:'Lato', sans-serif;

/*Base Font Size*/
root::{
    --root-font-size:1.125rem;
    --mobile-downsize:0.8;
}


/*We can do calcs to keep this more scalable*/
--font-xs:calc(0.75 * var(--root-font-size));
/*or choose distinct sizes*/
--text-base:1.125rem;

/*As well as potentially implement media queries to handle views*/
@media (max-width: var(--chosen-dimensions)) {
    root:: {
        --root-font-size:1rem;
    }
}

Spacing

We're going to be placing items with a higher relationship closer together. Where the margin also originates from the larger element. For example, our Display header will be more closely related to the Subheader than the body text. This is to help us create a spacial hierarchy

/*Base Spacing*/
--spacing-xs:0.25rem;
--spacing-s:0.5rem;
--spacing-m:1rem;
--spacing-L:1.5rem;
--spacing-XL:3rem;

Macro Layout

Here i'd also explain my process for the macro layout and expand on it a bit more. My goal with these handoffs is to make it as seemless as possible. Such that it could potentially improve the launch speed of a product.

/*Macro Layout*/
/* We could solve this with a flex or grid, but I chose grid here*/
.main-content {
    display:grid;
    grid-template-columns:auto 1fr auto;
    grid-template-areas:
    "sidebar content inpage_nav"
}

.main-content > article {
    grid-area: content;
}


.sidebar {
    grid-area: sidebar;
}

/* If we were building with mobile first in mind*/
/* we might even use media queries this way*/


@media (min-width:768px) {
    .main-content {
        display:grid;
        grid-template-columns: auto 1fr auto;
    }
}

/* set up some sort of container sizing if preferred */
/* Up to the teams discretion and preference */
.main__container {
    container-type:inline-size;
}

@container (min-width:768px) {
    .main_content {
        display:grid;
        grid-template-columns: auto 1fr auto;
    }
}

Reflection & Final Thoughts

What do I think about this now?