Web – Megan Jonas

Things I Wish I Knew Before I Started My Own Business

Posted by Megan Jonas On November 27, 2015

I graduated from college 10 years ago, and since that point, I have had a full-time, salaried job, until June of this year when I decided to go out on my own and start my own freelancing business.

Now that I’m about six months in, I have a list of things I wish I’d known when I started. Some of these things are practical, some are philosophical, but all are good advice for anyone thinking about going out on their own.

It’s better to start with systems than to develop them as you go
Pay for the accounting software
Your business name doesn’t matter nearly as much as your business structure
Working for friends can be a blessing, but it can also be the hardest client relationship to manage
Insist on signed estimates and deposit checks before starting a project
Hold on to your free time. Just because you work at home doesn’t mean that you’re always at work
Be confident in your abilities, but know when to ask for help
It’s OK to outsource things you’re not good at (more on that in my next post)
The worst part of any job is going to be billing – dealing with money sucks
Save everything – receipts, business cards, notes, emails, mockups, draft documents, checks, etc. – you never know when you’re going to need to refer back to something

And above all – remember the reason you’re doing this – whether it’s for creative freedom, the ability to work from anywhere, the ability to spend more time with friends or family, remember that reason and hold on to it. There will be hard, horrible days where you’ll wish you could go back to a full time job, or where you’ll want to fire clients, resign accounts, and quit projects. On those days, it’s important to think about why.

For me, there are multiple reasons why freelancing works for me, but one of the biggest is that life is short, and there is so much in this world that I want to see and do, and so when I have a hard day, I remember a raft trip down the Nolichucky river on a Wednesday morning, and how it was a perfect day, and how in my previous jobs, it was a day I would have had to miss, sitting instead in my office while the leaves went from green to yellow to red, and then fell off the trees. Those are the kind of days that make it all worth it.

Do you use checklists?

Posted by Megan Jonas On November 23, 2015

As I fly home to Denver today, I’m wondering what tools other developers use when setting up projects.

I have a questionnaire that I sent to clients before quoting a project that helps me get a sense of the type of website we’re going to build.

But I’m thinking of developing a series of checklists for new projects.

Collecting Logins for Clients with Existing Websites
Setting up a new WordPress installation
Plugins
Social Media Scheduling
Analytics and Adwords

Any others you’d like to see?

Social Media for Open Source Communities

Posted by Megan Jonas On November 16, 2015

This is the final post in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

For a community that prides itself on “openness” and “collaboration,” the open source community does not always readily embrace social media as a means to promote their projects and get people involved.

Rikki Endsley, from OpenSource.com, gave a quick rundown of best practices for all social media, and some of the key platforms in particular.

For those of us that do this for a living, her tips were not groundbreaking, but it’s always nice to get a quick refresher course on what we should be doing to promote our projects.

Her key takeaways were:

Send out Relevant, Interesting, Accurate Information
Know who your audience is
Craft your text
Use hashtags
Avoid PR Speak
Numbers do well
Ask questions
Images are very important
Retweet, Respond, Reshare, Reply

I think even experience social media professionals can use this refresher course from time to time, and it was an excellent way to talk about how Open Source communities can get out of their small bubble and welcome more people in, which was, after all, the point of the conference.

Open Government Data

Posted by Megan Jonas On November 13, 2015

This is the eighth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

In what was probably the most interesting session I attended in my two days at the conference, I listened to Mark Headd of Accela, Inc., talk about the issues with open government data, and how governments can really embrace the spirit of open data laws, vs. just adhering to the letter of the law.

This is the area in which I have the most experience, having worked and trained as a journalist and with the Code for Asheville brigade over the past year, and I found his perspective on the subject interesting and informative.

He advocates for eight principles of open government data:

Complete
Primary
Timely
Accessible
Machine Readable
Non-Discriminatory
Non-Proprietary
License Free

Citing data.gov and the 18F project of the federal government as models for open data, he noted that the culture change in the halls of government can be the biggest barrier to open data.

Most of all, though, he noted that the best way to encourage open data at any government level is to use it. That’s where local journalists and code communities come in. Build something useful and the government will see that their efforts to open their data and make it machine readable and timely are important to the people they serve, and the people who use the thing you build will understand why open government data is important as well.

Community Without Code

Posted by Megan Jonas On November 11, 2015

This is the seventh in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

In the final session on the first day, I attended a speech about how to contribute to the open source community without being a coder. This was not exactly what the speaker talked about, but it was interesting anyway.

He spoke in completely plain language about contributing to any open source project, including what first timers needed to know about GitHub. In addition, he recommended that non-coders use social media and blogs to promote projects that work, and that meetups and conferences were great ways to get involved.

If I have one criticism of the conference, it was that their “101” track still supposed that we were all hard-core back end developers with massive experience in the open source community. Hopefully next year, they’ll take the “101” idea to the next level and encourage speakers to develop sessions for those of us who really are beginners.

Can Design be Hostile?

Posted by Megan Jonas On November 9, 2015

This is the sixth in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

Sometimes when you’re at a conference, you go to a session where you think you’re getting one thing, and what you get is totally different. This is that session.

Hostile Design, a talk given by Shopify Lead UX Designer Cynthia Savard Saucier, was one I was looking forward to. In her session preview, she used the phrase “bad design can kill” and I thought she was going to talk about how poorly designed sites and projects can be painful to use (metaphorical pain here).

Her actual presentation… more of a tirade really… was about how a company’s clever promotion or user experience can actually hurt people (not metaphorical pain here) and how the poor design of her building’s evacuation alarm would lead us all to burn in a fire (not metaphorical fire here). Having trouble following her line of thought? So was I.

But there were a couple of key takeaways that I can get behind.

She started off with “the best designs don’t require instructions.” That is something I’ve been preaching for many years when it comes to web design. I had a client once who wanted instructional overlays for new users. Instead, I advocated for using standard web icons with tooltips, along with a simplified user experience.

The other thing I loved was the explanation of Dark Patterns, which are essentially web practices designed to trick a user into doing something that is in the company’s best interest, but not necessarily the user (Savard Saucier would be so mad about my repeated use of ‘user’ but that is what I do…). An example of this is opt-out email signups on checkout forms, or opt-out subscription services on a free trial signup.

This is the kind of hostile design that I’d originally thought of, and one that we can actually effect change on.

GitHub for Beginners

Posted by Megan Jonas On November 2, 2015

This is the third in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

The second session I attended at the conference was called “How to Start an Open Source Project” and it dealt with the nuts and bolts of GitHub and open source licensing and all those other intimidating things that keep people from starting and contributing to projects. The presenter, Don Schenck from Rackspace, gave a great overview of the process, from getting an idea, naming it, creating the repository (repo) and starting with the first file.

One of the key things he said to us was “once you publish your code to GitHub, it’s not your code anymore,” which is a way of saying that open source projects belong to the community. When starting a project, you need to be starting it with that in mind. If you want to control every aspect of it, then open source may not be right for that project.

He also talked about the need for a development plan: what needs to be done, in what order, and how to get people to contribute.

I’m still not sure I’m ready to create my own project on GitHub, but I’m at least a little more confident that I might contribute to one.

Constraining Design

Posted by Megan Jonas On October 30, 2015

This is the second in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

The first session I attended at All Things Open was in the UX/UI/Design track. The speaker Shay Howe from Belly described how design constraints can actually free a designer to do what they’re best at. Good constraints include a grid, font/typography choices, color choices, and any existing branding for the site, if it’s available.

“Narrowing your options can clarify challenges,” Howe said, and allow a designer to use fewer resources while maintaining consistent styling across iterations.

As someone who is working on a system to create design as good as my development, this really hit home. It is the reason I always suggest to clients that they should start with a style guide, or even a mood board, to give me constraints to work with. Taking away the basic decisions of font, color, and button styling allows me to spend my limited design resources on interesting elements that really customize a site.

Getting clients to see the importance of these style constraints is also an important part of the process. Clients want to jump right in to seeing a website in progress, and sometimes feel like developing these standards is a waste of time. Done correctly, however, it makes the development process much smoother and faster than the code first method.

“Constraints do not equal sacrifices,” said Howe.

Conference Notes: All Things Open 2015

Posted by Megan Jonas On October 28, 2015

Last week, I attended my first All Things Open conference. The conference focuses on Open Source software and includes speakers from major industry players like IBM, Microsoft and Red Hat.

This conference was a reach for me. I am not a backend developer and know very little about server-side technology or app development. But it was an important reach for me for a few reasons.

First, working from home means not having people to bounce ideas off of and not having those informal conversations that allow you to get new ideas and see cool things that other people are working on in person. Conferences can fill some of those holes for me.

Second, while contributing to open source software can seem intimidating (WordPress is Open Source), it shouldn’t be. The community is overall supportive of new people joining projects and wants to find new ways to include people who believe in the mission of open source.

Third, and possibly most importantly, spending time with people who are passionate about what they do, whether it’s the same thing I do, or something completely different, is energizing and regenerative. I came home from this conference convinced that I can build that app, finish this project and do something new.

For more on what I learned at the conference, check back in a couple of days.

This is the first in a series of nine posts on the All Things Open 2015 conference I attended in Raleigh in mid-October. For more information on the conference, along with videos and slides from the presenters, check out the conference website.

Design at the Speed of Digital

Posted by Megan Jonas On October 26, 2015

The web changes quickly and clients expect us to keep up. In this always on age, clients often want design projects turned around within a few days, if not hours.

The traditional agency is used to having a lot longer to do its work. Print deadlines are set many weeks in advance and work is signed off on a weekly basis, not hourly. But when you’re talking about small graphics projects for digital properties, or even iterative web design, those timelines may no longer work for your clients.

But how can you continue to produce excellent design work while working within these newly compressed timelines? Sometimes you just have to wait for inspiration to strike, and sometimes that doesn’t happen overnight (or over the next hour – whatever the case may be).

First, be honest with your clients about your workflow. Especially if you are single-person shop, like I am now, you need to let them know not only that it takes time to produce design work at the quality that they hired you for, but also that you have other commitments, and, at least in my case, you can’t rush the process or you’ll get flawed work that makes no one happy. No one, NO ONE is less happy with flawed work than I am. Not even the client who is paying for it.

Second, you need to re-evaluate your processes and see where efficiencies can be found. Some clients don’t need three mood boards, let alone six. The curse of digital can also be the benefit. You can check in with clients more often which means you don’t have to do unnecessary steps to hone in on a design.