productdesign

Rise of the Product Managing Designer

The design team at Skillshare does a lot more than just design. We’ve learned that to be as effective as possible we need to break out of our traditional role and own much more of the overall product process.

Not to say that the world does not need product managers, but by equipping our design team with skills like a deep understanding of business, operations, and analytics we’ve been able to create more impactful products at a higher velocity. Below are a few core competencies of a product managing designer.

Understand your company’s business needs and goals.

Product managers tend to have a handle on the big picture. They understand the inner workings of the business, its goals, and the focus of each team.

Without this understanding, it is nearly impossible to judge a good product idea from a bad one. Even worse still, you will be rendered unable to anticipate the repercussions of your decisions unless you consider how it relates to the larger whole.

It is critical for Skillshare’s design team to have a comprehensive understanding of the ecosystem and how each project will affect it. We do this by syncing on strategy with everyone who might have a stake in the game early and often. This happens well in advance of the formal design process. By aligning with the relevant teams, we are quick to understand how our strategy will be helpful or hurtful to them. For example, syncing with the content team on the tools they use to create classes informs what strategies we ultimately push and enables us to move forward confidently.

The Skillshare design team has gotten very good at choosing what strategies to pursue, and perhaps even more importantly, what doesn’t look like it will work, before we ever start designing.

Design doesn’t matter if it never ships.

Product managers are judged on their ability to get things out the door. This means they’re relentless when it comes to minimizing scope and sticking to a schedule in order to maximize their impact. They’re also great at taking a complex strategy and breaking it down into manageable chunks.

Because our product managing designers are responsible for strategy as well as timeline, we rarely design features that would take more than a week to build. That’s not to say we don’t work on big projects. It simply means that we invest upfront in working through how we can break a project down and get smaller pieces out the door (prioritized by impact). We quickly and effectively ship the “must-haves,” but will often deprioritize the “nice-to-haves.” This is a fact of life for a small product team, but the benefits far outweigh the negatives: 1) smaller releases are easier to QA and support, 2) much easier to iterate and 3) reduces product debt with bloated features that no one uses.

This way of working provides a strong sense of accomplishment for the product team. It also helps boost momentum companywide, since progress builds energy and keeps people excited. At Skillshare, we send a companywide email every time something ships out to the site. We believe it’s important to celebrate the wins.

Own the metrics and feedback.

Product managers tend to be an analytical bunch. Once something hits the site, they immediately start assessing its impact to see if the new feature in which they have invested so many resources is working properly.

Product managing designers need to be the same way.

At Skillshare, this means setting the right goals (realistic and measurable) at the start of a project during the strategy and alignment phase. We then loop back around immediately once something has launched and measure its effectiveness. We also keep a close eye on all other feedback sources, such as engaging with angry (or happy) tweeters or gauging user reactions with the help of our support team. Taking initiative to actively monitor results and then being proactive about updates is the only way to make a smart path forward.

This may all sound obvious, but it’s easy to ship work and forget about it. If you don’t actively reflect on your successes and failures, you will never learn what works and what doesn’t.

To dive even deeper into how Skillshare builds product, you may be interested in: Optimize Your Team for Impact over Speed or Golden Rule of Managing Up.

Motion Ui Design Principles

This blog is a quick look at some simple Ui motion design principles.  There isn’t too much documented about this area of mobile ui design and I thought there would be some value in expressing my views.   From what is documented already I urge anyone interested in ui motion to check out Pasquale D’Silva http://psql.me/ and Johannes Tonollo’s meaningful transitions http://www.ui-transitions.com/#home.  

Also make sure you bookmark http://littlebigdetails.com and http://capptivate.co.  (A special thank you to Capptivate.co who allowed me to use their captures below).   

These basic principles I’ve outlined focus more on the what and why, rather than the how to of motion / animation.  With the increasing emphasis on motion (largely thanks to the more paired back design of iOS 7) its important that it is implemented with the same integrity and purpose as all the other aspects of Ui design.  With the exclusion of skeuomorphic design there is now a freedom for content to behave in an unrestricted manner.  Gone are the awkward and sometimes absurd transitions that appeared to break all laws of their pre-defined physical environment.  Now the space has opened for there to be a much richer identity and defined language or landscape to mobile Ui and motion is very much an integral part of that.

Personality.

The most obvious principle is that any motion or animation should be of the highest standard possible.  Apps should look at going beyond “out of the box” motion solutions and making something bespoke and truly engaging.  Within the app the motion should convey a distinct character, whilst keeping a clear consistency throughout. Behaving in an expected manner will help maintain a stable relationship with the user keeping them engaged with experience.  

 http://capptivate.co. https://twitter.com/CapptivateCo Paper Makes use of a scale overshoot through out the app, giving it a clear and distinct character.   

 http://capptivate.co. https://twitter.com/CapptivateCo

Paper Makes use of a scale overshoot through out the app, giving it a clear and distinct character. 

 http://capptivate.co. https://twitter.com/CapptivateCo   Dots carries through a very relaxing inertia which is prevalent through all aspects of the Ui.  Again making it definable against other apps.  

 http://capptivate.co. https://twitter.com/CapptivateCo

Dots carries through a very relaxing inertia which is prevalent through all aspects of the Ui.  Again making it definable against other apps.  

 

Orientation.  

Motion should help ease the user through the experience.   It should establish the “physical space” of the app by the way objects come on and off the screen or into focus. It should aid the flow of actions, giving clear guidance before, during and after.  It should serve as a guide, keeping the user orientated and preventing them from feeling lost, reducing the need for additional graphics explaining where they are or have been.

 http://capptivate.co. https://twitter.com/CapptivateCo   Yelp shows a great example of drawing focus with a intelligent and well crafted animation. Making keeps the user orientated when drilling down into a category with a simply elegant transition. National Geographic keeps the user aware of where they are and have been with a good use of 3d perspective.   

 http://capptivate.co. https://twitter.com/CapptivateCo

Yelp shows a great example of drawing focus with a intelligent and well crafted animation.

Making keeps the user orientated when drilling down into a category with a simply elegant transition.

National Geographic keeps the user aware of where they are and have been with a good use of 3d perspective. 

 

Context.

Motion should give context to the content on screen by detailing the physical state of those assets and the environment they reside in.  Without the restrictions of skeuomorphism the ui is free to behave in any manner with out seeming contradictory to its pre defined environment.   Adding a stretch or deform to an object or applying inertia to a simple list scroll can make the experience much more playful and engaging.  

 http://capptivate.co. https://twitter.com/CapptivateCo

 http://capptivate.co. https://twitter.com/CapptivateCo

 

Responsive.

Motion should be responsive and intuitive.  It should react in a way that reassures the user, rather than surprises or confusess them.   The reaction of the ui, to a users actions, should be complementary and comprehensible.

 http://capptivate.co. https://twitter.com/CapptivateCo    

 http://capptivate.co. https://twitter.com/CapptivateCo

 

 

Emotive

It should evoke a positive emotional response, whether that be comfort from a smooth scroll or excitement because of a well executed animation transition.

 http://capptivate.co. https://twitter.com/CapptivateCo

 http://capptivate.co. https://twitter.com/CapptivateCo

 

Restraint.

Steer clear of distracting or even confusing the user with too much animation, Subtlety is key.  It should be used to maintain or help focus.  Not take it away.  Also don’t over elaborate aspects such as screen transitions. This becomes increasingly frustrating to the user over time.  Or if they are simply left waiting for what seems like “forever”. (there are no examples of this as its a not to do - and i’m not in the habit of kicking peoples work in the nuts)

Source

14 Different Ways of Product Design

After my dribbble post with picture of a Diagram with very positive feedback and lot of questions, I was motivated to create this article about my process and what I’ve learned after 2 years of this journey.

It’s a bit hard to say that I’m always using this same process, but you can read it similar to an ideal process. I’ve divided this process into 4 parts — Pre-process, Work process, Post-process and tips for Productivity.

Pre-Process

1. I’m drawing

It doesn’t matter if it’s paper, a notebook or just a small piece of something. I need to share the ideas in my head. I need to put these ideas down where they can be saved and not forgotten. Consequently this means that I have some sketches on my bank statements, bills from restaurants, book covers etc.

Sketch of old idea

However, for me it is ideal to have something tangible, for example, on Moleskine. It’s always nice to go through these lists from time to time, look at my old ideas and try to reinvent or recreate something for this particular project or different idea.

2. Collecting Pictures

“An artist is a collector. Not a hoarder, mind you, there’s a difference: hoarders collect indiscriminately, the artist collects selectively. They only collect things that they really love.” — Steal like an Artist (Austin Kleon)

Another pre-process phase is the collecting of pictures, I do this everyday. There is definitely hundreds of styles on how to collect and view these images, however I particularly prefer old school style — Dropbox folder separate to different categories (Dashboards, iOS, Illustrations etc.). Then, when I receive an inquiry or project, I’m going through these images and I’m trying to find inspiration. Dropbox is pre-caching low quality previews of files so you’re able to list them without an internet connection.

3. Moodboard and Preparation

We have plenty of sites for inspiration — Dribbble, Behance, Pttrns, Pinterest etc. and it’s really easy to find similar projects like the one you have. Additionally, it could be a solution for a problem that you’re experiencing and you’re trying to solve.

So when I begin working on a new project, I always prepare a folder with — PSD, Screens, Inspiration and Resources folders. I’m saving everything to the Inspiration folder that I find on the internet and is related to this project.

It should be everything from swatches to full case studies from Behance. Yet it also could be pictures of attractive people if the app has users’ profiles. It sometimes happens that I don’t even use that folder but that’s different story!

Work Process

4. I don’t care about wireframes quality.

I’m not a big fan of spending half a year on wireframes. I also prefer it if a client has prepared wireframes.

A good client is one who has prepared his ideas on paper.

I’m taking wireframes as just more about understanding the purpose and not the actual final result. The final result matters about you and your UI / UX skills and ideas which you want to present. Wireframes can help with the imagination of how many screens you’ll need and what’s the client’s idea.

On another page of the wireframes is a nightmare for the designer in which someone wants just the replication of prepared wireframes and to use the right details from the wireframes. That’s monkey’s job not the designer’s. In this case, every designer would just quickly finish that job and run away from the project like Usian Bolt.

5. PSD — Big Canvas (back to the Illustrator)

When I started 7 months ago at Badoo, I saw how my colleague works (Hi Sasha!), I thought that he didn’t understand how Photoshop works. However, now I’m trying to get into this technique, and in fact this style make sense to me. It’s good to use this style when you’re working on something really big, for example, a web application or a rich dashboard.

Basically, I work with a big canvas for example 8000*5000 pixels. Furthermore, my work isn’t more than just creating one big UI kit. The work is much faster because you see every element together and I can easily see what’s happening in every state. Additionally, it is much quicker to make a screenshot for developers with a small flow or just one states for one thing.

6. All screens in one PSD

In another case, which is not that revolutionary or different. If I’m working on a mobile app I’m working in different extremes. That means — All screens are in one PSD.

In folder 14 is another 12 designs of graphs

I know in this case it will be better to use Sketch, which could be really helpful with work. But I prefer one instead of 40 because it’s hugely quicker, I can easily pick one element from a different screen and copy that to another folder/screen. So that means if I change the background or a few icons on the top bar, I don’t need to change hundreds of other PSD’s.

7. Folders and Etiquette

I’m a tidy person in every respect — I have one icon on my desktop, folders per clients, per projects. Every folder is structured in the same way as I mentioned before. The same as in PSD. Every of my PSD’s is nicely structured in every folder. I use the rule that if you have more than 8 layers in folder then you should create a new folder. I think about my PSD’s like I’m preparing them for someone else. I’m not a big fan of naming layers because you can easily go through my folders.

But lately I’ve started working with @LukášKus and he always complains that he doesn’t have these folders in AE. Therefore, a particular situation always matters.

If you would like to know anything else about PSD Etiquette you can look at this — http://photoshopetiquette.com/

8. Communication with friends

A network of people who can provide you with relevant feedback is something critical for me. I can easily do mini user testings and listen to what people think about these specific problems This usually opens the doors to other solutions and other points of view for these problems. I do these calls/tests as much as I can in every state of my project or screen. Moreover, it doesn’t matter who you are testing. It could be anyone, I prefer to combine two segments — people from the community, the UX designers and normal regular users. This is because you’re usually working on project for regular users not for designers and UX principals.

9. Diagram

After my client or I prepare wireframes, I prefer to take them and merge them in one PSD. Then I try to think about interactions, what happens when I click here or there. Usually, we find a lot of missing screens and additional errors which clients or I don’t realise, when I was thinking about just one particular screen when I was preparing wireframes. For me, it’s this pre-prototype phase which I don’t consider a double job. It’s actually also a visual overview of all the screens and the elements. When I’m working on 15+ screens project it’s hard to keep the same visual style across the whole app and I can easily break the guidelines.

3 different types of lines — first a normal line with the number of next screen. Second in app screen. Third — an external app or linkHow it looks with contentComplete overview

About style — I use the same style similar to a lot of designers, however instead of spending a lot of time with creating these lines across whole canvas, I use circles with the numbers of the next screen. It’s a little bit like gamebooks which I was reading back in the days, but it’s a better solution than creating of printed circuit boards. You can see more states on the picture.

I add a link for the Diagram PSD for a better understanding these diagrams(The iPhone render is done by GraphicBurger)

Post Process — Guidelines

And we are finally close to end of the process, the last part is the creation of the guidelines and the final check for visual consistency. It turns out for me like such an important part of the process for small and also for big projects. Usually, when I work on a big project I want to change something in this part of process and I’m never a 100% sure that I’ve changed every of these properties. I use these for myself and also for developers to be sure that they won’t use 50 shades of grey or 14 different sizes of fonts.

10. Colour Specs

The specification of colours is one of the first thing which I try to keep in mind. It’s really nice in these flat design age to keep as few colours as possible for the buttons and for text. It’s nice to prepare this in your PSD like a painter’s palette or like swatches in Photoshop, which is basically the same.

11. Typo Specification

One other thing which can remind you of the logo specification is the guide for text sizes and the weight of fonts across the application. Again, it’s good for developers, but also for your overview.

12. UI Kits

The UI kit is a really important thing if we are talking about consistency across company apps and websites. It’s also important when you’re working in team of designers or you have more front-end developers who work on that project. I can use a UI kit in way that I’m always taking these elements from UI Kits. Also the developers can easily see how this button will look on hover and they don’t need to ask about everything.

Note: I’ve realised that in big companies, it is a big problem that nobody has heard about these things and teams basically re-create these same CSS lines again and again. Then you realised that you have 3 different interpretations of one button in 3 different applications. So you can’t forget about consistency.

Productivity

13. Todo

My key aspect of tidiness is working with todo lists. It doesn’t matter what type of app or paper you use. I prefer Things by Cultured Code and sometimes piece of the paper. That feeling of completing lists is always great. I was possessed with accepting every project which ends up in my email inbox, but now I’ve realised that it is much too comfortable to focus on 1-2 projects and 100% focus just on these 2 projects and then go to another one instead of fighting with 5 different ones.

“If you chase two rabbits, you will not catch either one.” — Russian Proverb

14. Goals

It’s really nice to know what you want to achieve, but also don’t be too bound to them. I make goals for 14 days (like a sprint) and quarterly goals. Also, I try to set these goals in way that I can achieve some new experiences (for example: make my first animation in After Effects) and also keep working on current things (finish 2 Behance case studies).

And what else?

I don’t use a mouse, just a tablet, I don’t have Tools panel I have learned all keyboard shortcuts. For streaming Photoshop to iPhone I use Skala Preview and I want to learn After Effects and Sketch. For prototyping, I use InVision App for web projects and the newly MarvelApp for iOS designs. It’s quicker for me to work with a pen instead of dragging and swiping on the iPhone screen. I sometimes still work with PopApp for some early prototypes, when I have time on the Tube for clicking and dragging on Screen.

The last few words

It’s really hard to say that I will always complete and follow the exact process for each project, because I sometimes skip some steps or I start in Photoshop if I see that the design in my mind and I have an exact idea about that.

In companies where I have worked, I’m still not experiencing real feedback, user testing and these things where designers can profit and take and experience them for thinking about new projects or updates for the current one. Especially User Testings, these change the thinking about all the things and show us that regular users usually work in completely different ways than we expect.

The End

I’d be happy to hear about your work processes, which steps you usually take in your personal projects or your thoughts about additional steps in my process.

Source

Two Keys to Building a Great Product

image

In the product group at HubSpot there are two guiding principles to building amazing products, they come from David Cancel and he’s 100% right in my experience:

  1. Be customer-driven
  2. Show meaningful progress

Each of these means different things at different stages in the product lifecycle, but they are strong guiding principles from early stage research through MVP to mature product.

Here’s a starting point to think about how to lean into each of these principles, and a view of how that changes as a product comes to market and matures.

Pre-prototype
  1. Customer-driven: Narrow your focus to your target go-to-market end user. Find where they spend their time, where their pain is. Watch them in their natural environment. 
  2. Meaningful progress: Consider doing a minimum of X interviews, and/or defining the output as being the top Y painpoints to start addressing.
MVP
  1. Customer-driven: Be insanely impatient to get an early working product in front of one user. That’s the hardest part, getting one person to the point where they would pay, or be seriously disappointed if you took the product away from them. super hard stage, from zero to one user. Then move from one user to ten, another extremely hard stage. Put your cell phone in the product, follow up with people as they use the product, and watch every motion they take using it. Start doing user testing as well.
  2. Meaningful progress: Live and die by activated user count. From zero to one, and from one to ten. 
Growth phase
  1. Customer-driven: The product team should directly support their customers. When applicable work with sales to understand how to iterate on *validated* learnings - not “all i need to close every deal is XYZ” requests but actual records of painpoints, blockers, competitive landscape, potential for product differentiation, shortcomings against existing solutions, etc. It helps here to have consultative sales folks who don’t do “feature dumps” but rather do a great, scalable job of customer pain discovery. If product/dev can overhear these conversations some magic can happen :)
  2. Meaningful progress: Measure, chart and distribute to the team: active users, activation rate, recurring revenue, net churn, referral loop, tickets/customer (whatever makes the most sense as a yardstick for product/market fit). Company demo (monthly) of new features LIVE for real customers, not mockups or qa.
Mature product
  1. Customer-driven: Record and distribute top support inquiry drivers, measure decrease in these drivers month over month. Heavy use of user testing to optimize the core flows and usage patterns in the product.
  2. Meaningful progress: Measure, chart and distribute to the company: tickets/customer, call drivers (and delta month-over-month), uptime/availability, performance/speed. Continue company demos, include performance improvements in addition to features.

Hope someone out there finds this useful, it’s been a breakthrough for me and my colleagues to embrace these principles and to dive deeper and deeper on both.

Nostalgia: A Product Designer’s Secret Weapon

Remember pogs?

Remember Tubthumping?

Remember Nickelodeon GUTS?

Now pause…

How do you feel right now? Did reading those words stimulate any emotional reaction? Did it bring back memories? Excite you? Make you smile?

Nostalgia is powerful. Simply mentioning the names of childhood toys, old TV shows, classic video games, and other pastime activities often instigate an emotional response, reminiscence. But why? Why is nostalgia so compelling and how can product creators use this to build more engaging products?

The Influence of Nostalgia

The term nostalgia was coined by 17th century physician, Johannes Hofer, based off the Greek words nostos (return) and algos (pain). He prescribed nostalgia as a mental illness, attributing it to Swiss soldiers’ symptoms of anxiety, homesickness, insomnia, and anorexia. Hofer believed“continuous vibration of animal spirits through those fibers of the middle brain in which impressed traces of ideas of the Fatherland still cling,” was the cause of these ailments.

Since then, we’ve acquired a better understanding of nostalgia, now defined in the Oxford Dictionary as “a sentimental longing or wistful affection for the past, typically for a period or place with happy personal associations.” Nostalgia generally instills positive emotions of happiness, social connectedness, confidence, and optimism of the future. When feeling down, people seek nostalgia to raise their spirits. Dr. Clay Routledge, a Professor of Psychology at North Dakota State University, posits that “nostalgia increases positive mood, perceptions of meaning, and a sense of connectedness to others. Thus, people may naturally turn to nostalgia if positive mood is threatened, a sense of meaning in life is undermined, or feelings of social connectedness are compromised.”

Negative emotions are powerful triggers, influencing our behavior. Feelings of loneliness, boredom, or insignificance prompt people to browse their Facebook feed, search for a match on OkCupid, or send a photo to a friend on Snapchat. People turn to these services, often subconsciously, to improve their mood. In one study Dr. Routledgeexamined the effects of music-induced nostalgia, playing popular songs and providing lyrics to participants. Those exposed to the music were more likely to report that they felt “loved” and that “life is worth living” than a control group.

Routledge further explains, “[Nostalgia] is a psychological resource that people employ to counter negative emotions and feelings of vulnerability. Nostalgia allows people to use experiences from the past to help cope with challenges in the present.” Smart product designers and marketers recognize the influence of nostalgia, integrating it into apps and services we use every day. Here are a few products that use nostalgia to spark engagement and build compelling experiences.

Timehop

Nostalgia is a core component of Timehop’s design. Each day the service revives past status updates and photos shared exactly one or more years ago. Instantly, memories resurface as these shared moments encourage people reminisce with friends and family.

The other day Timehop resurfaced this photo:

This was from an incredibly fun 80’s KOFY TV Dance Party, two years ago. Instantly, I shared this with my friends to reminisce.

Heyday

Heyday uses a similar approach, reminding users of the past. But it adds another dimension: location. Last month when I visited my hometown, I received a delightful push notification from Heyday, prompting me to “Look back at your photos shared in Eugene, OR.”

Using the location data stored within the photo, Heyday generates a historical map of one’s travels to surface delightful, contextual memories from the thousands of pictures stored on my iPhone.

Facebook Year in Review

Facebook amused the world toward the end of 2012 with a special year in review, surfacing the 20 most popular posts in one’s timeline. People enjoyed the digital scrapbook, reviewing and sharing memories of the past year. Facebook repeated the successful campaign again at the end of 2013.

Visit your 2013 year in review and observe your emotions and behaviors. Does it make you smile? Are you compelled to comment on these memories? This nostalgic look-back also helps communicate the value of Facebook as a destination to store and relive memories the following year.

Mindie

As Dr. Routledge’s research shows, music has remarkable nostalgia-inducing powers. Mindie, a mobile app to watch and create 7-second music videos, leverages this potent power to quickly deliver an aha! moment, hooking users on day one. Browse the feed of user-created videos to listen to the classics or create your own, selecting your favorite song from yesteryear, surfacing memories and nostalgia.

Polar

Polar, a mobile app of visual polls, covers a wide range of topics from current day politics to modern memes. But many of its most engaging polls, as found in its feed of top submissions, are based on old pop culture references and childhood activities like:

Boya

Boya, a new product from the folks at Monkey Inferno, thrives off of nostalgia. After registering any account, users are prompted to describe themselves, entering things they’ve done.

These shared experiences ignite conversation as community members ask users about their experiences, further digging into the archives of the brain.

Foursquare Timemachine

In the summer of 2013, Foursquare Timemachine, hit the internet, igniting a wave of attention in the press and social media.

People loved the data-rich, interactive map of their check-in history. My memories moving from Portland to San Francisco was most notable for me, marking a new chapter in my life. Others reminisced of past vacations as the map traveled across the world.

Glimpse

Glimpse, a dating app that uses Instagram photos to express oneself, creatively uses nostalgia in its on-boarding process. When first signing up, it prompts users to login with Instagram and select nine photos to express one’s personality.

Browsing years of beautiful photos from the past is delightful and although it’s not core to the product, the experience is fun and engages users when they’re most susceptible to churn, before they’ve recognized the value of the app.


Be it a one-time marketing tactic like Foursquare’s Time Machine or core part of the product design like Timehop, nostalgia is a powerful tool to re-engage users and create compelling experiences. Consider how you can use nostalgia to:

  • Promote your product and provide interesting content people want to share
  • Deliver an aha! moment on day one, encouraging users to return
  • Build sustainable value and delightful experiences by making people feel good

To learn more about product design and influencing user behavior, check out Hooked: How to Build Habit-Forming Products and subscribe to receive the first chapter for free.

This essay was originally published on Pando.

Source

Stationery required to design software

My software design training (as much as it could be called that) was in a mixture of strategic design thinking and graphic/communication design. 

I ended up designing software by a mixture of choice and accident. After a foray into management consulting with a design twinge at Engine, I’ve ended up spending the last seven years involved in different kinds of software design companies at EMC Consulting, Sidekick Studios, and now Makeshift.

Along the way I’ve been lucky enough to work with some amazing software engineers, and very talented interface designers who’ve introduced me to many useful digital tools to help me design better software includingcode management services,  product management appswireframing softwareand interface design things

The non-digital toolkit

But, as my digital toolset has evolved and grown, one part of my design toolkit has remained pretty static and actually become more refined - the stationery I use.

Now physical bits of stationery are not the first thing that come to mind when you think about designing software, but in my experience printing stuff out, drawing and talking as a group around a design are essential to collaboration and new ideas. And if you are going to physicalise your digital designs, you should use the right tools.

“Physical bits of stationery are not the first thing that come to mind when you think about designing software”

So, here’s my list of stuff that I use, and some notes on what I use it for. Below I’ve taken a picture of my full toolset, and I’ll go through each one in turn. I’d love to get your feedback on these choices and what you use.

image

Pens.

There are only two pens I need. PaperMate Flair in black and red, and standard Sharpie in black. I use pens for writing, of course, and for drawing simple wireframe interfaces - the PaperMate Flair is best for this, and the sharpie is best for writing on Post-its. The sharpie is also great for highlighting bits of interfaces. 

I find these two pens give me the full range of line quality I need. I can go to a pretty high resolution, but also keep things open and indeterminate in order to invite feedback. A note on pens not to use: Biros - no. Not clear enough. Other colours - no. Unnecessary distraction and they don’t show up on coloured Post-its.

Paper.

A3 and A4 + cheap sketch books. That is all the paper you need. I like to take a big stack of new paper when I sit down to do interface sketching, as it makes it feel like there’s lots of potential. 

image

A3 is best as you can draw a reasonably ‘screen sized’ box, but still have space for annotations or a smaller mobile view concept. I’ve finally settled on the 99p sketch books (ruled, squared or plain I don’t mind) as I draw so many big pointless doodles that Moleskines felt totally over specified.

“Sketching interfaces on paper is an essential part of software design”

I think that sketching interfaces on paper is an essential part of software design - its often where you come up with really new ideas, and its also the only place you can really conceptualise an entire app in one go (this normally requires sticking stuff on the wall).

Record cards.

These are essential to designing software. I use the 6” x 4” and 3” x 5” record cards for all sorts of things, but mainly for writing tasks / to do items for sprints (we then pin them on to large foam boards). They are also really useful for drawing tiny low resolution screens to illustrate key information required during stages of a user journey.

Post-its.

Only use Post-it branded Post-its. Cheaper Post-its are a false economy - they fall off the wall, and the colours are annoying. I prefer the warm neon and cool neon sets (I’d pick warm over cool generally) as this gives you a good range of colours to play with. I generally like to have all four main sizes available - tiny, square, letterbox and the ‘super sticky’ large size ones.

Cutting and sticking.

Once you’ve drawn your wireframes, printed off your graphics ideas you have to stick it all on the wall. 

image

Sticking things on the wall is a very important part of the design process - it gives you a huge canvas to visualise large flows through an app, lets you identify visual design inconsistencies and provides a way to get a group of people to feedback on an idea via notes, post-its and so forth. 

I like to use scotch / magic tape for connecting together pieces of paper, and then use coloured artist tape to highlight things or draw large grids on the wall an so on. Its also helpful to have a cutting mat, and a scalpel to hand.

“Sticking things on the wall is a very  important part of the design process”

Making it real helps make it better

In addition, sticking stuff up is just a great way of ‘socialising’ ideas around a company - the value of having something that people can see is huge, as it gives them something to ask you about. 

It’s often the ‘what are you working on’ unexpected conversations that lead to the big ideas, and having stuff up in and around your team’s space is a big catalyst for these moments.

So, that’s my stationery stack. What’s yours? Let me know on Twitter, and if you liked this post sign up for our newsletter below to get more of the same in your inbox once a week.

Source

Why you should move that button 3px to the left

When a product is close to launch, I become a perfectionist. Each misaligned element or awkward interaction is like a thorn in my side. There’ll be a dozen tiny implementation mistakes that taunt me each time I run into them. Everything seems so broken.

But to everyone else on the team, the product seems fine! It’s functional. They ask, “Will moving that button by 3 pixels really improve our product?” They argue, “The last time we fixed a small design bug, the product didn’t feel any different.” And so the team moves onto the next big idea and the next set of features.

If you’re anything like me, this situation can be incredibly frustrating. As designers, we are held responsible for the overall quality of the experience. Yet we’re at the mercy of our teams. We can design beautiful, intricate, delightful details — but we can’t build, test, and deploy them all.

How do we convince our engineering and product counterparts to care about design fit and finish? I’ve struggled with this issue many times. Here’s what I’ve learned.

It’s not design for design’s sake

Designers notice the gap between functional and delightful, and that’s why we obsess over the little details. (littlebigdetails.com) But there’s a very real tradeoff between perfecting the design details and building more functionality: getting the details right often means moving slower.

So it’s not enough to say “it looks better this way”. Designers need to make a case for why the team should spend time on fit and finish.

Trust increases when we get the details right

Customers judge online credibility by evaluating visual design, copywriting, and interactions. If trust matters to your business, then design details should matter too. Check out the academic literature on the topic of interface design and trust, or look into Stanford’s Web Crediblity Project.

MintSquare, and Simple have all done a fantastic job of getting design details right, and earning customer trust. They all began as unproven products, yet customers trusted them to store financial details, process payments, and safeguard accounts.

Usability improves when we get the details right

The MailChimp logo makes me smile every time! The lack of clutter on the Google homepage is so peaceful. The glossy pixel-perfection of Apple interfaces is delightful. They got the design details right, and it’s creating a positive emotional state, but why does that matter?

There’s a curious brain hack at work here. Our minds are deeply tied to emotional states. Being frustrated or happy changes the way we approach problems. I have certainly been in a bad mood, gotten confused by a product, and found myself repeatedly smashing a button to no effect. In my frustration, I try the same thing, justharder. But it doesn’t help me accomplish my goal.

When we’re happy, using an interface feels like play. The world looks like a puzzle, not a battle. So when we get confused, we’re more likely to explore and find other paths to success. There’s a whole book on this topic: Emotional Design by Don Norman. But here’s the important bit: Getting design details right can create positive emotional states that actually make products easier to use.

Batch up the work

If your product needs a massive helping of fit and finish, fixing one issue won’t do much to delight you or your users. Filling one pothole won’t turn a bumpy street into a smooth one — you’ll barely notice the change!

So here’s the trick: Batch up UI bugs into one sprint. If your team regularly holds a fix-it day to squash bugs, then piggyback on that habit and hold a design fix-it day. As a designer, you can do advance work like putting all the changes into a spreadsheet or bug tracker and prioritizing issues.

On the day of the sprint, everyone can just focus and crank through the list. Maybe you don’t fix everything — that’s OK. The small changes you do make will add up, and by the end of the day your product will be noticeably better. That makes everyone feel great and it’ll be easier to get people focused on fit and finish issues in the future.

Polish as you go

I really screwed up the first time I tried to keep quality high as we were building features. It always started fine: an engineer and I would agree to a design, I’d send him a few mockups, and the next day he’d show me the progress. What I saw: a sloppy version of my design. Ugh.

I’d moan and complain and point out all the mistakes, which wasn’t any fun. So the next time he was less likely to ask for my feedback, quality slipped further, and I became more upset. Classic death spiral.

I came to realize that when a feature is 90% done from an engineering perspective, it can still feel about 10% done to a designer. Now I get excited about the functionality and celebrate that there’s only a bit of surface details to finish before the feature is perfect.

I also try to build in triggers for feedback sessions while engineers are in context. I’ll say, “Grab me right before you check this in.” That way we can go over any small changes while all the files are open and checked out.

Avoid customization icebergs

Designing a custom button in Photoshop is easy — that’s the part of the iceberg we can all see. Below the surface it takes a lot of effort to get the details right: building pressed and inactive states, preventing text highlighting on double-click, adding right-to-left support, testing accessibility, and so on.

I often hit this iceberg when I stray from native controls. For example, Ajax interactions require more polish than basic web pages. Custom mobile menus require more polish than the built-in version. If the team doesn’t have the time to polish custom UI, it’s often better to stick to the boring native controls that work.


Those are some of the techniques that I’ve learned over the years to get design details built. And I’ve noticed along the way that teams vary widely in their culture around quality. Some teams obsess over the details and take their time. Other teams tend to launch sloppy products fast.

I’m interested in how teams create norms for quality. How do you create a culture where a team can quickly come to agreement about whether to spend more time on design details? What has worked for you? What hasn’t? Let’s discuss in the comments below.

Source

The Iceberg of Jobs-to-be-Done

When you’re starting to design a new product, or redesigning an existing one, the most important thing you can do is validate that the problem you are trying to solve is meaningful, important, and shared by a large enough group of people that a solution is likely to succeed in the market.

However, there are two significant challenges to overcome. First, it is difficult to find the right tools to truly understand these complex problems. Second, we have a strong human desire to conceive a highly-rationalized approach to deal with our insecurity in the face of many unknowns and perceived risks – especially when the stakes are high. These two forces often work against each other and lead to bad solutions that don’t solve real problems.

So where can we look for insights to guide us? It’s tempting to look at consumer market research segmented by demographics, psychographics, or technographics for data points that confirm or refute our hunches. There’s plenty of this out there, and it has been gathered and analyzed by smart people working at reputable companies.

It’s also tempting to look at competitors in a market and try to reverse-engineer their success, or classify them on some spectrum of qualities that help us identify arbitrary attributes that could differentiate us (“We’re like the Tumblr for the knitting community!”).

In the case of an existing product, you could also look at your analytics and hope the data will point you in the direction of the next big thing you should do. Finally, it’s easy to come up with a list of ideas, features, and requests from existing or prospective customers (see: The Homer) that seem worthy of building.

This type of data can make us feel more confident about our decisions and steer us down a path toward building a solution that is clearer in our minds. But how do you make sense of it all and ensure you’re laser-focused on solving the underlying problems people have in their lives instead of just the thing that came to mind today? And how might we identify unmet needs (non-consumption or hacks) from this data? We can’t.

The problem is that this data is almost always a lagging indicator of behaviour. Even when we aggregate it all together and look for trends, we are reporting something that has already happened, but that doesn’t mean we understand why it happened. Yet the why is the single most important thing to identify in product design. “Why does this exist?” “Why might someone actually change their behaviour and use this?”

The Iceberg

It is said that 90% of an iceberg is underwater. I believe the same analogy applies to the insights we use to focus our creative energy when designing a product. It’s easy to find the lagging indicators – the 10% that is above water – but much harder to find the leading indicators of potential customer behaviour. And focusing only on lagging indicators is a dangerous blindness to have when you’re trying to find product-market fit and persuade people to switch to your product.

At Teehan+Lax, we believe that single most important thing you can identify when creating a product is the jobs-to-be-done that your existing or potential customers have in their lives. Jobs-to-be-done are what cause a customer to hire or fire a product. Finding a poorly-served job that many people critically share is the most important factor in identifying new opportunities and building disruptive solutions. These are the leading indicators of customer behaviour that help you stay focused on building the things that matter and ignoring the things that don’t.

This would suggest that most successful products are created by one of four types of people:

  1. Geniuses who have a strong internalized sense of important jobs-to-be-done. These people are few-and-far between. They are the Steve Jobs of the world. Through an incredibly prescient vision, drive, and experience, these individuals are wired to identify and build things that solve important jobs-to-be-done.
  2. People who have identified a problem they have, and decide to create a better solution first-and-foremost for themselves. By focusing on their own problems, they remain focused on what matters and have an easier time identifying other people who might share this problem and hire their solution.
  3. People who create a product and, somewhat by chance, stumble upon a compelling job-to-be-done that propels them to success. This is dangerous – especially with complex digital products. It becomes easy to misunderstand the reasons people have hired you and to blindly push your product in a direction that actually moves away from solving the most important jobs-to-be-done. Over time, these products can begin to poorly serve the market, leaving the door open to competitive threats.
  4. People who understand the importance of creating products that solve real customer problems, and have a set of tools and frameworks like jobs-to-be-done that they use to identify and validate the real human problems they’re trying to solve in the market.

At Teehan+Lax, we push ourselves and our clients to be in the fourth category. The third category is too hit-and-miss (although you can get there more reliably by building stuff quickly and validating in market), and the first and second categories are too rare.

How We Do This

The idea behind jobs-to-be-done is relatively straightforward. We’re all trying to make some kind of progress in our lives with regards to problems or jobs that we have, and we hire various solutions to solve them for us. We continue to use a solution so long as it continues to adequately address the jobs we have (whether we’re conscious of it or not).

But identifying these jobs is the tricky part. Here’s a simplified form of the methodology we use:

  1. Find people who have recently hired or fired a relevant product.
  2. Interview them to investigate what forces and factors have led to this event. Don’t spend any time talking about what they like or didn’t like about the product, what features they want to see in the future, etc. These are traps.
  3. Analyze these forces and factors to pull out and prioritize the jobs-to-be-done.

This process looks more like detective work than conventional marketing research — in large part because most of us have low self-awareness of why we ‘hire’ things. We have found it greatly outperformsconventional research approaches because it avoids the trap of looking for esoteric or abstract ‘insights,’ and instead focuses relentlessly on answering very plain questions that get to the crux of why we do what we do.

At this point, you should have a set of jobs-to-be-done that, if employed correctly, will serve as a lens through which most product decision-making can exist. If an idea or feature doesn’t clearly resolve the job in some way, it doesn’t deserve to exist or should be de-prioritized.

We believe these are the most important leading indicators, because the day you stop adequately serving these jobs, or a competitor serves them better, is the day you start losing customers.

HTML5 Mythbusting

Article: Source

The ongoing discussion about the “readiness” of HTML5 is based on a lot of false assumptions. These lead to myths about HTML5 that get uttered once and then continuously repeated – a lot of times without checking their validity at all.

HTML5 doesn’t perform?

The big thing everybody who wants to talk about the problems with HTML5 is performance. The main problem here is that almost every single comparison misses the fact that you are comparing apples and pears (no pun intended).

Comparing an HTML5 application’s performance with a native App is comparing a tailored suit with one bought in a shop. Of course the tailored suit will fit you like a glove and looks amazing but if you ever want to sell it or hand it over to someone else you are out of luck. It will not be the same for the next person.

IMG_4197.jpg

That is what native Apps are – they are built and optimized for one single environment and purpose and are fixed in their state – more on that later.

HTML5, on the other hand by its very definition is a web technology that should run independent of environment, display or technology. It has to be as flexible as possible in order to be a success on the web. In its very definition the web is for everybody, not just for a small group of lucky people who can afford a very expensive piece of hardware and are happy to get locked into a fixed environment governed by a single company.

Native applications need to be written for every single device and every new platform from scratch whereas an HTML5 App allows you to support mobiles, tablets and desktops with the same product. Instead of having fixed dimensions and functionality an HTML5 App can test what is supported and improve the experience for people on faster and newer devices whilst not locking out others that can not buy yet another phone.

Native Apps on the other hand do in a lot of cases need an upgrade and force the end user to buy new hardware or they’ll not get the product at all. From a flexibility point of view, HTML5 Apps perform admirably whilst native applications make you dependent on your hardware and leave you stranded when there is an upgrade you can’t afford or don’t want to make. A great example of this is the current switch from Apple to their own maps on iOS. Many end users are unhappy and would prefer to keep using Google Maps but can not.


HexGL – a WebGL powered racing game

Seeing that HTML5 is perfectly capable on Desktop to exceed in performance, from scrolling performance to analyzing and changing video on the fly up torunning full 3D games at a very high frame rate and have high speed racing games we have to ask ourselves where the problem with its performance lies.

The answer is hardware access. HTML5 applications are treated by mobile hardware developed for iOS and Android as second class citizens and don’t get access to the parts that allow for peak performance. A web view in iOS is hindered by the operating system to perform as fast as a native App although it uses the same principles. On Android both Chrome and Firefox show how fast browsers can perform whereas the stock browser crawls along in comparison.

The stock browser on Android reminds us of the Internet Explorer of the 90s which threatened to be set in stone for a long time and hinder the world wide web from evolving – the very reason Mozilla and Firefox came into existence.

In essence HTML5 is a Formula 1 car that has to drive on a dirt road whilst dragging a lot of extra payload given to it by the operating system without a chance to work around that – for now.

HTML5 can not be monetized?

HTML5 is a technology stack based on open web technologies. Saying that HTML5 has no monetization model is like saying the web can not be monetized (which is especially ironic when this is written on news sites that show ads).

Whilst on the first glance a closed App-market is a simple way to sell your products there is a lot of hype about their success and in reality not many developers manage to make a living with a single app on closed App markets. As discovery and find-ability is getting increasingly harder in App markets a lot of developers don’t build one App but hundreds of the same App (talking dog, talking cat, talking donkey…) as it is all about being found quickly and being on the first page of search results in the market.

This is where closed App markets with native Apps are a real disadvantage for developers: Apps don’t have an address on the web (URL) and can not be found outside the market. You need to manually submit each of the Apps in each of the markets, abide to their review and submission process and can not update your App easily without suffering outages in your offering.

An HTML5 App is on the web and has a URL, it can also get packaged up with products like Adobe PhoneGap to become a native application for iOS or Android. The other way around is not possible.

In the long term that begs the question what is the better strategy for developers: betting on one closed environment that can pull your product any time it wants or distributing over a world-wide, open distribution network and cover the closed shops as well?

Many apps in the Android and iOS store are actually HTML5 and got converted using PhoneGap. The biggest story about this was the Financial Times releasing their app as HTML5 and making a better profit than with the native one. And more recently the New York Times announced it was following suit with its Web app.

HTML5 can not be offline?

As HTML5 is a web technology stack the knee-jerk reaction is thinking that you would have to be online all the time to use them. This is plain wrong. There are many ways to store content offline in a HTML5 application. The simplest way is the Web Storage API which is supported across all modern browsers(excluding Opera mini which is a special case as it sends content via a cloud service and has its own storage tools). You can also store the application itself offline using AppCache which is supported by all but Internet Explorer. If you have more complex data to store than Web Storage provides you can use either IndexedDB (for Chrome and Firefox) or WebSQL (for iOS and Safari). To work around the issues there are libraries like Lawnchair available to make it easy for developers to use.

HTML5 has no development environment?

One concern often mentioned is that HTML5 lacks in tooling for developers. Strangely enough you never hear that argument from developers but from people who want to buy software to make their developers more effective instead of letting them decide what makes them effective.

HTML5 development at its core is web development and there is a quite amazingly practical development environment for that available. Again, the main issue is a misunderstanding of the web. You do not build a product that looks and performs the same everywhere – this would rob the web of its core strengths. You build a product that works for everybody and excels on a target platform. Therefore your development environment is a set of tools, not a single one doing everything for you. Depending on what you build you choose to use many of them or just one.

The very success of the web as a media is based on the fact that you do not need to be a developer to put content out – you can use a blogging platform, a CMS or even a simple text editor that comes with your operating system to start your first HTML page. As you progress in your career as a developer you find more and more tools you like and get comfortable and effective with but there is no one tool to rule them all. Some developers prefer IDEs like Visual Studio, or Eclipse. Others want a WYSIWYG style editor like Dreamweaver but the largest part of web developers will have a text editor or other of some sorts. From Sublime Text, Notepad++ up to VIM or emacs on a Linux computer, all of these are tools that can be used and are used by millions of developers daily to build web content.

When it comes to debugging and testing web developers are lucky these days as the piece of software our end users have to see what we build – the browser – is also the debugging and testing environment. Starting with Firefox having Firebug as an add-on to see changes live and change things on the fly, followed by Opera’s Dragonfly and Safari and Chrome’s Devtools, all browsers now also have a lot of functionality that is there especially for developers.Firefox’s new developer tools go even further and instead of simply being a debugging environment are a set of tools in themselves that developers can extend to their needs.

Remote debugging is another option we have now. This means we can as developers change applications running on a phone on our development computers instead of having to write them, send them to the phone, install them, test them, find a mistake and repeat. This speeds up development time significantly.


Remote debugging in Firefox

For the more visual developers Adobe lately released their Edge suite which brings WYSIWYG style development to HTML5, including drag and drop from Photoshop. Adobe’s Edge Inspect and PhoneGap makes it easy to test on several devices at once and send HTML5 Apps as packaged native Apps to iOS and Android.

In terms of deployment and packaging Google just released their Yeomanproject which makes it dead easy for web developers to package and deploy their web products as applications with all the necessary steps to make them perform well.

All in all there is no fixed development environment for HTML5 as that would neuter the platform – this is the web, you can pick and choose what suits you most.

Things HTML5 can do that native Apps can not

In essence a lot of the myths of HTML5 are based on the fact that the comparison was between something explicitly built for the platform it was tested on versus something that is also supported on it. Like comparing the performance of speedboat and a hovercraft would result in the same predictable outcome. The more interesting question is what makes HTML5 great for developers and end users, that native applications can or do not do:

  • Write once, deploy anywhere – HTML5 can run in browsers, on tablets and desktops and you can convert it to native code to support iOS and Android. This is not possible the other way around.
  • Share over the web – as HTML5 apps have a URL they can be shared over the web and found when you search the web. You don’t need to go to a market place and find it amongst the crowded, limited space but the same tricks how to promote other web content apply. The more people like and link to your app, the easier it will be found.
  • Built on agreed, multi-vendor standards – HTML5 is a group effort of the companies that make the web what it is now, not a single vendor that can go into a direction you are not happy with
  • Millions of developers – everybody who built something for the web in the last years is ready to write apps. It is not a small, specialized community any longer
  • Consumption and development tool are the same thing – all you need to get started is a text editor and a browser
  • Small, atomic updates – if a native app needs an upgrade, the whole App needs to get downloaded again (new level of Angry Birds? Here are 23MB over your 3G connection). HTML5 apps can download data as needed and store it offline, thus making updates much less painful.
  • Simple functionality upgrade – native apps need to ask you for access to hardware when you install them and can not change later on which is why every app asks for access to everything upfront (which of course is a privacy/security risk). An HTML5 app can ask for access to hardware and data on demand without needing an update or re-installation.
  • Adaptation to the environment – an HTML5 app can use responsive design to give the best experience for the environment without having to change the code. You can switch from Desktop to mobile to tablet seamlessly without having to install a different App on each.

Let’s see native Apps do that.

Breaking the hardware lockout and making monetization easier

The main reason why HTML5 is not the obvious choice for developers now is the above mentioned lockout when it comes to hardware. An iOS device does not allow different browser engines and does not allow HTML5 to access the camera, the address book, vibration, the phone or text messaging. In other words, everything that makes a mobile device interesting for developers and very necessary functionality for Apps.

To work around this issue, Mozilla and a few others have created a set of APIs to define access to these in a standardized way called Web APIs. This allows every browser out there to get access to the hardware in a secure way and breaks the lockout.

The first environment to implement these is the Firefox OS with devices being shipped next year. Using a Firefox OS phone you can build applications that have the same access to hardware native applications have. Developers have direct access to the hardware and thus can build much faster and – more importantly – much smaller Apps. For the end user the benefit is that the devices will be much cheaper and Firefox OS can run on very low specification hardware that can for example not be upgraded to the newest Android.

In terms of monetization Mozilla is working on their own marketplace for HTML5 Apps which will not only allow HTML5 Apps to be submitted but also to be discovered on the web with a simple search. To make it easier for end users to buy applications we partner with mobile providers to allow for billing to the mobile contract. This allows end users without a credit card to also buy Apps and join the mobile web revolution.

How far is HTML5?

All in all HTML5 is going leaps and bounds to be a very interesting and reliable platform for app developers. The main barriers we have to remove is the hardware access and with the WebAPI work and systems like PhoneGap to get us access these are much less of a stopper than we anticipated.

The benefits of HTML5 over native apps mentioned above should be reason enough for developers to get involved and start with HTML5 instead of spending their time building a different code base for each platform. If all you want to support is one special platform you don’t need to go that way, but then it is also pointless to blame HTML5 issues for your decision.

HTML5 development is independent of platform and browser. If you don’t embrace that idea you limit its potential. Historically closed platforms came and went and the web is still going strong and allows you to reach millions of users world-wide and allows you to start developing without asking anyone for permission or having to install a complex development environment. This was and is the main reason why people start working with the web. And nobody is locked out, so have a go.