My first milestone for the new product is to test it out in front of real people. So, next, I’m going to launch a landing page, try to collect email subscribers, and try to learn more about how users feel about this concept.
I do this on every product, and recommend it for all my clients. Creating a teaser page gives me the chance to explain the product, gather feedback, and get at least a rough indication of whether I could successfully market the business. It’s critical to know early whether I can gain any kind of traction, because I don’t want to build something people don’t want and that I can’t sell. Research is great, but nothing beats a real reaction from a real user.
So, I took a week to design the brand, key parts of the product, and a new landing page to show it all off. Here’s more on my design process and the decisions I made.
How much design is enough, and how much is too much?
Early in the lifecycle of a product, it's tempting to try to solve every detail. But early design concepts should be focused around trying to identify the right problems, outcomes, and features.
In the past, I created designs thinking I knew exactly how to improve workflows for users and found they didn't want my solutions. As designers, there is a constant temptation to arrogantly believe you know better than your users. We know interfaces and can find the best way to design for any task. But the best way in our eyes doesn't always match the user's perspective—and as a solo founder I've seen that ruin entire businesses I've started.
So, I learned the hard way to build user testing and evaluation into my early design phases. Generally, here's how I decide how much design is right:
Too much design: if I don't have any real user reactions, and scrapping the work would be painful, I spent too long on the design.
Just enough design: If the concept is clear enough to gather user reactions but small enough I wouldn't feel crushed to throw it away, I've done just enough work on it.
My product’s focus: implementation phase and long-term product design
As for my new product specifically, here’s how I decided on the specific functionality and workflows.
My early research into others’ product design process revealed a bunch of phases where teams and individuals hit speed bumps and even conflict.
After design handoff and during the implementation of a new design or feature, designer and developer teams often run into problems. Also, long-term, ongoing projects (like CRO, evolving web app features, and design system updates) are difficult with current design tools because mockups always end up out of sync with what the live website looks like.
But designs have to get built, and teams have to keep going. My target users have devised a bunch of workflows to keep projects moving, but there are several that I think are painful enough to address with a new product:
While a developer is building from a design mockup, the designer is responsible for ensuring accuracy and addressing any gaps the design didn’t cover. Designers tend to do this by:
- Open the staging site in devtools, make some edits —> take a screenshot —> write up a list of the changes —> share via Basecamp, Slack, email, etc
- Using Git, pull the developer’s branch —> make a new branch and add edits —> push to remote repo —> post a screenshot in Basecamp, Slack, etc
Workflow #1 is tedious for the designer, especially if they need to redo this for several changes or make further edits after discussing with the developer, and workflow #2 required relatively advanced coding skill for the designer to be able to contribute production-quality code in whatever languages and frameworks are in use.
While a designer is creating enhancements, updates, and additions to an existing web property, they need to build their designs on top of what the website currently looks like. Designers do this by:
- Use devtools. (Same as #1 above.)
- Write complete code in a new git branch. (Same as #2 above.) (The Basecamp design team shared a public example of how they do this.)
- Update the last set of mockups (or create new ones) to match any changes that were made to the site since then —> do new design work
- Write custom bookmarklets that inject code changes into the page (the Medium design team wrote about this)
Workflow #3 is probably most common from what I’ve seen, but it is also a lot of work. I’ve spent many hours throughout my career updating old design files, taking screenshots of websites and editing them in photoshop, and so on. Not fun. Workflow #1 is again just as tedious as it was before, even though the designer is creating new designs rather than collaborating with a developer. Workflows #2 and #4 again require relatively advanced coding skills for the designer.
My solution is to replace these workflows with a new tool: a browser extension that captures edits made in devtools, takes screenshots, and publishes everything to a private url where anyone can see a code diff of all the changes and have a discussion right on top of the design.
This solution removes the lengthy, tedious workflows of #1 and #3, and removes the need for advanced coding skills in #2 and #4. it also works in a familiar way since it matches workflow #1 so closely.
The features to see a detailed code diff, before & after screenshots, and comment dots on top of the screenshots (just like in design mockup feedback tools) remove a lot of the back and forth that happen during these workflows where a designer sends changes, the developer doesn’t understand or disagrees on a point, and the whole thing starts over. These features show every change very clearly and in context, so no one is getting confused in Slack about which staging server or branch to view, etc.
The name Mod&Dot comes from the two core features of the app: first, the ability to create website "mods"; and second, the ability to add comment "dots" on top of the design for discussion.
Strengths of this concept
- Doesn’t force designers or anyone else to switch the tools they use for their primary work. No major change in behavior required, which hopefully will make users more likely to try it.
- Fits in just 1 phase of the process. It’s focused and easy to understand when you would use it: during implementation or when planning & exploring design updates.
- Allows me to focus on the expert portion of the design & web professional audience: people with active client/work projects, who probably know at least a little html, and have enough seniority to be involved during implementation.
- Browser vendors could eventually make much of my product part of devtools itself, invalidating the product.
- The audience could be too small. Designers who can code are often called "unicorns", after all.
- The outcome of working on live sites in devtools might not be compelling enough. It could be too small a frustration.
- Providing a new area for team discussion might be a tough sell, since so many teams already have slack, basecamp, etc.
Browser extension design mockups
Here’s how the first draft of the browser extension would work. My main goal for these mockups is to emphasize how it tracks and saves edits inside devtools for the purposes of landing page.
I didn’t design all the pages within the extension, just the ones that show key points of interaction so people would understand how it works. I’ll design out the full thing later after I see what people think, so I’m not wasting any effort right now.
Web app design mockups
For the web app portion I went a bit deeper, designing a few more pages because it’s a critical part in understanding the value of the app. Most of the value happens at the unique url where people share their ideas, so I need to make this part clear.
That said, there are a bunch of pages I didn’t design, like the user account, list of projects, sign up, log in, etc. Those things will wait for now, because I don’t need them in order to explain the product concept.
Users commenting on a screenshot of the original page.
Users commenting on a screenshot of the edited page.
The comment feature will work very similar to design mockup feedback tools. The great thing about this method is that it allows people to discuss specific points within a design, but without having to draw red arrows on top of screenshots.
Viewing the code diff listing all changes to the page.
The code diff is what I think will be my killer feature. Showing exactly what changed in the source code of the site will make implementing any of the ideas much faster. Sure, the designer might not be writing perfect code, but it gives the developer a clear idea of what changed and where the changes would go in the real repo. Many could be a straight copy and paste, no need to rewrite from scratch.
I considered the idea of making the code edits stored in a diff or patch that could be downloaded and applied via Git. However that feature got very complex very quickly, as the browser has no way to tell how html gets rendered by the server (such as a header from a php include, body from a template, etc). Further, I think the separation between the edits and production code makes the concept more liberating—removing the burden of writing perfect code frees up everyone to explore. I think that’s central to the audience’s goals for this phase of the design process.
Landing page & brand design
(click the image to see the full size mockup)
A quirky sans-serif typeface, Poppins, forms the foundation for the brand. It feels a bit serious, with a few unexpected shapes like in the ampersand, that designers will appreciate.
I also chose to use brutalism and anti-design elements (the brighter, almost clashing blue and yellow colors, extremely high contrast, heavily manipulated photos, and large bold text). Brutalism has been getting some attention in design circles, and I hope my use of it appeals to designers. Also, it’s been fun for me to work on, which is important because I hope Mod&Dot will grow into my core business for the foreseeable future!
Week 2 was: fun and nervous
Designing Mod&Dot was a joy. I had a blast with it. I felt that my experience as a designer and my research gave me a lot of depth of understanding of the user challenges and that my solution is elegant.
I hope other people agree. I’m nervous about how the audience will react. I want it to work out!
I’m taking another day to build and launch the landing page. Let’s see what happens.