Instead of an event filled with speakers who talk at you, we wanted to create an event where you could interact directly with an expert about their crafts, their stories, and their life’s good work. We also wanted to keep it local to build community and increase awareness about the talent and knowledge in our own backyards.

What do you love? What do you itch to know more about? 1on1 is an opportunity to talk with someone who’s passionate about things you’re also passionate about — whether it’s professional or personal. Each attendee will get 30 minutes of personal one-on-one time with their chosen expert as well as the opportunity to make new connections with attendees or rekindle connections from the past.

nGen Works is taking on the role of an incubator these days, which means we can connect with each other and launch projects and events like 1on1 while balancing time on client services. This allows us nGeneers time to kick ass and do great work for clients, but it also lets us spend time on the things we love while fostering growth in our local communities.

We’re very excited about this initial 1on1 Seattle channel, and want to bring it to other cities later in the year. So, if you’re not in Seattle, stay tuned for new events popping up around you.

Visit the site at https://1on1.ngenworks.com and register or share it with your Seattle area friends.

Update #1

Ladies and gents, I’d like to introduce you to Jen Hyde. Jen is a friendgeneer who started helping us a few months ago. She’ll be blogging regularly on Hapyn, beginning with this first post. When we started playing around with the idea of live blogging this project we wanted to make sure we had somebody dedicated and impartial reporting everything. Please welcome Jen and enjoy her coverage of the Hapyn project!

Three words came to mind as Carl pitched me on a new project called Hapyn™: vague, but exciting.

Tim Berners-Lee’s boss wrote these same words atop Lee’s 1989 proposal for the World Wide Web, right before the project was shelved for 18 months. Lucky for you, me, and the LOLcats, Lee and his colleagues rallied together to bring the idea – the web – to life.

I wanted to reframe the way we use information, the way we work together. – Tim Berners-Lee

As Carl talked about birds flying in unison, I thought about teams and ideas and pitches and packaging. Hapyn had an intriguing idea and a solid team behind it. So when Carl asked if I wanted in on the project, I of course said yes.

So here I am, describing Hapyn. Hapyn isn’t about features, or other apps that kinda sorta do similar things. It’s a story about improving the way we come together to accomplish things. It’s a story about facilitating collective action modeled after collective behavior. It’s a story that Carl, the self-described “deviant hippie trying to make work fun”, almost passed up.

That’s right, Hapyn almost didn’t happen.

nGen was set to turn down the project, but the client asked for a call before they did. So Carl got on the phone, and the client talked about birds. And fish. Swooping and swirling together. Turning in sync, right down to the millisecond. And Carl lost track of time, and then he changed his mind.

Thousands of birds take flight at Marseille Provence Airport in France

If you know Carl, you know why. He’s all about teams. How they work together. What drives them forward. How to build a jellyfish company without going Lord of the Flies. Carl’s spent an enormous amount of time thinking about these things. And so has the client.

So Carl said yes. Just like I did.

And really, how can you say no to the idea of bringing the beautiful complexity of the natural world to our everyday interactions? A million starlings can fly together, yet we struggle to get even small teams off the ground. Why?

Hapyn is the answer to that question. It’s a new operating system to improve how projects and occasions occur. It eliminates the waterfall process and replaces it with “stuff attached to things”. So interactions no longer have to happen in a set order. They can just hapyn. Spontaneously and immediately. Like birds taking flight.

The client described a “tracked object” as “the thing” you attach stuff to. At first Carl wrote the phrase “attach the stuff to the thing” followed by a question mark. By the end of the conversation, he added a bold exclamation point.

Catch up with us next month. We’ll talk more about nGen’s unique development approach, and the thinking behind the “tracked object”. Stay tuned…

The thing is, as our client envisions it, it can.

Hapyn is a platform for creating, managing and archiving events, or hapynings. It can help you run a charity event, family vacation, small business or create a new green space. Best of all, once you’re done you can share your event with others. Want to know more about the trip I took to Europe? Here you go. Have a complete understanding of everything I did, how I did it and what it cost.

Now for the fun. Every few weeks we’re going to blog about how it’s going. We’ll talk about the ups and the downs. Things we’ve learned. Mistakes we’ve made. And my promise to you is we’ll be completely honest.

So far we’ve made a couple of fun decisions that I think will raise some eyebrows.

First, we’ll be working on the marketing and the product at the same time. This will be an interesting experiment as the two teams will be in frequent contact sharing ideas and brainstorming on ways to make the product and promotion tightly integrated.

Second, we’ll be using Hapyn to build Hapyn. No, we haven’t solved the mystery of time travel. But we have realized that we can add enough functionality to the prototype that it can function as our project management app. How cool is that? Using a product to build the product. Sci-fi stuff going on in here!

We’ve also been throwing around the phrase “minimum usable product” instead of “minimum viable product.” More on that soon…

Tell us what you’d like us to share as we build this new application!

Jolly is the kind of guy you’d hang out with and within a half hour, offer a best friends bracelet. When he’s not overheating during 24 hour marathons, he’s balancing the fun of four kids and a beautiful wife with four to eight projects at work—with more long distance training padded on each side for good measure. He’s funny, he’s honest about the fact that he lives in Wilmington, Delaware (which takes guts), and he’s doing this whole work thing a little differently.

Project management isn’t something you typically think of as remote freelance work, but Robert’s got things down to a science, and as such, has unique perspectives on what it’s like to work for a range of companies, including flat ones. I have to say, I was close to buying him tickets to a Celine Dion concert as a token of my Canadian appreciation. But I couldn’t because she sucks.

Rachel: So Robert, how long have you been freelancing with Simply Accessible?

Robert: I’ve been freelancing with Simply Accessible for about ten months now. Started in April of 2012.

Rachel: How did you first hear about it, and how did you transition into that role?

Robert: Derek Featherstone tweeted that he was looking for a project manager and wanted some recommendations. I direct messaged him because we’re friends, and he knows me, and I told him, “You know I did project management for Happy Cog before I left them.” He says, “No, I didn’t.” Because he remembered me as the client services director there. We talked on the phone and decided that it would be done. He needed somebody, he thought, for some part-time help, and it worked out perfectly in terms of his need and my availability.

Rachel: Is there anything you’re working on right now that has got you really excited?

Robert: Yes, we’re working on the launch of a major retailer’s presence in Canada. Our work is accessibility focused, so we’re working with them prelaunch to identify and resolve any design and code issues as they relate to accessibility. We’re actually bringing a lot to the project in terms of overall usability as well. Just by its nature, the accessibility has parallels with usability.

Rachel: Would you say that Simply Accessible is completely distributed—does anyone have an office, or anyone at a central location, or are you completely decentralized?

Robert: It’s completely decentralized. I’ll take that back. It is mostly decentralized. There is at the office space in Ottawa: Derek and Katherine (who is the president of the company). Derek is the accessibility lead. They also have an office manager that helps with bookkeeping and things of that nature that comes in. But there’s no main headquarters where we have a lot of the project work getting done by people in the same location.

Rachel: Do you find it challenging working remotely in a flat team?

Robert: Sometimes not knowing what the progress is with a specific task is tricky, so again that revolves around communication. And making sure you have a way of checking in when you need to know something. That’s one of the issues with remote teams, just making sure that everyone knows what’s going on and what’s coming up next. So as a project manager what I try to do is make sure we all talk about that stuff at the beginning of the week, and then almost—I wouldn’t say over communicate, but communicate some of the things that may be obvious to me or someone else, but may not be obvious to everyone on the team, like we have this milestone coming up, or we need to do this. And kind of checking in occasionally to make sure that everybody is on track with what they’re responsible for.

I read something today about project manager roles being ones that look after the team members as much as possible so they can focus on getting things done. I liked that in terms of how I try to approach things with our team. Make sure we have all the information in front of us but not be like a taskmaster about it; not stress people out about where we are with certain things—unless I know we’re falling behind. Then I’d have to start singing a different tune.

Rachel: The slightly more violent whistle.

Robert: That’s right, animated GIFs would become a lot more hostile.

I definitely think I prefer the distributed environment. I do miss some of the in-person collaboration and camaraderie that happens when you go into an office and you share a space and a set of work hours with other individuals. I do think there are benefits to that but I think if you have the right team and the right ability to communicate, you can overcome those issues.

Rachel: It’s interesting, I was talking with someone recently about the same thing and he said both of those things; you need the right people on the team, and you need the right tools to be able to communicate.

I’ve also heard the argument that it’s not about the team members so much as the willingness to be able to adapt and evolve into that fit.

Robert: I think it’s true. If you can’t adapt then you’re probably not the right person for it. But it does take some flexibility, especially when you have people in multiple time zones.

Rachel: Do you think if you had a small company that was still considered a corporation, it is possible to transition to a flat structure?

Robert: I think it’s possible. I think what makes it difficult would be the resistance to change. If that idea wasn’t embraced by everyone on the team, from the top down or bottom up—you could say it both ways—I think the change has to really be wanted by everyone that’s there to make it work, or people that don’t like it have to leave. The people that want it have to create their own thing. I could even see there being flat departments within larger enterprise organizations, if that makes sense, just by virtue of how they decided they’re going to run their particular shop.

Rachel: Talk a little about what you might look for in your teammates as far as qualities go.

Robert: I guess being self-starters, being able to openly and freely contribute and also to give and receive criticism or feedback on the team. The ability to communicate is going to be pretty important with a flat team. It’s not that everyone has to feel comfortable speaking in a room or something like that, but just being able to tell your teammates what’s going on when you’re working and being able to jump in and help out when it’s needed is going to be important in a flat team.

Rachel: How do you think that differs from people who aren’t working in a flat team, but in a more traditional model? What sort of qualities do you think their senior employers look for in them?

Robert: I think they’re going to look for all of those things, but I think that work is maybe more siloed in those organizations. You may have people that if they aren’t wearing them when they come to the organization, they may end up putting on blinders where they’re really only concerned about what they’re supposed to be doing, what’s immediately in front of them, and maybe not necessarily what other folks in the organization are doing that is not directly impacting their job.

Rachel: We just talked about what kinds of qualities flat teams require. Then we asked, “What do traditional hierarchies look for?” The interesting thing is you said they look for the same qualities in people. But you also said the silos in hierarchical teams isolate people, which is fascinating considering many people think that same issue applies to distributed teams. What is the thing that you think ties people into this idea of “let’s be flat, let’s not haggle over our roles here”? What is that ‘common vision’?

Robert: I think that common vision is this dedication to do—especially in a small organization—whatever it takes to get the job done, to succeed, help the business succeed, help your customers succeed. Does that make sense?

There are more hierarchical organizations that really do try to honor work/life balance, but what I’ve seen with flat organizations is a real desire to recognize when something isn’t right, and then take steps as a team to fix that. Like if we work on a project and we have a crazy deadline with way too many deliverables to get it done in the amount of time that we need to without sacrificing our home life, we all recognize that and say what can we do differently next time to change that. I’m not saying that doesn’t happen in bigger organizations, but I think it’s harder to effect that change, or at least it’s been my experience that it’s harder to do that. You don’t have everyone feel like their voice is being heard and valued at the same level as everyone else.

At that point, you’re then lobbying for something, for what you need, to someone with more power than you have. That versus discussing things as a group and making the necessary adjustments, either consciously or subconsciously. I’m thinking now of a flock of birds. They don’t talk to each other and say we all have to turn right, right now this instant, then discuss it and decide to do it. They just do it as one.

[Jolly’s statement made me think of this starling video]

Rachel: How does transparency come into play in flat organizations?

Robert: If you’re not clear about how your team is made up, who’s on your team, and the approach that you take, then it doesn’t build trust with the client. In the end, I think what really matters to the client is; are you going to be able to do the work, and do they trust it’s going to be great. I think some of that is evident from past projects, but the trust comes from just showing them we’re a little different; we’re a flat company. And if you want to read more about it, here it is. Transparency is really important and it can overcome almost any objection, I believe.

Rachel: When you sit down and look at the last however many years you’ve been working, and where you’re sitting today; what do you take away from our discussion, and where you’re at?

Robert: My takeaways from doing this for a while and after talking with you are that it’s good to hear there are a lot of other people doing this. I had no idea there were that many. So there are people that really are turning this almost into a bona fide science. Although I’ve known it has worked, I didn’t think it was magical or anything, but it is pretty special.

It’s special indeed, Jolly. It was a real treat to be able to chat with you about a new perspective on freelance project management and flat teams—almost as much as it was to find out you weren’t hurt about the Celine Dion tickets. I’ll make it up to you, buddy.

Tools At Work

Some expert tools Simply Accessible uses to get the job done.

Basecamp (Classic)

The “old standby,” Basecamp is our main repository for project communication. I can’t imagine life as a PM without it.

TeamGantt

TeamGantt’s a newcomer to our tool chest, but it’s proving to be wonderfully suited for us. It offers at-a-glance views of project tasks, progress, and resourcing which is really valuable for our remote team.

Git/BitBucket/GitHub

Git is the shit! We’re often developing accessible code prototypes and solutions for client projects and seminar examples, and this allows our team to develop, test, and revise work iteratively and cohesively.

Google Apps

Google Apps. So calendars. Email. Documents (Drive). And now Hangouts all help us be more efficient.

Communication

GoToMeeting, Skype, Google Hangouts/Chat/Voice, Phones, and IM apps. Basically, we need solid, affordable options for communicating since we don’t sit in the same room for most of our discussions. Google Hangouts is fast becoming one of my favorites for impromptu discussions—with or without the Pirate Hat.

As I mentioned before, I’m all about reducing as much waste as possible in my design process. Everything we do should contribute to the final product so we can spend more time addressing design problems and less time painting pictures and translating them into our intended medium. Ultimately, I think this change in approach results in better products and more value for our clients.

Disclaimer: While I personally think designing in-browser is the way of the future, I don’t believe that great design can’t be done without it. Most of my favourite designers are diehard Photoshop champions (though I hope one day they give the in-browser concept a fair chance).

Get uncomfortable

The concept of designing web sites and apps with graphics editors like Photoshop is so ubiquitous, it seems crazy to imagine working without these tools.

When you think about it, the traditional web design process is a response to the limitations of early CSS. Photoshop just happened to be the tool that best fit the job at hand; one that we bludgeoned beyond its intended purpose so we could design graphically complex UIs. The result of toying around in it created a slough of UI porn which was meant to give web design similar capabilities to print design. When we use a graphical editor, we design graphics. We add layer style like gradients, drop shadows, and textures to make things “pop.”

Ironically, print design never succumbed to these visual tricks and ‘flat design’ is actually just a return to its core principles.

We’ve gotten really comfortable on this picture-painting path over the years, but as products get more interactive, UIs more flexible, devices more unpredictable, and web typography more sophisticated, it’s leading us astray. Photoshop comps can no longer cut it.

I’m far from the first to express the virtues of in-browser design. Many smart people have presented compelling arguments for it over the past few years, so I don’t have to. I’m curious to find out why more designers haven’t adopted this approach and how we can make it easier to transition to this way of thinking.

When you read any of the articles prosthelytizing in-browser design, all it takes is a scroll through the comments to witness the common hurdles that stop people in their tracks. They’ll usually say something like this:

• “Coding is too hard.”
• “It limits your creativity.”
• “It leads to bland designs.”
• “It can’t work for complex sites.”
• “It’s difficult to create irregular objects.”
• “It’s difficult to think visually with code.”
• “I can think more creatively in Photoshop.”
• “I need to show the client something earlier.”

Are these concerns really symptoms of in-browser design, or is it simply that we haven’t distilled the process yet? I have a feeling that most critics dive in, flounder, and drain the pool without really learning how to swim.

In Switch, the Heath brothers make a good observation:

When people try to change things, they’re usually tinkering with behaviors that have become automatic, and changing those behaviors requires careful supervision by the [rational part of your brain]. The bigger the change you’re suggesting, the more it will sap people’s self-control. And when people exhaust their self-control, what they’re exhausting are the mental muscles needed to think creatively, to focus, to inhibit their impulses, and to persist in the face of frustration or failure. In other words, they’re exhausting precisely the mental muscles needed to make a big change.

There’s a lot of truth to this. When we try to make sweeping changes to our process, it’s almost impossible to be comfortable and feel like we’re doing good work right away. A lot of folks dive off the deep end attempting to apply familiar comp-based workflows to in-browser design, expecting the results to be of similar quality. When they get tripped up or find the designs aren’t working, it’s much easier to revert to old habits instead of sticking it through and re-examining each step.

I spent a lot of years frustratedly switching between Photoshop and CSS before nailing down my workflow and learning how to be creative in code (by the way, memorizing a few CSS declarations is far easier than memorizing those Photoshop tool menus). I still occasionally find myself hopping in the ‘ol faithful Photoshop in search of ideas, but that’s where it stays. Idea generation and graphic editing. Start small and move on.

Okay, enough philosophical pep talking. Let’s do this.

Make the transition

There’s a lot of muscle memory locked up in those esoteric tool palettes to unlearn, and a great first step towards UI design in the browser is to start with a live style guide. There are plenty of articles about live style guides out there, but most seem to be an afterthought used as a reference guide for future design and development. I’m suggesting it as a starting point. There are several unique advantages to this:

• It’s a fantastic early design deliverable for clients.
• You’re not deferring the finer details of your UI to a developer.
• You eliminate much of the slicing and dicing of Photoshop comps.
• You are writing a strong foundation of production CSS right off the bat.
• It’s fun and easy to experiment on such a focused collection of elements.
• For less experienced developers, it’s a great place to learn the finer points of CSS without getting bogged down with its quirky layout aspects.
• It gets you thinking modularly about your design. Focusing on individual elements without the distraction of layout is helpful on getting the details right.

If you are still uncomfortable coding a full site, this also works as a decent hand-off to more experienced front-end engineers on your team. You can even use Pagelayers to export your elements into a full layered PSD if you feel the need to continue in Photoshop. And if you change your mind about certain elements as you progress, you can always update your guide.

We don’t have to dive into browser-based design head first. We can do little things that gradually enable us to create more powerful interfaces without the intense discomfort brought on by total immersion.

Here’s how I do it:

Choose your type

Typography always comes first—using a combination of client requirements, experience, and research, I settle on a few typefaces I’d like to experiment with. I’ll usually plug a sample of real content into Typecast and start typesetting in there. I always begin with paragraph text, create a modular scale, and move on to headlines, block quotes, and callouts. See Tim Brown’s magnificent More Perfect Typography talk for a great breakdown on how to design typographically.

Once I get a rough idea of the basics, I take the generated CSS out of Typecast and pop it into my own home-grown style guide template, which you can check out for yourself on Github.

Design your system

Now for the fun: building that style guide. Here’s how I do it:

1. Tailor guide.html to my project by changing the title, typeface names & fonts used, and if decided, the colours; then remove any unneeded elements.
2. Apply my type settings from Typecast to my SCSS files and start refining.
3. Work down the page styling, using separate .scss files for each UI element until I’m satisfied with the entire document.
4. Review the finished guide with the team and client and adjust accordingly.

It’s dead simple to experiment with various colours and typefaces. Just copy your styles to a new folder and adjust accordingly (or do what I do and create separate git branches for each version). This method is great for focusing on individual elements and gets you thinking in modular systems rather than pages, which as we addressed in the last post, prevents us from missing vital elements and functionality.

Connect it to Live Wires

Once I have a solid style guide, I simply apply the CSS to our Live Wires template. At this point, we’re well on our way to a solid design in the browser. We have a full set of designed elements applied to a rough layout.

We still have to massage and refine the details, but at least much of our foundation is taken care of. This can really save you and your clients a ton of time.

It may take a little longer to get each of the elements just right when you’re getting your feet wet, but then again, you won’t need to translate designs to code later and you’ve covered much of your front-end development, too.

Tips

• Keep your guide.html file alongside your site. It will stay updated even as you refine your pages, and continue to work as a nice reference for others.
• If you need to add an element more than once across different pages, bring it into your style guide and start designing it there first. Refine as needed. This will keep you ‘thinking modular’ and ensures your guide stays current.
• Feel free to drop into your graphics editor every now and then to experiment with specific elements, but resist the urge to design an entire layout. Get into code as soon as possible.
• Set aside major milestones in your work for comparing progress across reviews. I like to use tags in Git to mark important milestones, but you can regularly copy and archive your folders if Git ain’t your thang.

See an example of a style guide in progress.

Skip the trap

Starting with a live version of my style guide has been pivotal to successful in-browser design. I can focus on individual elements and typography without getting bogged down by layout or page-specific quirks. Thinking this way also allows me to skip the trap of designing a series of individual pages in Photoshop. I’m less concerned about the quantity of templates I need to design, and more focused on putting valuable time into creating higher-quality reusable elements. By skipping Photoshop, I conserve several hours for experimentation and refinement and I have full control over the final product.

Designing web interfaces in Photoshop and handing them off to a developer to finish them is like an architect designing the outside of a building and leaving the the internal structure up to the construction team.

Give in-browser design a fair shot and let me know how it goes. Together we influence how this concept evolves. Let’s see what’s possible.

Solid resources

• My Style Guide
• Typecast
• Modular Scale Calculator
• More Perfect Typography
• Stephen Hay: Responsive Design Workflow
• Nice Web Type
• Material Honesty on the Web

How many hours do we whittle away adjusting site map templates, dilly-dallying in wireframing applications, picking apart prototype frameworks, and feverishly massaging Photoshop comps only to throw them away when the next project phase begins? How many more hours are spent converting those formats to something else?

I’m not even talking about time spent actually designing, I’m talking about everything in between. The slicing, dicing, adjusting, revising, and refactoring that comes purely from working in our potpourri of traditional design formats. It’s easy to miss the full impact when we’re used to receiving an asset in one form, analyzing it, converting it to our desired format, then handing it off to the next station in the assembly line.

For years we’ve been building disposable avatars of a finished product. How much better would our finished products be if we could turn those hours into real design thinking and execution? We can give our clients a much bigger bang for their buck with a little change in our perspective and a big change in our process.

Instead of creating a series of disposable deliverables, let’s look at the web design process as an evolution. Everything we build should in some way take us closer to a final product with as little waste as possible.

We’ve been making adjustments in all other areas of our work process, but today I’m going to focus on an area that has really gone off the rails in the last few years … wireframing and prototyping.

BACKGROUND ON WIREFRAMING

The proliferation of UX as a field has yielded a staggering number of wireframing methods and tools. Some of them are online apps. Other methods involve repurposing old tools like Illustrator or Fireworks. I’m making a bold declaration that they all stink. Yup. Every last one of ‘em.

Here’s why:

DESIGNING WITH THEM

• You are limited to the available palate of UI elements.
• Designing interactions is troublesome or not even possible.
• They are often cumbersome, buggy, and time-consuming to use.
• It’s easy to forget pages like search results, sign-ins, sign-outs, and 404s.
• The fidelity is too high for such an early stage. Decisions get glossed over and too easily paint designers into a UI corner (e.g. adding social media icons in a wireframe causes a client to focus on design elements instead of content types and organization).

INTERACTING WITH THEM

• Most aren’t responsive.
• They don’t effectively mimic a true browsing experience.
• The aesthetics are often not suitable for client presentation (intentionally ugly UI’s aren’t always obvious to clients … looking at you myBalsamiq).

Worst of all, with every single app, we spend hours creating something that we inevitably need to translate to another medium, then throw out. Not cool—and not economical for anyone.

Many folks have began to use frameworks like Twitter Bootstrap or Zurb Foundation to build their prototypes. While I think there are great elements within these frameworks, they have their own sets of problems when used as a whole:

• The fidelity is far too high for early prototyping.
• They make too many decisions for the designer.
• They are bloated and complex. Too much time is spent stripping, overriding, and trashing.
• You’re trapped into their way of thinking. It’s far too easy to get sucked into the “Bootstrap look.”
• Often you still need to throw out a bunch of work by the time you’re ready to move past the wireframing stage.

The proliferation of UX as a field has yielded a staggering number of wireframing methods and tools. Some of them are online apps. Other methods involve repurposing old tools like Illustrator or Fireworks. I’m making a bold declaration that they all stink.

I’ve always been a fan of really low-fidelity wireframes. Remember Jason Santa Maria’s grey box method from almost ten years ago? It feels exactly right for designing basic content organization. It demonstrates basic layout for our content and there’s little mistaking it for a final product. Most importantly, it doesn’t pin you to a UI wall. This stage should be about quick approximations that are easy to adjust and give an idea of how the site works on its most basic level.

Grey boxes were great in the old days of fixed-width layouts, but today the approach is too limited. How do we communicate how things work at different screen sizes? How do we show dynamic interactions like hidden drawers or navigation elements? And once again, we’re spending valuable time creating a series of assets that get discarded later.

INTRODUCING LIVE WIRES

In response to the lacklustre options and approaches out there, I rolled my own wireframing toolkit called Live Wires.

Live Wires is more of a philosophy than a framework. It’s designed to be as simple and un-opinionated as possible. It’s not ugly, it’s not fancy or colourful, and it uses simple HTML & CSS (actually SCSS). It has a couple simple examples of common UI patterns to use as starting points, and a few nice SCSS variables to make things easy. This is why I like it:

DESIGNING WITH LIVE WIRES

• Experimentation is quick and easy.
• I’m not limited to the available library in a wireframing/prototyping application.
• We can pull in core messages when we’re ready to design to help keep page goals in focus.
• Because I’m placeholding much of my “content” using background images, I can set the stage for production-markup without filling it with junk that I throw out later.
• It’s fast. I’ve already included some simplified designs of common patterns and standard elements which speed up coding. It’s just a matter of dropping them in and adjusting as necessary.

INTERACTING WITH LIVE WIRES

• We can serve it anywhere and share it with anyone.
• It’s responsive. I can preview wireframes in all my devices.
• It’s not ugly, but not handsome enough to be mistaken for a final design.
• Nothing replicates the browsing experience like clicking and interacting with actual web pages.
• Omitting text separates content from layout and helps make it obvious that the wireframes are just that … wireframes.

OTHER ADVANTAGES

• There are no monthly fees or additional expenses to worry about.
• Clients won’t see partial wireframes and can’t be confused about site navigation, page stacking, or page orientation.
• I’m not wasting time creating assets only to throw them out later. I’m setting the foundation for actual production code.
• The organization is so low-fidelity that you’ll have the freedom to change elements in design without throwing client expectations.
• It’s more difficult to forget pages when you can truly interact with the whole site. I added some commonly forgotten templates to ensure they’d be included.
• It is the perfect first step towards designing in-browser. I know you don’t believe me, but this is the way of the future.

HERE’S HOW IT WORKS

Live Wires is an attempt to capture the spirit of the grey box model and bring it into the browser. What we end up with is a standard set of neutral styles, and a flexible, quick n’ easy way to build out prototypes in the browser without creating waste.

See an example of Live Wires.

As I’m building out my Live Wires, I work directly with a content strategist to help define content types and organization. Design decisions should be influenced by the type of content used in each section. Good design conversations will influence the content itself—it goes both ways. Designers need to be working directly with content strategists. Collaboration is critical in this stage.

Live Wires is an attempt to capture the spirit of the grey box model and bring it into the browser. What we end up with is a standard set of neutral styles, and a flexible, quick n’ easy way to build out prototypes in the browser without creating waste.

CONSIDERATIONS

• You need to know a bit of HTML & CSS (Learn it. It’s easy).
• At first, you may not be able to prototype this way as fast as you did with other tools. But consider the time you save by not transferring designs over to another medium which also force you to deal with software quirks. You’ll get faster as you go.
• While writing your CSS, keep your wireframe-specific styles separate from your layout styles. The idea is to be able to drop as much as possible into the next stage of design or production.

FORK IT, TRY IT, MODIFY IT

You can fork the toolkit from the nGen Github account, but please recognize that it’s really the philosophy that’s important, not the product. Customize it to your own needs and workflow. Hope you find this approach works for you and let us know if you have any feedback!

NEXT: BROWSER BASED DESIGN

Next post, I’ll be exploring how we can be more efficient designers through a browser-based design approach. Ultimately, this approach is about designing systems, not pages. Once you’ve tried it, I’m sure you’ll see how effective it can be at eliminating wasted comps and tightening your design process.

We’ve been talking a lot about flat teams at nGen over the last year and a bit. So chatting with Steve was fascinating because Ordered List was a flat company that employed five people, and of course, GitHub is flat and employs 148 (as of this writing). Quite a spread.

Naturally, I wanted to know about the mechanism behind that flatness. How do things work? Does it matter how big or small your teams are? What’s important where you work? What happens when things get tough? Steve gave me so much to work with I probably could have written a short novel, but then we’d have to work out royalties and I’d have to put up fake pictures of him in sparkly drag to test his loyalty—he does have great hair.

Instead, I decided to lay out the teeth and bones of being flat at GitHub so you could see how large companies are doing flat these days.

Some Things You Should Know About Steve

• He’s got a wicked sense of humor.
• He’s from South Bend, Indiana, which should never be confused with Silicon Valley.
• In 2007 he formed Ordered List with his pal John Nunemaker and later added Jonathan Hoyt, Branden Keepers, and Matt Graham to the mix.
• Together they created cool stuff like Speaker Deck and Gauges which caught GitHub’s attention.
• “When a company like GitHub comes around and shows interest in what you do, well—you get pretty excited.”

Some Things You Should Know About GitHub

• It’s the most popular open source code repository site for developers.
• In five years, it’s already hit its 3 million user mark and is valued at over $750 M.
• It’s a people company, which means that the people that use the products and the people that make them come first.
• It has no hierarchy: there are owners, but no managers. There are business operations and shareholders, but no profits before people.
• It has been growing steadily and hires folks from all over the world to work at the office in San Francisco or remotely.

Here’s where I pick Steve’s brain. He didn’t complain once…

Rachel: Can you help me understand the integration of Ordered List into GitHub? How do you work and how does that fit in with the greater GitHub environment?

Steve: GitHub was very interested in us as a team who built software. They were really interested in both Speaker Deck and Gauges and how they could apply that to what GitHub’s overall mission was. There was never pressure to take things and shut them down. They were interested in anything we wanted to do to make our products, or GitHub in general, a better place. They didn’t come at us with a specific list of things we would be doing. It was more like, “You’re a member of the family now so continue doing whatever you want to do…” The five of us (at Ordered List) still work together on some things, and on other things we’re very autonomous, but we always talk with each other all the time. It’s been a good family experience. It’s the only way I can put it. It’s semi-organized chaos, which takes a little time to figure out, but once you do, it produces some pretty awesome stuff.

Rachel: How do you decide who works on what?

Steve: People always wonder, ‘How do you know what to do?’ and the answer is that we just decide and then do it… We’re building software for us—stuff that we enjoy, and that we think is going to be great for the people using it. Rather than doing work to satisfy a boss, we find ourselves doing the coolest, best, most ridiculous work we can to impress our friends who work with us. Of course there are all sorts of discussions, and the larger the team grows—I’ll even just say it—the more difficult it is to decide a given direction. When you have any number of people who can do any number of things they want, trying to keep that cohesive, I think, has been the biggest challenge.

Rachel: Are you a distributed team, or do you colocate in the same place?

Steve: So we have an office and we’re partially colocated in San Francisco. About half of the team works there now. I would say that GitHub encourages anyone who doesn’t live in San Francisco to come and work at the office, but it is not a requirement by any means. I believe there is value in being in the office. I love going myself, but it is obviously a better situation for people (as you can see from our [remote] team) and whatever’s going on in their lives—be it family or the desire not to live in the city—that they don’t move. They still add value to the company and are still a great asset to have. Talented people come from all over the world.

If you can set yourself up so that being distributed is not only possible, but ultimately functional, it’s only going to be a better situation for you.

Rachel: Would being required to move to San Francisco have been a determining factor for you to join GitHub?

Steve: There’s no way it would have happened—at least three of the five of us would not have gone. I can’t move to San Francisco. It’s amazing to work remotely and work where you’re comfortable. What’s great is that even the people who live in San Francisco, a majority of them work from home a couple days a week. On a typical day with a company of around 150 employees (my math might not be right on this, by the way), 70 of which live in the area, there might be only ten or fifteen people in the office at a time. You have some people who come in the morning. You have some that come in at night. There is no set schedule … We can’t have this concept of face-to-face meetings or phone calls. You can’t hire someone from Australia and expect him to work on a U.S. time schedule because that’s not good for him.

Rachel: Are there certain qualities that people on flat teams have to have—or be on board with—that fit the model?

Steve: Absolutely. I think the biggest, most important aspect of having a flat team like we do is fitting into the culture. You have to be a certain type of person. You don’t have to be an introvert or extrovert. It’s about a willingness to communicate, a desire or passion for what you do; a passion to constantly get better at what you do; being able to take criticism well.

The funny thing is when we hire people, their work is probably already on GitHub, so it’s easy to tell someone’s technical ability. And when I was looking to hire people at Ordered List, I always said: people can learn new schools in a technical environment, but no one’s going to become less of an asshole. It’s all about personality; if you’ll jump in and contribute right away. But more important is that you get along with people. It’s very much a culture fit.

We spend most of our hiring time just talking to people. When we interview, a lot of the time it’s just random people who are in the office or whoever wants to have a Skype conversation with the potential hire. It’s not about programming. It’s just talking about your life and what you’re interested in and seeing if this person is someone I could get along with because that’s what you’re going to have to do on a daily basis. You can’t have a distributed team without communication—although I would say you can’t have a colocated team without communication either. Being able to handle that level of freedom and that level of trust and getting along with your teammates is the most important thing to us. Ultimately, you end up becoming friends because you hire all these awesome people who are passionate and can talk. You hang out a lot!

Rachel: When you have a flat team, you don’t have anyone standing in and saying, “These are the expectations; these are the things you need to do within a given timeframe.” So, how would you say GitHub emphasizes accountability on a team?

Steve: We definitely take the approach at a more proactive level. I don’t think it’s anyone’s job to look around at people to see if they’re doing well enough. I see people who have struggled in the past with the unwieldy freedom. You tend to see those people and have questions like, “What has that guy been doing for a while? Has anyone heard from him?” We love to ask people what they’re working on, and if someone is having a difficult time you ask if they want to help you on your project.

There are times when you are going to have a project and you are going to be gung-ho and working crazy hours. There are times when you’ll have a hard time knowing what to work on, so if you continue in that communication cycle, you’ll always find a place to hook back in.

We also encourage you to take vacations and get away from the computer. Just go. Away! Take a week or two and free your brain a little. We recognize there are all sorts of working styles. There are probably people at GitHub that are sitting down at their computer less than twenty hours a week, and that’s fine as long as your producing, contributing; as long as you’re doing something. Whether or not it gets used, you have to finish something. The worst thing you can do is start a bunch of things, get halfway through, quit and start something else. You’re not going to be happy. Ship stuff.

I’d like to think if you get into the area where someone needs to sit you down and talk to you about contributing, it’s been a long time coming. We constantly are working with each other to communicate on a daily basis. And we’ve had to let some people go. The disappointing part is realizing that we made a mistake hiring them in the first place. It’s not like they were great once and then suddenly got worse. We just didn’t do a good enough job figuring out that this wasn’t the best place for them to thrive. We feel bad and we feel disappointed in ourselves.

Rachel: GitHub started out flat from the get go. Do you think that in a more traditional structure, people can transition to and ‘go flat’?

Steve: I think it would be difficult to do unless you have a buy-in from everyone on the team. If we had twelve managers and wanted to go flat, we’d have to be like, “So you guys, I don’t know what you’re going to do now. We don’t really need you anymore—.” I don’t know how you’d handle that as a company [laughing].

In a top-down structure in a company, a lot of times you have this concept of senior level and junior level programmers, so you hire people who are entry level and they work up through the company by getting better and then they work up into management. In a flat company like GitHub, there’s no concept of moving up, because no one is going to take responsibility for you, no one is telling you what to do or holding your hand while you do stuff. Everyone has to be great at what they do. I think that’s really hard to transition into that. I’m not saying it’s impossible, but it would be a very difficult thing to do without the whole company buying in. I think if you had the CEO of a company suddenly decide to go flat, it would be chaos. And maybe that level of chaos is fine for a little while…

Rachel: If you had the CEO of a multi-trillion-dollar company approach you and say, “Steve, you’ve got the chutzpah. I really like what you’ve got going on. I would love for you to manage a team of 250 people. There’s going to be a pyramid structure in there, but you’re going to have ultimate control and influence. All you’ll have to do is report back to me. I’m going to pay you net 2.7 million every year.” Would you do it?

Steve: Wow. [pauses] If I did it, I would hate it. It sounds miserable to me because what I love to do is build stuff and managing people is not that much of a strength of mine. If you really want to learn more about that you can talk to Hoyt and Brandon and Matt. I love to design and build software. Right now I’m working with the GitHub for Mac team, so I’m designing actual Mac software for the first time in my life.

We have this concept for ‘team’ at GitHub. We like to say: “Never work on a project alone because there is this flat structure and an absence of someone checking in on you. For your own sake, don’t work alone on stuff.” It gets really boring and difficult. It’s hard to finish things. It’s hard to do it well when you’re on an island. I just joined the Mac team in 2012. There’s no manager; you just sort of jump in, and the tools for doing that at GitHub are huge. Your company has to be set up to have that type of communication.

It takes a huge amount of trust and respect and the ability to recognize that [the founders’] concept of what GitHub is and can be on its own is smaller and weaker than what it could be collectively.

Rachel: Do you have any tips for clarity on text based communication?

Steve: The only thing so far that has affected improving text based communication is to meet someone in real life. When you’ve met them and hung out and gotten to know them, it’s so much easer to understand their voice when they’re typing. Twice a year, GitHub flies everyone into San Francisco. Everyone comes and hangs out for a week; we do things like lightning talks. We just do fun activities together and get to know people on a personal level, so when you’re in a chat room I don’t interpret you saying, “I don’t know if that’s good enough,” as you being an ass.

One of our guys in Spain, he was very blunt in chat and email. Until I met him in person, I just thought he was an ass. But then I went to a summit and met him and went, “Oh! You’re not an ass, you’re actually hilarious and one of the nicest people I know. This is just how you talk. I get it now.” And so now I understand where he’s coming from. I think it’s really important to have face to face conversations but not in the context of work.

Rachel: I was just thinking how traditional industries do their power lunches and their stand up meetings and one day, if they were like: “We need better communication guys; how are we going to do this?” Then you were to walk in and say, “Well, let’s talk—but not about work and let’s not be at work when we do that.” Can you imagine how that would flip their world upside down?

Steve: Even in that context, with that hierarchical setup, whatever you’re doing, you’re still going to the bar with your boss. Traditional hierarchy doesn’t set itself up well for socializing like that which is why most of the time it doesn’t happen and is frowned upon. I’m not going to go to a bar and get buzzed with my boss. That’s just weird. But all we do when we hang out together [at GitHub] is we have fun, we drink, and we play games. Last year everyone rode roller coasters during one summit. It totally depends on the people. You have to have people that are social and communicative.

Rachel: Do you think then that there are certain types of industries where this flat team structure wouldn’t work?

Steve: The only ones I can think of are ones with legal checks and balances, like maybe the medical industry would kind of suck in a flat structure. There’s always that threat that someone is off on their own doing something that is completely out of line and kills someone.

But I think for most things, happiness in what you do is always going to produce better stuff. Happier salespeople would sell better. Happier factory workers would do more effective work. We found that at GitHub our CEO would always say, “We optimize for happiness” in every way. For our customers and for us. Anywhere we can make someone happy, we do our damnedest to make it happen.

Rachel: Do you do any peer reviews or is it more ongoing evaluation?

Steve: It’s just day-to-day. There’s this feeling because we all know each other and we’re all friends, and communicate with each other, we do look out for each other. Maybe someone is just going through some bad stuff in their life right now and that’s fine. As friends of theirs, how can we help? Whatever we can do to help you move along and help you get better, we will do. It comes back to that family aspect. The culture that we have is very familial. It’s very friendship based; it’s very respect based. I feel like that’s the most important thing for having the kind of team that we do, because everyone has to be on board together.

Rachel: So, how do you compensate hard work in a flat team or flat company?

Steve: To me, you just have to make sure people are happy making what they make. You have to pay people well; you just have to take care of everything people can worry about. You’re not going to pay more than they’re worth, technically, but you can’t scrimp.

You have to make feel people feel valued and one of the ways to do that is through salary. Some of it’s through benefits, some of it’s through technology or toys—giving them computers and access to the devices that they want. Whatever you can do to help take care of that stuff for people is only going to be better. If you pay people correctly (I should say, what they’re worth) to the point where they’re not looking at other jobs…I don’t need to look around—I’m doing fine. I’m happy and I’m doing my work.

I’m never worried about my family getting sick, or anything that could possibly happen because my insurance is taken care of and it’s not coming out of my pay check. That’s an additional benefit. It’s amazing how freeing mentally that is. It’s another thing I don’t have to think about and it frees up my mind to do other things. I think it’s an intangible; you can’t really measure it, but it follows that it produces better things.

I’d like to think that it sort of rolls around on its own. People are more productive, the company is more profitable, and it sort of just snowballs at that level. At this point in GitHub’s timeline, we’re providing more benefits. They added 401K this year. We don’t have to come up with a bunch of cash to make shareholders happy … Our investors are on board with what we do.

Rachel: It sounds like this is about feeling connected and passionate about the things you do, and then out of that comes amazing work. So instead of, “Go to your job and do your job and then meet people you may or may not get along with,” it’s, “Put everything else first, and create things you love to do as a result.”

Steve: Absolutely. Again, it’s about optimizing for happiness. Do everything you can to make people happy. Exude that sort of attitude in the work that you do. For our customers we use terms like ‘surprise and delight.’ What can we do to make them happier, so they can go, “Ha! Woah, that’s awesome”? We love what we do and we love who we do it with.

Rachel: So Steve, on this final note, if you had to sit down with somebody who did have a more traditional perspective—maybe he was trying to shift the way that he worked or joining a company that was flat—what would you tell him to get him to see the big picture?

Steve: I think the encouraging words would be, “it’s okay to let go…”

I have the hugest respect for the founders of GitHub who built this amazing thing and hired 150 people and have said, “Do whatever you want with it.” It takes a huge amount of trust and respect and ability to recognize that their concept of what GitHub is and can be on its own is smaller and weaker than what it could be collectively. And I think that’s really hard to do. As a person who started and ran a company and designed and built products on my own, I can vouch that it’s incredibly hard to do. But it’s going to be okay.

Hire the right people, keep them happy, and great stuff will happen.

Rachel: That’s some pretty powerful stuff, Steve.

Tools At Work

A short list of tools the folks at GitHub use to make their days a spot easier.

Chat

We use Campfire by 37signals. We utilize many, many different rooms to keep conversations focused and searchable. We have desktop and mobile clients, so we can communicate on the go.

Team

An internal twitter-style application, with web and mobile versions. We can push chat mentions, team statuses, and any other relevant information directly to people’s phones, as needed.

We can also post new ‘Ideas’ that can receive feedback from any employee to facilitate broad company-wide discussion.

GitHub

We obviously use GitHub.com to develop our software. We make heavy use of Issues, Pull Requests, and code comments to have a record of any conversation around building applications.

An idea conceived on iChat.

Carl’s new idea: let’s offer quality control and testing as a service to other web shops, front-end and back-end developers, etc. Carl did some asking around and found that this type of service would be viable for many we know in the industry. From there the internal planning, conversations and development began.

Several team members have contributed to its development over the last couple of months:

• Travis took the lead by creating a wireframe/prototype, doing branding and design, complete with a logo. He also made everything work.
• Rachel provided content guidance plus the words to convey the idea so it all made sense.
• Fred continues work on a custom management system that will be unveiled in future iterations of the service.
• Carl has been there for guidance, the legal bits, and as a sounding board.
• Me, I’m in charge so I’ve just been telling everyone what to do. And testing the site before it went live, of course.

Introducing QCat

The goal of QCat — pronounced q-kat — is to assist you and your business with one of the pesky steps that is of great importance to the outcome of each project: quality control and testing. We’ll test forms, links and interactions to make sure they work as anticipated, we’ll look for visual consistency, and test to see how everything functions on multiple devices (desktop, mobile), and in a variety of browsers. Now who wouldn’t want help with that?

You can get all the details at qcat.ngenworks.com. If you have any questions before submitting a request, please reach out to us at qcat@ngenworks.com.

By this point the place was starting to fill up with a mix of people on their way to work in downtown Austin, TX, and SXSW attendees looking for a non-crowded place to get breakfast. Dan got pulled into a conversation with another person who I’d never met and that left me and Carl just standing there. He was probably the one to say, “So…” first.

Thankfully, we didn’t talk about the web beyond noting what we did for a living. Mostly we talked about our kids. We both have daughters who are about the same age so we had a lot to talk about in that respect. He seemed like a cool guy. Eventually Dan rejoined us and we had a nice time just chatting and caffeinating ourselves up enough to make it to the Ginger Man that night.

Back home, in Boston, MA, at the time, I looked through my bag o’ schwag and started cataloging the business cards. And yes, by cataloging I mean recycling. But I found Carl’s card in the mix and decided to check out the nGen site.

On the team page, I realized I knew a couple of the people who worked at nGen. Also, I noticed that I was on that page.

Okay. It wasn’t me. But it could be…

Ten Months Later…

I was actually pretty happy at the place I was working prior to joining nGen. But I’d been working at large corporations for 12 years and the idea of working with a small, focused company, with people I know and like? Yes, please.

I jumped in right away working on a massive software and iOS project that’s launching soon, elbowed my way in to a couple of other things that were going on, and generally tried to make myself useful. What I came to realize pretty much right away is that in a company like nGen, being just the UX guy wasn’t going to be enough. Nowhere near enough.

In those 12 years of corporate life, I was as much a Generalist as I could be, but compared to working at nGen, I was definitely a Specialist. In the corporate world, you might get 1.5 hats, if you’re lucky. At nGen, more like seven; mandatory. Which is an aspect of working here that’s made me happiest.

I get to be a Product Manager for some of the more complex projects. I get to be a User Experience person on projects of all sizes and complexities. I get to help run New Business with Carl. I get to contribute to process discussions and development. I get to act as a consultant on projects that are run by other nGen peeps. I get to start building a local presence of nGen in Portland, OR, where I now live.

Basically, if I see something that needs doin’, I doin’ it. And I am welcomed and thanked for doing so.

Twelve Months Laterer…

As I write this, I’m drinking coffee and IMing with Carl, so in some respects nothing has changed in the last almost-two-years. Except, of course, I now work at a place where I feel like I belong. Is life perfect? No. I don’t have a Koenigsegg. That’s probably the worst part of all this. Unless… Hey, Carl? Can I have a really big raise?

Kelly gave a talk called “Workflow That Works.” She not only described her process, she handed out binders with nearly 100 pages describing everything she did to make a project work smoothly. Her client survey is used by almost every web shop I’ve ever met at some point. Many of them didn’t even realize it was hers. They just got it from a shop who got it from a shop.

Late last year I showed Kelly a process wiki that we created for ourselves at nGen. As we evolved our workflow it only made sense to create a living document we can edit on the fly. As I was sharing it with her, it hit me: I had the opportunity to pay forward that wonderful gift she had given me more than a decade earlier. As the nGen team kept working on the document, the idea of giving it away never left my mind.

A few weeks ago, as I read Leslie Jensen-Inman’s article about her experience as a female conference speaker, one sentence she wrote woke me up. “It’s our responsibility to leave our industry better than we found it.”

It’s our responsibility to leave our industry better than we found it.

– Leslie Jensen-Inman

So today I present to you the hard work of my fellow nGeneers. More than 100 hours have gone into the making of this document so far and we’re not even close to finished. In no way would we ever claim it’s the only approach, or even a good one for you. But it works for us. And since this is a wiki, we invite everyone to add their processes as well. We hope that this can become a place where the industry can learn and teach through sharing what we all do best. Create the future.

Ladies and gentlemen, we give you process.ngenworks.com.

P.S. Kelly, I still have my binder. ;)