We've been playing with the first round of Help Scout designs for about a week and are ready to show how things are shaping up so far.

Firstly, design for a web app should start where people will spend most of their time. Start with what's most important, because nothing else matters if those pages don't execute well. For that reason, we started with the tickets view and the individual ticket page.

Objectives

1. Get out of the way. For Help Scout to be successful, it has help teams be more productive and save time while handling customer service. Since people will be using it every day, design decisions must be based on the utility and intuitiveness they bring to the software rather than the wow-factor.
2. Make it fast. In order to compete with desktop email clients (and popular web-based ones), Help Scout has to be really fast. Aside from the server/development stuff, HTML5/CSS3 give us the ability to minimize images and code. We're also using CSS sprites whenever possible and only use images when they benefit the overall experience.
3. Leave room for growth. We hope Help Scout grows tremendously over the next several years, so we're building a frame that can support items on our "someday maybe" list down the road.

Comps

The first attempt started too dark, but the layout was coming together nicely.

There's nothing like getting these comps into the browser as quickly as possible to see how they feel. Even though the design is at the beginning stages, we're working with coded prototypes to make it more realistic.

You can check out the version 1 prototype for yourself here- brightwurks.com/helpscout/v1/. The Open mailbox, Spam mailbox and top ticket from Cesar Milan are the only links that work properly so far.

What's Changed

We've already made some pretty big changes since the final wireframes. Here are just a few of note:

• The "Assigned" and "Pending" mailboxes are gone. We found a way to make those work in the "Open" mailbox. I love deleting stuff like that!
• We added "Mailboxes" to the navigation and made it a dropdown so you can select a mailbox from anywhere. The location feels a lot better there.
• On the ticket layout we made a HUGE improvement by adding a third column for customer information and history. This was definitely a lightbulb moment.
• The "New Ticket" button makes more sense in the Mailbox column for a number of reasons.

Next: Polish

Although we're happy with version 1 so far, these designs need a lot more polish. We've got some good ideas on how to do better in the next round.

View this post to make a comment.

Today we're going to show our third round of wireframes for Help Scout, which is the last before we bust open Photoshop and start pushing pixels around. I'm really excited to see how it all comes together.

Although these wireframes may look pretty specific, it's important to note that NOTHING below is sacred. Nothing is in stone. These images probably won't look anything like what we end up with. Putting anything in concrete at this stage is stupid, but wireframing is extremely important for setting a foundation. Nothing is final or off the table from a design/layout standpoint until we launch.

Major Changes

1. We started thinking through ticket "states". What's a new ticket look like, versus an open or closed ticket? I don't think we'll know this for sure until we design it.
2. On the individual ticket page, all the action buttons have been moved from the bottom to the top and we flipped the chronological order. Instead of the oldest update showing on the top, the most recent update will show on top and you can scroll for older updates.
3. We added in a button to "merge" a ticket, provided we are unable to match it properly.
4. We changed the location of the attachments. The old location is not intuitive at all. We're also thinking about using Gravatar to pull in customer images and more information about them to place on the left sidebar. This could be neat.

To see how these wireframes evolved, check out the first two rounds of wireframes:

• Wireframes: Version 2
• Wireframes: Version 1

View this post to make a comment.

We're so excited to show you guys the final Help Scout mascot today. After lots and lots of tweaks, he is finally finished. He doesn't have a name yet, though. Any suggestions?

Now that the mascot is finished, next we'll be choosing a font for the "Help Scout" part of the logo.

To see what went in to creating the mascot, check out our other posts:

• HelpScout Mascot: Sketches Round 1
• Help Scout Mascot: Round 2

View this post to make a comment.

You may have noticed in our last couple of posts about Help Scout, the name has been two words instead of one (HelpScout). When building a web app, this is something that requires more thought than you may initially think. The domain, of course, has no spaces, leading many to leave out spaces when talking about your app. Is there a right way and wrong way or is it just a personal preference?

In our opinion it doesn't really matter either way. It's all about how you present the name in the logo. As long as it's clear, consistent and easy for people to understand/pronounce the first time, it's a keeper. We've technically gone both ways in the past. Feed My Inbox has always been three separate words for us. However, Linkpatch was always one. In both cases it came down to how we presented the logo.

If you decide to combine a couple of words for your app name and keep it as one word, the logo must visually define each word so that the logo reads more clearly and is understood more quickly. FreshBooks does it through capitalization and changing the color. Salesforce does it by changing the color and the type. Both are very effective:

The main reason we chose two words for Help Scout, each capitalized, is because we've already got plenty of visual stuff going on with the mascot. The type will be pretty simple and straightforward. So in order for people to immediately make the distinction with our service in reading the name for the first time, we think the space adds more clarity.

There isn't a one-size-fits-all answer to this question, but it's definitely something that must be considered during the logo creation process. The last thing you want to do is create any confusion.

View this post to make a comment.

After sketching out some good ideas on paper in round one, we finally took to Illustrator and Photoshop to create the Help Scout mascot. We've spent several hours working on him so far and I'm really excited about our progress. The face still needs more time, as do some minor shadows and such, but it's pretty close. Take a look at how he evolved:

View this post to make a comment.

After spending some time away from the first version of wireframes for Help Scout, I came back and couldn't believe how complex I had made our little app. What's with the bar graph on the dashboard and the messy ticket screens?

Round two was all about simplifying, stripping away anything that wasn't a "must-have". I started with a blank slate, thinking through every bit functionality in these pages again. Here's a summary of the major changes that took place from round 1 to round 2:

1- Took the "customers" section out completely. We can build that out later if we ever need it. For now, customer information will only show up when you are viewing a ticket from them. We also took "Mailboxes" out of the navigation and link to mailboxes in the left sidebar.

2- We switched out "Settings" and "Help" from the two navigation areas in the header, thinking settings is much more important. Settings is where you edit mailbox information and configure a bunch of other options, so it belongs on the main navigation.

3- The tickets layout is far too complicated. We simplified it a great deal by moving all the ticket actions off of this screen. If you need to assign a ticket or change the status, just click on the ticket. Provided the screens load very quickly, it's a worthwhile trade-off considering all the free space we gain.

4- We ditched the idea to stack the tickets view and an individual ticket, a la Apple Mail (screenshot). It may work well for a desktop client, but I hate the scrollbars and there's still too much going on.

5- The "header" of each ticket was also a mess in the first round. It's been re-worked, with functionality being placed more intuitively throughout the page rather than bunched up on the top.

We're much closer after this round, but still need another go to finalize anything. The next set of wireframes is the final round before we open Photoshop and start having some fun.

View this post to make a comment.

In the last post I mentioned that the new name HelpScout was ripe with branding possibilities. We think it needs a mascot, so we've spent a lot of time working on it while we finalize more serious stuff like the wireframes. Here is the first round of (very) rough sketches ...

View this post to make a comment.

This isn't a Lebron James press conference, so we're not going to waste any time keeping the world waiting (and we know the world is waiting for this ... ha); we'll just tell you what we chose as the name. The new name for our customer service app is HelpScout.

Why we chose HelpScout

The Branding Possibilities are Awesome

We were immediately excited about branding this name. It's the perfect name for us to create a mascot of some sort. For all that MailChimp (logo here) has done for monkeys, we could have the same sort of impact from a branding perspective with HelpScout. We think this is a HUGE plus.

We Like the Connotation

While none of us have ever been boy scouts, we like what they stand for: teamwork, honor, helping others and hard work. There's enough here for us to market the app to customers without having to explain the name every time.

It Works for SEO Reasons

In the last post we mentioned that it would be a nice boost if "help" were in the name. Considering what a competitive field "help desks" are (even though we're the anti-help desk), we instantly helped ourselves by getting a domain with one of the main keywords.

It's Short, Easy to Spell and Easy to Remember

Enough said! It passes these three tests with flying colors.

So far we have two domains, HelpScout.net and HelpScoutApp.com. HelpScout.com is a squatter of some sort. We're hopeful that maybe we can grab the domain at some point, but it's not a big deal either way. We don't have any actual competition with the HelpScout name, so we're moving forward.

Don't Forget to Make Sure You Can Use the Name

Before you register or publicize a name for anything, make sure you can legally use it. All you have to do is a Trademark search on USPTO.gov (in the USA) for the name. Go through any existing trademarks with the same name and triple-check that they are not in the same or a related business. Consult your lawyer for specifics, but if there are any web services with the same name as you, it's better off not to use it.

You don't have to register the trademark officially right off the bat, but you do need to make sure it is available and be the first one to use it publicly. We'll be registering the HelpScout trademark upon launching the site, but since we're actively talking about it on this blog we will have legal rights to it, even prior to registering it.

37signals made this mistake rather recently, with an application they released called Haystack. Due to trademark issues, they had to change the name to Sortfolio and update all the branding. It's worth doing a little homework upfront in order to avoid these kinds of problems.

View this post to make a comment.

Opinions vary regarding the importance of a name. Since it's something we're going to live with for the long-term future, I think it's very important. Sometimes they come easy, but usually they don't, so be patient and don't decide on anything unless you live with it for a couple of days or more.

I think naming a web app should require a whole different set of rules compared to naming something that exists predominantly offline. Here are the things we consider when creating a name, in order of priority:

1. Make it short and sweet. One or two syllables is ideal.
2. Consider how easy it is to spell. We made this mistake with naming Brightwurks and I would take it back if I could. Don't name an app based on a misspelling. Also, try to cover your bases with any common misspellings of the name you come up with.'
3. Is it SEO friendly? This varies in importance, but for us it's very important. The "help desk" market is very competitive, so ideally it would be great if the name included "help" or "desk" somehow.
4. Get the Dot Com. In my opinion this is becoming less of an issue on the web. As long as someone types in the name of your app in a search engine and you are #1, I'm not against a dot net or variation of the dot com. Don't ditch the perfect name just because of a stupid squatter on the dot com. Chances are you will have an opportunity to get it at some point.
5. Does the name adequately describe the service? I think this could go either way. There are great examples of both, but it's a nice bonus if your name does describe the app in some way.

I've heard people say you should spend anywhere from 20-40 hours naming your app. I disagree. You'll know the right name when you find it. It may be in hour 2 or hour 38. Just exhaust every possibility until you find the one, no matter how long it takes.

Another big thing when creating a name is to know when to start and when to stop. Only work on it when you feel inspired, and stop when you hit a wall. Banging your head against the wall for hours typically doesn't produce results; it's a waste of time. I find that all my best work is done in the first half hour, then I have to move on and come back another time if nothing materializes.

What You Need

• Pen and paper ... don't let one thought or idea go through your head without it being written down. Keep it all.
• Dictionary and Thesaurus
• Domai.nr for quick domain research
• Co-founders- our most productive "namestorming" takes place collectively rather than individually, although we still do both.

Initial Ideas

For this app, the big idea we want to convey is teamwork. This is the best application for people to collaborate on email and work together to communicate with others. If we can find a way to say that in two syllables it would be awesome.

Right off the bat I thought we had a winner in the name "Huddle". In my opinion it was a great visual for what the app does and I was willing to go without the dot com name. However, many of you may already know about Huddle.net, a project management app based in the UK. They have a good thing going and we weren't about to create any confusion or legal battles there.

Several more brainstorming sessions went by, both individually and with our team, without anything really popping. Here's a list of some of the words we had on the board so far:

• Herd
• Flock (taken by the browser)
• Tribe
• Chief
• Army
• Colony
• Swarm
• Tribe
• Pack
• Hive
• Team
• Peep
• Clutch
• Cartload
• Rake
• Band
• Sedge
• Leash
• Kennel
• Pod
• Gang
• Mob
• Cast
• Knot
• Gaggle
• Charm
• Glint
• Group
• Array
• Nest
• Stable
• Troop
• Scout
• Clan
• Lounge
• Zeal
• Unit
• Force
• Clique
• Social
• Convoy
• Fleet
• Crowd
• Mass
• Crew
• Jumble
• Bunch
• Bundle
• Medley
• Cluster
• Marvel
• Enhance
• Shepherd
• General
• Chorus
• Tandem
• Choir
• Harmony
• Harmos
• Sync
• Collaborate/Collab
• Hub
• Pilot / Co-pilot

So we had a big list of words, ideas and terms, but nothing really solid for a name. A couple more weeks went by before we finally came up with the name in a group chat at the office. Stay tuned to the next post for what we chose and why.

More References on Naming an App or Company

• Carsonified: How to Name Your Company
• Guy Kawasaki: The Name Game
• The Name Inspector: 10 tips for naming your company, product or service

View this post to make a comment.