In this example, let’s say we have a list of questions and answers that we want to show as an accordion. An accordion usually works like this: only the questions are seen, and when you click on one, the answer expands below it. When you click on a different question, the previously shown answer hides and the new answer expands.

Write the markup

For a list of questions and answers, you can use the oft-overlooked definition list element. Any similar markup pattern will work; this one is handy since it’s not often used for other things.

<dl class="accordion">
  <dt>Why is the sky blue?</dt>
  <dd>Because lorem ipsum</dd>

  <dt>Why is grass green?</dt>
  <dd>Because lorem ipsum</dd>
</dl>

Use whatever questions you want in thes and whatever content you want for the answers in the corresponding. Repeat the <dt> and <dd>
sets as many times as needed.

Include jQuery and a script file

Before the closing body tag of your html file, include a script link to the latest version of jQuery and to a blank script.js file that you create. It’s good to get in the practice of keeping your scripts separate, maybe even in their own directory.

In your script file

Create a blank function and call it from inside the jQuery ready method. Nothing will happen yet!

var accordion = function() {
  
};

jQuery(function($) {
  accordion();
});

The following lines go in your empty accordion function:

// first, hide all the answers:
$('.accordion dd').hide();

$('.accordion dt').click(function(){
  // after clicking a question, close any open answers in the list:
  $(this).siblings('dd').slideUp();

  // show the answer (item directly after the question) if it is currently hidden
  if($(this).next().is(':hidden')) {
    $(this).next().slideDown();
  }
});

And that’s it! Now it will work as described above. Here’s the full example without code comments.

Extra credit

You should probably make the questions look clickable so people will know to click them. The bare minimum would be to add this to your CSS, which will change the cursor when hovering the question so it looks like a link:

.accordion dt {
  cursor: pointer;
}

You could also wrap the questions in a link, but this will require some other changes to your markup and jQuery.

You might also notice that the questions are visible for a second or so when first opening the page. That’s because we are hiding the questions with jQuery which is called after the page loads. Viewers without javascript will see the fully expanded question list. Avoid this flash of unstyled content by adding display:none; to a .accordion dd CSS rule, and you can get rid of the first line in the accordion function.

Have fun

The result of my pondering and research ended up being both a template of .scss files that go into each project, and a concept for defining the elements that make up a web design. So here’s what I’ve come up with: it’s nothing revolutionary, but I like seeing how other developers do things, so maybe you will too!

Core Concept: Modules and Components

You hear a lot of developers talk about modules in all kinds of development. Modules are re-usable bits of something. In CSS, you might have a button module or a breadcrumb module, or anything that you might use multiple times within a site or app. Now, modules are great, and it’s always good to be as DRY as possible, but I’ve come to acknowledge that not everything is a reusable module, and if I start treating every element on my page as something I’m going to use again in another context, I’m usually just fooling myself and spending too much time trying to abstract something for the sake of abstracting.

I now recognize that the sites and apps I work on tend to comprise both modules and what I’m calling components. Components may not be the most accurate term here, but it’s what I’ve come up with. Components are all the bits that make up your web site or app that occur only once, or only in one context. Things like your page header or footer or sidebar. Sure, you could have multiple headers or sidebars or footers, but in a lot of cases, you know that you won’t. You might still have multiple instances of a component, but you’re only using it in the one context. If you need to use a component in more than one context, you should turn that into a module. I the main difference between a module and a component is context: a component is context-dependent, a module is not.

Markup

I’ve never been all that vigilant about commenting my code, but I’m really pushing myself to change that. Since I know I’ll have coworkers working on the same code that aren’t familiar with my little system, I know I have to make everything as clear as possible. I use a system of corresponding HTML and SCSS comments to make it clear to anyone reading the HTML where in the SCSS they can find those styles:

File Structure

I always have a main.scss file that imports all other scss files and compiles to main.css, the files I include are fairly consistent, but sometimes change a bit depending on the project:

The order here is important, both for css specificity reasons and scss inheritance reasons!

Example: Space Apps Toronto

The team at The Phuse is working on something pretty exciting this spring: we’re helping organize a hackathon here in Toronto called the Toronto Space Apps Challenge, and my coworkers and I have been developing the event website.

Props to my coworker Tom for the awesome design.

It’s a fairly simple website in that it’s only 3 pages, but there’s a lot of content, a lot of images, and a somewhat unusual grid system going on (18-columns instead of the usual 12 or 16).

Component: Schedule

To illustrate my component/module distinction, I’ll go over an example of each. In the ‘Schedule’ section of the Space Apps Toronto website, there are 3 schedule tables, one for each day of the hackathon.

The .schedule-table element is repeated: there is one for each day, but it is context-specific: this layout is specific to displaying this kind of content. I could abstract this out to something more generic (and maybe later I will), but at this point that isn’t necessary and makes the code harder to navigate.

The code looks something like this:

HTML

SCSS

Module: Callout

On the Space Apps website, I have several areas that are visually similar though semantically unrelated: the schedule for the pre-event party, the lists of media links on the press page, and the schedule for the NASA Youth Space Challenge page. This sounds like a good example of a module! I decided to call it ‘callout’ because it visually emphasizes the content inside it.

The code looks pretty much the same as it does for a component, but it lives in a different file:

HTML

CSS

On the Youth page, the schedule element is both a module and a component: It shares the callout styles with the press and pre-party schedule elements, but also has it’s own context-specific styles associated with the schedule component. (I’m re-using the schedule element here, but it remains a component and not a module because the context is the same).

Conclusion

I’m aware that this approach can seem backwards: treat elements as context-specific and abstract as needed, as opposed to abstracting everything and then adding specificity. I don’t have anything against the latter approach in theory, but in practice, I find I often end up with much messier code, because inevitably my re-usable modules need to be altered in one place but not another, a client or designer points out that actually those two elements should have different padding, or the text shouldn’t be bold in module instance #2, and suddenly the instances of my module are more different than they are similar, and at that point why even bother?

Surprisingly, I’ve found it easier to abstract out a component into a module as needed than to add increasingly specific styles to each instance of a module as a design grows and changes, and it leaves me with modules that exist out of necessity, rather than just for the sake of abstraction.

I’ve only been using this approach for 3-4 months, but it’s working well for me so far, and considering that after about a month of coding something I usually look at it and think it’s garbage, this is holding up fairly well. I’m always looking for ways to optimize my technique, and I’m currently experimenting with making heavier use of the Sass @extend function to create components as extensions of modules (but that’s another blog post…). I’m always looking for feedback with my coding techniques and methods, so feel free to leave your thoughts!

Imagine this scenario: you pop your new declarations into one of your stylesheets and reload the browser expecting things to be perfect, and they would be because you’re a kick ass developer, but nope, not so fast! Your elegant and masterful styles aren’t even showing up! So you pull up web inspector and see seven selector chains and their styles fighter for supremacy over the style of your elements. Not cool.

It’s alright though, you’ve got this. It’s not rocket surgery. It’s internets math!

Rendered styles are no coincidence; there’s a specific order of precedence. Let’s get you back in control.

1. !important

`!important` is a trump card. It will always win over any declarations, even inline declarations, but you should avoid using it at all costs, unless you’re up against CSS from an imported framework. When you find yourself wanting to use `!important`, a much better option is to refactor your styles to eliminate the conflict.

2. Inline CSS

Inline styles, styles applied within a HTML document, win over everything in your stylesheets. They should be avoided like the plague, though, as you don’t want to mix the styles with the content, and having styles in two places is confusing. HTML is concerned with content and CSS is concerned with styling. Let’s let both of those files do their jobs.

3. IDs

Even though `a.bar` targets a more specific type of link, the specifier with two IDs in the chain will override the first snippet.

4. Classes

Yep. Same thing as the IDs. Most of your miscellaneous fancy selectors, `.foo:not(.bar)` for example, also fall into this level of effectiveness. It’s important to note that selectors containing IDs will always win out over selectors that don’t, so even 100 classes won’t override an ID. 256 classes will in some browsers, but… please don’t do that.

5. Elements

For the sake of this discussion, that leaves basic element selectors.

Classes can cut out a lot of the pain that comes with nested elements, so don’t be afraid to name all the things!

Go Forth and Style!

Hopefully this gives you a better comprehension of the order of precedence styles take in your projects. With this rough outline, you’ll finally be able to get things looking how you’d like without any extra clutter or conflicts.

Stay Organized

Everyone will find their own system that works best for them, but here’s what I do: to-do lists. Whenever a new task or something to remember pops up, I write it down. I used to keep to-do lists in my head, or not go into as much detail, but putting a bit more in writing clears up brain space for other things, and greatly decreases the likelihood of forgetting something.

Each morning I look at what I can tackle for the day and put those tasks at the top of the list in priority order. It may take a while to learn to gauge how long certain tasks will take for you, but by tracking your time you can get a better feel for it. I usually prioritize by deadline and move tasks around to fit into work hours for the day.

I also keep a simple text file with details (like milestones, logins) for all projects I’m currently on as an overview. The different levels of organization help me keep a big picture view and zoom in for details. Project management apps can do that too, but if you use them with your team or clients, they can get cluttered. Not only does keeping my own lists keep me organized, I find that the simple act of writing things down helps with remembering them.

Stay Productive

The best way to be productive is to just do the work. Sounds simple, but sometimes it can be hard. How do you feel when you put off work, or avoid doing things you know you should be doing? You might have the nagging feeling that there is something you should be doing, or something that you are forgetting. The more you put things off, the more the pressure builds. Simple little tasks start to look overwhelming. Procrastination is a downward spiral and, like with any habit, the more you repeat it the harder it is to break. Imagine how good it will be to have the weight your to-do list lifted, and start actually doing those items. Form a new habit of doing, and you will feel happier and healthier.

Sometimes, even with the best of intentions, you may find yourself dreading some important task or wanting to put off work. In that case, I suggest productive (or structured) procrastination.

Stay Motivated

My daily to-do lists are essentially daily goals. Sometimes I celebrate reaching those goals with little rewards! It doesn’t have to cost money or be something you do every day. For example, a nice warm bubble bath at the end of a long day feels like a reward. Keeping a box of bite-sized chocolates around to snack on after crossing off a to-do works, too.

When you enjoy your work, just knowing you’re doing a good job is enough. Other times, you may give yourself a little push to accomplish things by telling yourself you can have ___ if you complete your tasks. If you have a hard time keeping yourself accountable, enlist the help of a friend or family member.

Stay organized, productive and motivated! It sounds simple, but really requires some self-discipline that, if you don’t have, you can learn.

What challenges have you faced regarding working from home or any of the above points?

Working on the Internet has many perks. One of them is that we work remotely. The Phuse has team members in Canada, The United States and England, which means we have the ability to work on our own schedules, using our own techniques, in whichever chair we choose to sit.

However, in this line of work, communication is absolutely critical. Taking a project from concept to completion requires a solid connection between all team members. Without a physical office and the ability to shout annoyingly across it to a teammate, we must take great care to ensure our communication is consistent and top-notch. Any breakdown in the communication process could potentially cause disruptions with the client’s timescale and budget, and that’s what should ultimately be avoided.

“We are not self-made. We are dependent on one another. Admitting this to ourselves isn’t an embrace of mediocrity and derivativeness, it’s a liberation from our misconceptions.” – Kirby Ferguson

Why Have Audits?

Our developers have carried out code-audits for a while now. They prove to be extremely useful as it ensures they are using optimal techniques to create a website or application which is built to last. It’s a chance to share, learn and collaborate.

So, if it works so well for them, surely it should work for designers? Therefore we recently started a series of weekly design audits. These are essentially short meetings in which our design group can get together on Skype and share what we have been working on during the past week. We start off by discussing the projects we’ve been hacking on and any problems we may have faced. Then we take turns to share screenshots of design work and ask around for critique. This is in addition to weekly kick-off meetings and an almost constant line of communication whilst working.

This new method of communication allows us to develop our critical thinking and improve the way we express ourselves through other people’s work. Also, as any other web designer will tell you, the longer you work on something, the easier it is to see your design through rose-tinted spectacles. Using another set of eyes gives us the chance to discover potential flaws in our design, which a client or another team-member may not have initially noticed.

This has improved our work process by opening up our own little project eco-systems to the rest of the team. It re-enforces the knowledge that, despite living thousands of miles apart, we can still work together, help each other and enjoy doing what we love the most – design kickass web stuff!

Global Jet via Compfight cc

A successful project starts with a complete understanding of the design process on both sides. If you’ve ever had trouble explaining your design process to clients, using a metaphor will help you get to a deep understanding quickly, without having to go into too much confusing technical detail.

So far I’ve only found one metaphor that fits. When explaining the design process to clients, I begin by telling them, “We’re the race car, and you’re the driver.” This establishes our roles early in the discussion. The details follow from that.

To swiftly reach a deep understanding, nothing is better than a good metaphor.

Don’t Bore Them with Details

In the past, when I wanted to explain the design process to a new client, I dove straight into agile methodologies, the iterative process, personas, wireframes vs. mockups, frontend vs. backend, bla bla bla. I could barely listen to myself talk without nodding off!

Now, when a client asks about our process, or what to expect when working with a design studio like The Phuse, I start with the metaphor.

“We’re the race car, and you’re the driver.”

One short sentence acquaints them with their role in the process. We can then use that as a jumping-off point to elaborate on their understanding.

“We’re the race car.” We keep the project on course. The studio’s purpose, as the vehicle of the driver’s success, is to move us swiftly towards the finish line.

“You’re the driver.” You define the goals. The client’s duty, as the driver of the vehicle, is to define the rules and milestones of the race.

The Race Car and Driver Metaphor

To further flesh out the metaphor, here’s a little sketch. I hardly ever repeat this story in its entirety, although I may use a sentence or two as appropriate. Good communication is about going with the flow, not reading from a script.

For the purposes of this article, however, I find it educational to see how well the metaphor matches up with our process.

“We’re the sleek exterior, the power steering wheel, the curving headlights illuminating the road’s next bend. We’re the anti-lock breaks, the record-breaking response time, the suspension that absorbs any imperfection in the road.

This automobile is smart. It’s made of many moving parts that all work together. It’s also adaptable—it can change directions with ease and stop on a dime.

But we’re nothing without our clients. Without YOU. You’re the most important part. If we’re the race car, you’re the driver. You tell us which track to drive on and how far to go. We can tell you how many miles (hours) we’re getting per gallon (out of retainer), but it’s your job to put fuel in the tank, turn the key, and step on the gas pedal.

Your goal as driver is to get us to the finish line. We’ll get you there in record time—and with style—but it’s up to you to determine where the race starts, and how to tell when we’ve reached the finish line.

What’s at the finish line? Good question. Your users are there, waiting to admire the work we’ve done together.

And at the finish line, when the MVP meets your users—that’s where the team finds its glory.”

Completing the Circuit

Nothing beats that car metaphor to convey a full understanding of our respective roles and responsibilities in the project. We want to empower clients, to work with them as a team, which is why the race car metaphor works for us.

We put the client in the driver’s seat, and our job is to take them swiftly and safely to their final destination, but we work best as a team. The best car in the world won’t win the Indy 500 without a capable driver behind the wheel. Similarly, the driver needs a top-notch machine that can handle the curves and carry them across the finish line without breaking down on the way there.

The State Of jQuery—Dave Methvin

The conference kicked off with jQuery Foundation president Dave Methvin giving his ‘State of the Union’ address about jQuery in 2013, which was great timing, since jQuery 2.0 Beta 2 was just realeased on Friday. Key takeaways:

• jQuery 2.0 does not support IE 6, 7, or 8. It’s being developed alongside jQuery 1.x (currently at 1.9.1) and maintains an identical API. They’re not expecting people to be using jQuery 2.x in production any time soon, but they really would like people to test out the beta!
• I’d somehow never heard of the newish jQuery Migrate Plugin, which can detect and restore deprecated features that are being referenced in your code when you’re running 1.9. Though intended as a tool to help you bring your code up to date with jQuery 1.9.x, it will also just patch in missing functionality to save the day if you’re *gasp* using deprecated functionality like .live() and $.browser (but you’re not, right?)
• jQuery now supports modularized custom builds that can get you down to just 17kb if you can live without Sizzle, animations, event aliases, and css. If you’re using plugins, don’t do this, as they most likely depend on something you might exclude.

That’s right, reject any module in our jQuery reality and substitute your own.
— Dave Methvin

Hardware Access and Device APIs with JavaScript and HTML5—Wes Bos

Toronto JavaScript guru Wes Bos gave a fun talk about accessing hardware APIs on mobile devices using JavaScript and HTML5. He talked about speedometer, accelerometer, camera, and file access, and showed us how he built a super cool security/mail camera with a live feed to his computer using WebRTC, node.js, socket.io, and a Nexus S.

It was cool to see how easy it is to access device hardware these days, but my favourite part of Wes’ talk was how cleverly he managed to solve his first-world problem (home office in back of house, mail comes to front of house) using the technology he already had and knew. I’ve often thought about attempting this kind of project myself, but always thought I’d need to obtain an Arduino and learn C. Now I’m planning on turning my old Galaxy S into a next-bus-display in my kitchen using my local transit system’s API.

Check out the HackPad and the slides

Bower and Grunt

Conveniently, after I spent Friday playing around with Yeoman, I attended two talks about two of Yeoman’s main tools: Ralph Holzmann of Twitter talked about Bower and other client-side package managers, and Dan Heberden gave a talk about Grunt for running tasks. I was already leaning towards trying out these tools for some of my projects, but now I’m more solidly convinced and feel like I have a good starting point.

Awesome Chrome Dev Tools

Paul Irish’s highly-anticipated “Front-end Dispora 2013″ talk covered a lot of ground, from CSS selector optimization (hint: don’t bother) to Chrome’s new requestAutocomplete() feature. My favourite part of his talk was watching him demo some awesome new and not-so-new features in Chrome’s dev tools (most only present in Canary). Some favourites:

• He didn’t seem to think it was a huge deal, but the ‘un-minify’ button got a huge reaction from the crowd, and I’m pretty excited about it.

This button un-minifies production code!

• Pressing H when you have a DOM element selected in the web inspector will toggle visibility:hidden for the element. This feature is actually present in Chrome Stable, and I’m sure it’s going to be super handy
• Pressing ? brings up a list of keyboard shortcuts for dev tools, as well as links to settings
• Check out the ‘Overrides’ settings: you can play with user agent, as well as set screen resolution and orientation, override geolocation, emulate CSS media types, and emulate touch events with click
• Enable dev tools experiments by heading to about://flags, then pick which experiments to try from dev tools settings.
• Cool dev tool experiment: Snippets. Snippets gives you a multi-line console to run code within your browser and lets you create and save various named scripts. Once you’ve enabled Snippets support, you can access your snippets from the Sources panel, in the Snippets tab. Right-click to create a new snippet, then just click ‘Run’ to run it. Save a snippet with CMD+S from within the editor. You can also run single lines of code within a snippet by highlighting the line, right-clicking, and selecting “Evaluate in Console”. Sweet!

Create and run multi-line scripts from the browser using Snippets

• Another experiment he went over was Inspect Canvas. Enable this experimet from dev tools settings, then head over to the Profiles panel and select “Capture Canvas Frame” and click “Start”. The resulting trace log gives you a play-by-play of all the canvas calls recorded and lets you replay them step-by-step.

Inspecting the canvas of a shooting-stars experiment I did.

Gone in 60 Frames Per Second—Addy Osmani

Addy Osmani’s talk about framerates, scrolling performance, and paint/repaint times was worth the price of admission itself, and the many audible gasps and ‘wow’s from the audience suggest I’m not the only developer whose mind was blown. This talk was a huge eye-opener and will definitely change the way I approach performance. Some key points:

• Framerate is extermely important not only to site usability and the perception of speed, but also to user engagement. A framerate of about 60 frames per second creates the appearance of a seamless, smooth experience, while lower framerates give you the appearance of ‘jank’, where you can see frames changing. Facebook did tests with lowering the framerate of their native iOS app, and saw user engagement plummet.
• Framerates tend to be dramatically lower on mobile devices, so if you’re hovering just below 60 frames per second on desktop, you’re likely under on mobile.
• Chrome has an advanced selection of tools for visualizing and monitoring framerate, go to the Timeline panel, select Frames, and hit record for a couple seconds. Scroll up and down a bunch to record behaviour, then check out the results.
• In the resulting graph, tall, coloured bars indicate your expensive processes. Click on a frame to see what’s going on, and drill down through the listed events to see what’s costing you. The most costly events are layout and paint/repaint. Things like resizing and decoding images, recalculating sizes and positions, using some CSS3 properties (box-shadow is shockingly brutal), putting too much JS functionality in your event handlers (especially scroll), and using position:fixed will really kill your framerate and scroll performance.

This website’s main offenders: costly image resizes

• When you can’t avoid things like fixed positioning, you can improve performance on desktop by forcing GPU acceleration with null-transform hacks like -webkit-transform: translateZ(0). There are a lot of caveats to doing this, and it won’t help you out on mobile, but it can be handy in some cases.

Addy went over much, much more in his talk and covered exactly how to find and fix your performance problems in devtools, and you can read all about it in the slides for his presentation.The presentation was full of practical advice on debugging and improving performance, and I highly recommend you go through the slides.

Conclusion

There were many, many other awesome presentations, and I’d never be able to summarize all the valuable information I’ve absorbed over the weekend, but a huge thanks to all the presenters for sharing their vast knowledge. Slides and HackPads for all the presentations shold be posted on the jQueryTO website in a couple days, they’re all definitely worth a look.

As it turns out, the functionality he wanted could be added with 6 lines of jQuery (5 lines with CoffeeScript):

While jQuery’s extensibility is one of its greatest strengths, and the many brilliant plugins available often solve a lot of problems and open up a world of options to the novice developer, if you’re an experienced front-end or back-end developer looking to hack together an interface, plugins are not for you.

jQuery plugins for common interface elements like slideshows, dropdown menus, tabs, and the like are a fantastic resource for beginners and hobbyists trying to add functionality to their websites, but if you think of yourself as a developer, you’re better than that. jQuery plugins try to be all things to all people, but if you just need a simple tabbed content box, you’re going to be loading in a lot of code that you’ll never even use.

If you have a basic understanding of JavaScript DOM manipulation, you can easily roll your own re-usable solution with only a short time investment. The benefits of writing your own jQuery modules are extensive: you’ll save thousands of lines of code, avoid version compatibilty issues, and dramatically speed up debugging through your familiarity with the code. Write your code flexibly and modularly, save it as a Gist and next time you need it, you’ll spend even less time than you would have including and referencing a plugin.

Some Common Examples

I keep a library of GitHub Gists that includes snippets of copy-and-pastable jQuery interactivity modules, and using the Sublime Text Gist Package, I include them wherever I need them and often share them with coworkers and fellow developers. You’ll notice that none of these snippets contain any exceptionally clever customization options or fancy CSS. They’re meant as a baseline to give you the interactivity you need without adding any styling or behaviour you don’t.

Rather than thinking of these snippets as ‘plugins’, I think of them more as ‘modules’, and try to keep them in my modules.scss and modules.js files for easy debugging and reference.

Tabs

This kind of thing.

Just a simple unordered list with same-page links to the associated divs. Just match the IDs to the hrefs and you’re good to go.

Vertical Accordion

This one is pretty much exactly the same as the tabs, using the href attribute of a link to target an element.

Multi-Level Navigation

Supports up to 2 levels of nested unordered lists, sub-navigation appears on hover, but could easily be altered to work on click with some javascript.

Dropdowns

Just a simple show/hide element attached to a click event. Click the trigger to show the dropdown, then click off the dropdown to hide it.

Work Smart Not Hard

There are many situations in which a jQuery plugin can save you a lot of time dealing with cross-browser compatibilty issues or responsive design, and help keep you under budget when you’re facing time pressure. For many complex interactions and features, using a plugin is often the most sensible choice. However, if you’re looking to add some basic interactivity to your project, it doesn’t hurt to ask yourself a couple questions before dropping in that popular new plugin: could I code this myself in the next 20 minutes? How much of the code in this plugin will I actually be using? How many lines of CSS will I have to override to make this fit into my design?

If you’ve got some handy little scripts of your own you’d like to share, link them up in the comments and I’ll add them to the list!

Photo: Pip R. Lagenta via Compfight cc

Personas get complicated very quickly as different types of users are added with different objectives. This complexity makes it tough for designers and clients to be on the same page in conversations and leads to a great deal of confusion as the project evolves.

To avoid this confusion, we started using storytelling as a tool. What we’ve found is that including storytelling in our mockups improves the communication between us and our clients.

By using storytelling, we’re creating a consistency between words and images that has allowed both clients and designers to be specific about what is being shown for who, ask relevant questions about specific user types, and be show precisely how changes to the design can affect users’ decisions. But before we do any of this, we need to make sure we’ve got the terminology clear so there isn’t any confusion.

Terminology: Laying the groundwork

When scoping out a project, we make sure to know who will be accessing it. Everything we can find out, from demographical information like age and gender, to usability information like device and access point is collected.

We also make note of a user’s objectives based on their role. For example, is the user selling an item, or are they shopping? Defining these roles early is important because it gives us insight into functionality that needs to be sorted out in the work we’re doing.

Once we know the different roles and objectives, defining them with consistent terminology is something we advocate strongly with our clients. In personas this means names for different users (“Joe Seller” and “Bob Buyer”), but this can be as simple as “Buyer” and “Seller”. The majority of our team’s communication with clients is over Basecamp messages, so getting this terminology down right away makes everyone’s lives easier. Not to mention if a client asks to see what a “Seller” sees when they access a dashboard, our designer knows right away what the client is referring to.

Having different people refer to the same role in two different ways or referring to the same page in multiple terms is when things get confusing. Right at the point of confusion we pause and get the terminology clear. Forcing everyone to stop and do this makes everyone sharpen up. Most times we only need to have this happen once in any project for everyone to remember that other people need to understand what they’re saying.

An example of this on a recent project we’ve been working on was the terminology between Learning Events and Learning Materials. Learning Events were “containers” that held Learning Materials. Having these two terms thrown around in conversations while defining hierarchies and looking for iterations to designs got messy initially. After defining them properly across the team, we were able to better understand the needs of the users, as well as engage in understandable conversations with our clients.

Even better, on that same project: Classes and Courses mean different things in the UK than they do in Canada and the U.S., so defining even what would seem like the simplest things can help avoid confusion down the road.

Storytelling: Putting designs in the real world

A good designer is a good storyteller. And like any good storyteller, referencing imagery in the text is important. Usually this is done by explaining interactions or thoughts, but tying in personas to designs to explain how the user would complete an action is powerful. By simply integrating personas into your designs and delivering them using proper terminology and making reference to the personas, suddenly they’re relevant.

We can do this by using the personas’ names in designs (e.g. if you’re creating a profile for a Buyer, use “Bob Buyer” and stay consistent for all pages related to Bob’s experience), and referencing the terminology we’ve all agreed on in the designs. Now when clients see Bob Buyer’s face and name, they know right away that the screen was designed for Buyers.

Using storytelling as a tool improves how clients perceive our designs by making sure more complex concepts are broken down into digestible chunks. When clients come with drawings of the way they imagine things to work, it can be tough to explain to them that there are better ways of completing a certain task. But by using storytelling, the client is forced to stand in the shoes of their users and imagine their path to complete that same task.

Delivery: Making designs make sense

All of the above is about execution, and the combination of the two strategies (personas and storytelling) to make designs make sense. Weaving both design and explanation together allows our designs to have their own stories and be more than just bullets on a page. When problems arise in design, things can be explained in a straightforward way by making reference to the personas and terminology created so that it can be understood in the design.

These stories help shape the user’s experience because everyone isn’t just focused on getting all of the elements on the page: they’re focused on creating something that is well thought-out and intuitive for the users.

Bringing it all together

While this article references the importance of storytelling with special regards to distributed teams, this is equally as important in a product-driven team, and teams that are working alongside their clients. Whether you’re delivering your designs in a project management tool like we are, over email or in a boardroom, how you explain your designs determines the kind of feedback you’ll receive.

By adding storytelling to your discussions and making use of personas in them, you allow terminology that you’ve created to be used and live throughout the design process. Breaking things down in steps is important for any team, and how you bring it together towards delivery is crucial to a smooth project.

James’ hair looks like this.

Like most other people, I get nervous with the thought of new hairdressers as the negative effects (e.g. terrible looking hair) are things you have to live with for weeks afterwards. Finding a good hairdresser for most of us is not only tough, but takes a lot of trust. I couldn’t tell you how much money I’ve spent at high-end salons to get my hair done, still never finding a place that did a consistently good job.

It started getting me to think about the position I was in hiring people for The Phuse, and how meticulous small businesses especially have to be when selecting the people they hire to do the work they do. Hiring isn’t just about bottom lines and getting work done, it’s about raising the bar in your work and maintaining trust with your clientele.

When I first started The Phuse, I was the sole designer and front end developer, and clients not only knew who I was, but had my personal phone number and full trust that I would do the best job out there. Every hire I made past that point was an extension of the work I was doing, and as such I had (and continue to have) a very important responsibility in choosing the right people.

Every hire we make at The Phuse is as much a reflection of ourselves as the work we produce. We’re super picky about who we hire because we know our clients expect a consistently high standard from us. Our clients are buying into the trust they have of the leadership of the company as much as the work we’ve done in the past, and we don’t take that for granted.

Sitting down at the salon afterwards to get my eyebrows waxed (I’m Portuguese, I have bushy eyebrows, don’t judge me), I noticed a lady who came in and refused to have the new hairdresser touch her hair, and it made me realize how lucky we are to have clients who trust us.

We know when clients come to us they have a certain level of nervousness. They’re working with a team that they truly believe will determine a part of their product or service’s success or failure and are spending money out of their (or their investors’) pockets that they need to be careful with. Building trust is an important part of the work we do and it starts from the first experience the client has with us.

We’re strong believers that the best form of marketing we do is by doing amazing work for our clients, so when the people they refer to us walk through our virtual doors they already have built trust. Throughout our process we don’t take this for granted as we know when working with a distributed team, trust is crucial to a successful execution of our process. Little things like having kickoff calls with the team or setting expectations on timezones and feedback loops show that we believe as much in what they’re doing as they believe in us.

We don’t hire “B” team members that we put on smaller, less important projects because every project we work on is as important as the next. We take the quality of our work seriously because that’s what we know our clients want. Therefore, hiring is just as important—if not more so—than the work we do every day. If we didn’t do it properly, we would not only have gaps in our process but have issues throughout it with quality and everything else. Our work is a reflection of the quality of the people we hire, and as long as we continue to have referrals I know we’re doing it right.

So as we hire more and more frequently with the amazing growth we’ve seen throughout the last year, I know I’ll always think back to my friendly neighborhood hair salon and the owner who really knows what she’s doing, because I love my Ryan Gosling hair.