And like most designers, I love what I do enough to put up with the annoying parts of the business (AKA: difficult clients who don’t ‘get it’). There were rare occasions in the past when I was able to design something fun, meaningful, or challenging for a client who did ‘get it’ and had enough budget to make it profitable. That’s when it didn’t feel like work at all, it felt like an awesome hobby I got paid for.
Now that I run my startup Proposify , I don’t design for clients anymore and that feels strange. Am I even a designer anymore without clients to push me? Without designer colleagues to critique my work?
Designing your own product sometimes feels like cheating because there is no middleman between what I design and the end user of the product, and that’s exactly what makes it challenging. Once the initial rush of freedom wore off, I realized that the filter was gone. Whatever I put out there will either work adequately enough to be ignored, loved, or hated, by a growing number of people. And that’s super scary.
I also get a lot less practice now. When I worked with clients I flexed my design muscles on a regular basis and worked on a variety of projects, constantly switching styles and creating new look and feels. Now I’m more like an in-house designer who works on one brand except I only design about 10% of the time, the rest is spent on customer support, marketing, testing and general “CEO stuff”.
Now that Proposify is a fully designed product with active customers it’s more about refining what’s there, so the changes are evolutionary, not revolutionary. I don’t get to stare at a blank canvas anymore, instead I get to tweak and (attempt to) perfect an existing product based on intuition, metrics, and customer feedback.
But last week I worked on one of the most fun design projects I’ve had in a while. I got to design the mobile app for Proposify. Let me walk you through the process.
(NOTE: For our Proposify customers reading this, I’m giving a sneak peek at our upcoming mobile app but have no idea yet when it will be released.)
The design process
Start with the why
As with any design project, you need to begin with a purpose. There’s nothing more deflating than beginning a design knowing it serves no purpose and will never be used. I have always imagined we’d eventually have a Proposify mobile app because... apps. But what would someone actually use it for? Is anyone going to write proposals on their iPhones?
It wasn’t until a customer emailed and then explained to me on the phone why we should have an app that the use-cases started becoming clear: people on the go need to be able to view the status of their proposals, respond to team and client comments, preview and send proposals, and review their pipeline and metrics. They also need to get push notifications when clients view, comment, or accept/decline their proposal.
I wrote those into my Evernote as a check-list of the design requirements:
- If you’re pricing out a client project, give yourself less budget for design and more budget for research and testing. Those are a whole lot more valuable and time consuming than the actual process of pushing pixels.
- When starting a new client project, don’t just talk to your client about what they need — talk to their customers, the people who will actually be using it.
Sketching designs before running to the computer is something that’s been beaten into me since I attended design school, and it never left me. I’m very sloppy when it comes to drawing, but that’s OK - my sketches aren’t for anyone but me. All they do is help me think about the flow and layout of each screen really quickly.
- A big part of your design is the thinking and sketching before you open up Photoshop (or whatever you design program of choice is). The computer just refines what you’ve already thought about away from the screen.
- It’s common in the web design world to design wireframes for clients so you can establish flow and layout without needing to show look and feel. However, I’ve long felt that wireframes are mostly unnecessary except in rare circumstances. Designing with typography and colors doesn’t take much longer than designing black and white wireframes. More importantly, these visual elements have a massive effect on the final design, so why save them for last? Show the client a sketch if you need to quickly communicate layout and flow before the design.
Fireworks & Invision - A match made in heaven
I’m going to go on record and say that I have loved Fireworks for web design since the early 2000’s and I’m not going to change any time soon. I’ve downloaded trials of Sketch and Macaw. I’ve used Photoshop on a few projects. I just can’t do it… Fireworks beats them all (but only because Macaw is early stage). Eventually I’ll have to change since Fireworks is being killed off by Adobe, but that’s a post for another day.
I created my Fireworks project at 960px wide by 4000px high (150 ppi) to give myself lots of room to work with and so that the images would look good on a smartphone display. The downside to this is that the canvas looks huge at 100% so I need to zoom out and scroll a lot.
Normally when designing I create a few mockups and then when most of the views are complete I’ll build a prototype. This time I wanted to make sure all the components of the design, font size, color, and screen size were perfect in one view of the prototype before needing to go into every view and change it, so my next step after designing the list view was to go right to Invision and drag in the first screen. Then I downloaded to my iPhone to view it in context right away, quickly realizing how badly it needed to change.
The first list view was basically cramming our desktop version down to a small phone size. That didn’t work because the text was too hard to read. I needed to cut some info out so I decided to take out the tag filter and status flags and use color to make it clear if the proposal is overdue, upcoming, or awaiting decisions. The problem was, it looked like ass and threw off the branding, so instead I used a thin strip of color to indicate the status without overpowering the design.
Happy with this, I began mocking up the other views at a pretty furious pace, and after every view I’d upload to Invision and look at it on my phone.
Invision lets you create an app icon and loading screen you can download to your phone for testing. This really lets you get a feel for the final product and gives you something tangible to give to users for initial testing before a line of code is written.
This project began at the beginning of last week and by the end of the week I had a design prototype to show to my team on our Friday afternoon meeting. In total, the time spent on this app was about 5 hours or less, including research, sketching, and polishing.
NOTE: I’ve been told by colleagues in the past that that I’m a very fast designer. I slam shit out at a breakneck pace. I’m not saying that to brag, a lot of this has to do with my lack of patience. I think I’m probably like some writers are who type fast because they feel panicked to get their ideas out on paper before they forget them.
I also think it’s more important to get something designed and out there to show people instead of fussing about with pixel perfection when it’s going to be re-created in code anyway.
None of this will go into production until I show some the app to some of our customers and talk to them on the phone about it. It’s so easy at this stage to change it, so I want to make sure all the core use-cases are considered and functionality added before building it.
I also intend to run the Invision prototype through Usertesting.com with a few people and watch them perform actions so any usability holes are caught up front. If you are a Proposify user and want to see the prototype and offer your feedback, please email me or Support and let us know.
Perhaps the most surprising thing about designing this app was how many ideas it gave me to make the main desktop version of the Proposify better. This shouldn’t be surprising to me since I’ve read Mobile First, but this was one of those “doing rather than reading” experiences where it opened my eyes to how much a desktop site can improve once you’ve designed it on a phone. I plan to implement these findings soon in the main desktop app.
Other miscellaneous takeaways
Aside from this mobile project, designing Proposify has taught me a number of other lessons I hadn’t learned from past client work that I wanted to quickly share here:
Users always need context. It’s so easy to bury a function in a settings panel or drop down. But that’s almost never where users look for it and they will email support. If a user is trying to change something, put the button right there where they’re looking, not somewhere else.
For example, early on we made users go to the theme to change their cover. But people would click on their cover page and have no idea how to change it until we put the button to change the cover right on the page itself.
Track everything and use data to drive decisions. We use KISSmetrics to track pretty much every button a user clicks. That way any time we need to run a report to see how often a feature gets used, the info is there.
We also use Groove for our help desk, and it offers analytics on what our users are looking at and searching for in our help widget, which helps me see what parts of the interface aren’t clear or need better documentation. It also lets me tag customer support requests with labels so I can see which topics they commonly need help with.
Actually use what you build. Sometimes startup founders rely so much on customer feedback and metrics that they forget to just use it themselves. Using your own product on a regular basis will help you find issues you’d never learn from metrics or customers.
You know the saying “There’s only one chance to make a first impression”? The first time experience for your product is more important than anything else. The people who engage with your product and stick with it will eventually get used to how everything works and come up with workarounds for things they’re trying to do.
But you can’t get people to engage or stick around if you don’t get them onboard in the first place. That’s why every month (at least) I go through the process of reading our marketing site, creating a trial account, and going through the onboarding steps. I often uncover small holes I can tweak to make that first time experience so much better.
Take time to second guess yourself. Every bad design decision costs money, whether it’s the time spent on engineering to implement and then change, or dealing with the resulting customer frustration that leads to support requests and possibly churn.
Take a bit of time to show it around to the team, get feedback from customers, and test it on a first-time user with UserTesting.com. Sometimes it feels like you’re slowing things down when actually you’re speeding up the process and mitigating risk for you or your client. You also build better relationships with your early customers by offering them a look behind the curtains at what you’re working on and that you care enough to get their feedback.
Even though I don’t design for clients, I still have people to please, like users and customers. Being able to design for them without the barrier of a client relationship has taught me a whole lot about how to be a better designer. You can use these same principles even if you primarily design for clients and not your own product.
Let me know what you think of these suggestions or if you have any to add yourself!