We recently wrote about some of the changes we made to our support site in the last year. Following up on it, this post goes into depth about the details of our process for adding content to our support site.
As we are a software company, our process for adding documentation is not unlike our process for adding features and fixing bugs. Here's how we do it.
Recording a need
Documentation updates can be prompted by several actions. Here are the primary triggers:
- A customer contacts us (via phone, email or our forums) and mentions a typo or mistake in our documentation or has a problem that should be explained better on our support site
- We add or change something in our product and therefore need to update our documentation
- A support employee mentions that lots of people keep asking the same question and asks to create a dedicated FAQ or article about it
As much as possible we try to track things our customers want to know more about and things they're frustrated by. Our process hinges on frequent communication between our customer-facing staff and our documentation and product people. We also want to make it easy to then record those frustrations as tasks and assign them to the right people. I am responsible for our non-sales related documentation.
The three main tools we use in our documentation workflow are:
Desk - for email support and for managing our documentation knowledge base
- HipChat - for communication among the team, and
- Pivotal Tracker - for tracking issues and documentation requests.
If an issue related to documentation is raised in Desk (our direct customer support channel), it can be assigned to me. We also have a dedicated HipChat room called Docs, where we discuss ideas for new support articles and give feedback on existing ones.
Some conversation in our HipChat Docs room, including status updates from Pivotal
To stay in the loop I also monitor the Support HipChat room so I that can see what people are having trouble with.
Some conversation in our HipChat Support room
We use Pivotal Tracker for our product feature requests and bug fixes, so it made sense to use it to track documentation tasks as well. For a long time our documentation issues were filed in a general "Website" project, which was a catch-all for anything affecting our website (documentation, page redesigns, CSS alignment issues, etc.). But we recently created a separate project called "Docs" just for documentation and tutorials and moved our documentation stories into it.
We also made it easier to add issues to Pivotal by connecting Pivotal to HipChat via Zapier. Now, when a documentation story is created or updated in Pivotal, it is shown in HipChat (you can see this in the first HipChat screenshot above). Conversely, we can create Pivotal documentation issues directly from HipChat by typing: "Pivotal(issue name)". Employees can also create Pivotal stories directly in our Pivotal Docs project.
Once the documentation tasks are in Pivotal, I can organize them and begin work on them. Organization within Pivotal can be a bit of a challenge though, so I came up with a few additional processes for getting a handle on our documentation stories.
After we separated our documentation stories from our other website stories I quickly reviewed each of them. I started by labeling those I didn't understand as "to review." Those that appeared to be no longer relevant I labeled "to remove." The people who created those stories pitched in and added their comments or deleted them and we reduced the size of the backlog a bit.
Next, I tried to think about how to prioritize and group the remaining stories because I didn't have a good way to get a sense of urgency and difficulty. One of the first things I did (perhaps because diving right in was too intimidating) was develop a labeling system.
After some iteration, I came up with three categories of labels:
- The Action label group, describing what kind of task was needed
- "New" means this is a new article that should be created
- "Update" means that this is an existing article that needs updating (e.g., out-of-date screenshot, missing feature/function)
- "Clarify" means that something in this article is not clear and should be reworded or modified for clarity
- The Actor label group, describing the type of documentation affected
- "FAQ" is for any FAQ (product, licensing, installation)
- "Documentation" is for product user guides (anything in the Mockups for Desktop or myBalsamiq "Documentation" category or any of the plugin User or Admin guides)
- "Tutorial" is for tutorials
- The Category label group, describing the affected product or category within the Actor group (myB, Desktop, GDrive, Licensing, etc.) - this is optional
When adding the tags I try to place the tags in this order: "Action (Category) Actor" so that they make sense when written out. E.g., "New Installation FAQ", "Update myB Documentation", "Update Tutorial".
This has worked pretty well, as the labels seem to fit most requests and I'm able to add them easily when a new Pivotal issue is created. It also helps me tackle these issues in bulk more easily. So, for example, one month I made a point of addressing all "Update" stories in order to try to get our documentation up to date with the latest release (I didn't make it all the way through, but I made a big dent!).
A few stories in the Pivotal Docs project
To help with planning, I devised a system for estimating the work required for our documentation and tutorials stories. Here's the current version:
- 0 points - No change needed (e.g., duplicate or no longer applicable)
- 1 point - Typo or minor wording change
- 2 points - Updating or adding a screen shot, adding a new section to a document or a major re-write of one or more sections of a document
- 3 points - Creation of a new article or video
There is a big jump between 2 and 3 points (writing a long article or creating a video can take a couple of days), so it's not exactly a linear scale, but it's simple and clear enough to do be useful.
A new writing tool
One of the frustrating things for me when I started writing new documentation was just how long it took. For a simple document it often took a full day. One of the reasons is that our documentation is written in HTML (which is ok, although it adds some time) in a web-based tool (which makes iterations and drafts a bit challenging) and often requires screenshots (which can be a pain to create and upload).
What I really craved was one tool for everything, preferably that could work offline. After a lot of research, I settled on ScreenSteps Desktop, a tool for writing help guides that has built-in image capture. This was the killer feature for me. It can also automatically resize images to a set width to fit our web template. This saves me from having to edit them after I've captured them. And it outputs HTML with the ability to customize the output template with variables so that it generates the exact HTML that I needed to paste into Desk. My edits to the default template included removing the header and footer, mapping to the correct images directory, and adding specific CSS class names that we use on our site.
Our ScreenSteps HTML template, stripped down to meet our needs (click to see more of it)
I haven't used it for our main documentation yet, but it worked great for our "How-To" guides, which are heavy on images.
The process of publishing images also got easier when we moved to using GitHub to manage uploading our images, meaning that I could drag and drop them from my computer rather than using FTP.
A Style Guide for docs
Finally, we wrote a style guide for our documentation (although I haven't gone through the process of updating our old docs with it). It covers topics like rules for HTML and how text should be capitalized and formatted.
A work in progress...
One of the big things I was hired to do was improve our documentation and I'm pleased with the new content and processes we've added in the the last year. The process is a lot smoother than when I started and I'm hopeful that our content will take another big leap forward in 2014.
Still, I know that as a UX designer turned Doc writer I have a lot of room to grow, so I'm focusing on improving my abilities. Although I've been struck by the many similarities between UX design work and writing documentation. For instance, the process of creating something based on a specific need, giving an orderly structure to it and then refining and polishing it seems to activate the same neurons as designing a UI for me.
It also has many of the same challenges as my UX roles. Much like coming into a company as a new designer, I inherited a "product" (our support site), which had existing content and an underlying technology platform, both of which were limiting in some way. There is a significant cost to shifts in either that can outweigh their advantages. (We have researched other documentation platforms but haven't found one that meets our needs much better than what we have, so I'd love to hear what works for others.)
Fortunately, I've had help throughout the year. I adopted the good practices that had been established when I arrived. And I started paying a lot more attention to other support websites and made an effort to understand how they were designed. I also attended the Write The Docs conference last year, where I connected with other doc writers and learned about the resources and tools that they use.
I'm still learning though, so I welcome your advice or feedback in the comments!
At Balsamiq we've always prided ourselves on our customer service. We have real live humans who stand by the phone and love hearing it ring. And we're blazing fast with email support by providing coverage from our U.S. team during our working hours and passing it off to our European team during theirs.
We also rely heavily on our web support channel, i.e., our support website (support.balsamiq.com). This site serves as our repository for product documentation and FAQs, helping people learn the product and get help if they run into trouble. Our support site is very important not only for customers wanting to get answers, but for our support staff, who can direct people to specific articles that can answer their questions.
In 2013, we identified several touch points in our customer journey that we wanted to improve. Support was a primary focus, being an aspect of the company's service that customers can repeatedly return to. A little back story describing the evolution of our support site may help understand what we hoped to improve.
When Balsamiq started, our documentation was modestly maintained on our servers (a single page per product) and we responded to support primarily using Gmail and GetSatisfaction. As the company and customer count grew, we grew our support team. In 2012 we started using Desk.com to manage our support system, from email management to publishing our documentation.
We shipped a very basic site with a searchable set of articles using Desk's base templates. While we continued to write support articles and improve how we responded using the email management capabilities of Desk, the support site was largely unchanged. The questions and feedback we got over that first year helped us become aware of its limitations, and we started to describe the problems internally.
The predominant issue had to do with difficulty locating content. From our perspective we also identified problems connecting related content, keeping media up to date, and knowing if users were getting the answers they were looking for.
This was a re-alignment and not a redesign. We set out to improve the site, focusing on aligning the organization of content and the layout of entry pages to address the findability problems, and gardening the current content to reflect user needs.
A new look + better organization
Here's a list of the most noticeable changes to our support site, although there were many other, smaller changes we made to both our processes and our site.
Updates to our support home page
We wrote up requirements and started wireframing a rough idea that we could use to discuss the problem and explore solutions. We iterated over it a few times until we had a basic understanding and agreement on the direction we wanted to take, and immediately started front end development. We like to make refinements in further iterations in code.
This screenshot shows our initial wireframe for the support home page.
Rather than just showing the first 10 articles in each category we wanted to encourage visitors to either search for what they are looking for or choose a category to drill down into for a more approachable index page for that category. This cut down greatly the amount of text on the page and provided better entry points to a refined search. Also, by looking through our logs, we could pick out some of the most popular search terms and place them next to the search box, helping people who didn't necessarily know how to describe what they were looking for. Finally, increased use of icons and images would differentiate the categories and other link targets better.
Here you can see a comparison of the original support site's main page with the redesigned version.
Better sidebar navigation
Our sidebar (the grey navigation bar to the right on our individual articles) now links to headings within the page so that you can get an overview of the article you're reading without having to scroll all the way through to see if it contains the content you're looking for. We've also tried to save some time and effort by providing links to some related articles below that in case the page you're on doesn't answer your question or you want more information.
This screenshot shows some of the navigation changes to our sub-pages, as well as updates to our tutorials (discussed below).
More focus on tutorials
We got feedback last year saying that many of our articles were too wordy and too focused on describing features rather than on how to actually do stuff with our products. So, we made a concerted effort to step things up in the tutorials department. Here are some of the changes we've made.
A new index page for tutorials
We started by creating a new home page for our tutorials. It's grouped into categories for beginners, intermediate users, and people who want to do more with our products once they've learned how to use them.
We also got feedback from people who said that they just wanted to see the videos, so we've labeled the tutorials that contain videos as well as consolidating all of them into one playlist that's viewable at the bottom of the new index page.
We also experimented with some different kinds of tutorials. Some people said that many of our articles were too general or that they didn't have many pictures or enough guidance. So, we took some of our most frequently asked "how do I...?" questions and created a few detailed, step-by-step guides showing these processes each step of the way. Our guides on how to create a symbol and how to download from Mockups To Go, for example.
More "Tips and tricks" videos
We describe Balsamiq Mockups as "Excruciatingly simple. Filled with hidden powers." The goal of the videos we've added recently has been to reveal some of those hidden powers by showing how you can do things with Mockups that you may not have thought were possible and/or easily accomplished. We relied on our own Mockups experience as well as examples from our customers to create a few short videos, such as "How to Use Show / Hide Markup for Layering" and "How to Create Multiple Header Rows in a Data Grid" that might make you say, "I didn't know you could do that with Balsamiq Mockups!" We hope to create more in the coming year.
Here's an example of one of them:
Looking ahead / our hopes for 2014
Here's a quick list of some things we'd like to add in the next year:
- Better, clearer docs, more tailored to specific needs
- Better metrics for tracking the usefulness of our articles
- A more structured course for learning Mockups
- Tagging or labeling for better cross-referencing of articles
- Applying the editorial style guide that we finally got around to creating to all of our old articles
How are we doing? What would you like to see more or less of? Have any tips for us? If so, leave a comment below or email us at email@example.com. We're eager to get better!
— Leon and Mike
Supporting customers is such a huge part of what we do as company. Everyone contributes to customer support in one way or another, and our awesome team keep working to improve that experience.
Recognizing that we don't just care about support, but live it, GetSatisfaction interviewed Ben for their Customer Experience Series of videos. Our forum powered by GetSatisfaction has been one of the primary resources we've relied on for keeping close to our community. We're huge fans.
It's a wonderful feeling knowing that our connection to the community is in such good hands.
Hi, all. Ben here again with more sketchnotes! (Here is a link to the first set of sketchnotes I posted.) Last week, I had the opportunity to participate in the Mobile UX Summit, put on by Environments for Humans and Rosenfeld Media. It featured a fantastic lineup of speakers, all focused on the nuances of designing for mobile experiences.
One of the biggest takeaways for me was from Josh Clark's talk. He pointed out that touch devices have fundamentally changed who we are and what we do as interface designers. Whether we are aware of it or not, we are also now industrial designers. Ergonomics is a huge part of what we do, and must be taken into consideration when we craft our designs.
Another main point that resonated with me was from Jason Teague. He made it clear that we have to elevate the importance of typography. In many mobile designs, the typography and layout are some of the only design considerations you can impose on an interface to make sure that it convey the proper emotions to your users. "Mobile first" has become a cultural buzz-phrase, but we should perhaps start with typography first before tackling more of the visual design.
Finally, from Theresa Neil's case study, it was clear immediate user testing is an absolute must. This is something that we really care about here at Balsamiq, and want to make as easy as possible. We have recently added some features to make this easier, and have even more planned. I loved hearing about designers getting users to interact with their wireframes before even moving on to visual design. Taking an approach like that will save you incredible amounts of time and money down the road.
There was so much more in this conference that I loved, and hopefully my full set of sketchnotes will help you to benefit from it as well.
(Click to enlarge; ← and → to move through the images)
And here is a PDF with the entire set: Mobile-UX-Summit-Sketchnotes.pdf.
How has your design process changed as you have focused more on mobile experiences? Let us know in the comments below.
Here at Balsamiq, we hear a lot of stories about people using our application to build great user experiences. We are so proud to be a part of the UX revolution that has taken place over the last ten years. There's no doubt that many of the websites and applications that we use regularly are now more tailored to specific user goals and configured around the way actual users work. In keeping with our belief that we love the problem more than the solution and that life's too short for bad software, I wanted to write about some areas where the problem (i.e., hard-to-use software) still exists.
Every once in a while I'm reminded that there are still plenty of products out there that are in need of some serious UX love. So many companies "get it", yet there are still stragglers, especially in certain industries whose products are not traditional computing devices. There seems to be a line that divides desktop and mobile experiences from those in the rest of the digital interface world. And once you cross that line things get ugly, fast. I think that these realms represent the next frontier of UX opportunities for those willing to brave the waters.
Selling the Sizzle
My most recent reminder was at the gym. The elliptical machine I was using had a very modern component to it, the console that tells you how fast you're going, how long you've been going for, etc..
This machine has an LCD display with a touch screen. Cool, right? As a UX designer, though, I view everything through the lens of user experience. I was struck by what a bad UX this was, despite all the modern technology underneath. There's just way too much going on here. Remember, I'm moving my legs at 4-5 MPH while using it, which has quite an effect on the rest of my body. While it boasts a list of impressive features (a virtual trainer, the option to change the image I see that tracks my progress, etc.), I didn't see anyone around me with anything but the default settings. The screen is washed out and hard to read, and it's very hard to tell at a glance how to do what I want to do.
Contrast this with another exercise machine I've used in the past:
This one has quite a bit to it as well, but I would argue that it offers a much better experience.
The main problem with the first machine is not with the user interface design. There is an order to the buttons, there is a fair amount of consistency, and the buttons are adequately sized given the constraints of the screen. My guess is that there was a deliberate attempt at user interface design here. But what's missing is the user experience perspective. A user interface designer asks, How do I arrange all of these buttons in a logical way?, whereas a typical question in the user experience designer's toolbox is, Why are each of these buttons here? Are all of them really necessary?
For instance, do I really need a "virtual trainer" and the ability to change the wallpaper? And, given that market analysis has determined that the target price point necessitates a cheap LCD screen, how readable will this screen be in various lighting conditions and how well will it respond to touches from sweaty, jostling fingers? Did someone intervene and think about the experience of using this screen?
It seems that nobody thought to say, "Just because we can, doesn't mean we should."
This is a classic example of technology-driven design and "featuritis." My guess that the design discussion went something like this:
© Scott Adams - Original image here
This cartoon is from 2001, when this scenario was commonplace. Though it clearly still exists, the frustration this way of thinking caused has led to a user-centered design culture that is now at least represented, if not respected, in many software firms. It is a fundamental paradigm shift that focuses less on individual features and more on holistic tasks and goals. And it typically requires full-time roles dedicated to understanding and designing the "experience" of a product, separate from those who will be actually building the product.
Many companies outside of software and web development firms don't yet have these roles. This is problematic because the people who build digital products like the exercise machine screen are often not representative of the people who use them. There is a problem on the purchasing end as well, particularly for items like these. It is frequently the case that the people who buy the products are also not representative of those who use them. Feature lists can be used as the "sizzle" of the steak, though the consumers ultimately care most about the taste. Gym owners aren't savvy enough to pick the machine with fewer features.
Looking at this year's model of the same exercise machine, the trend is continuing. Now you can browse the web, play games, and, tweet and update your Facebook status while running (more sizzle). There are also even fewer physical buttons, just a big touch screen. And here's the description of the new "LFconnect™" feature:
Easily choose your favorite websites through your LFconnect account and they will be instantly available at login.
Do people at the gym really want another login and password to remember? And do they want to spend time configuring the treadmill while at the gym over their lunch break? Will gyms now need to employ technical support staff?
Car Interfaces: Unusable at Any Speed
Unfortunately, the exercise equipment industry isn't the only category of products that have been left behind in the UX revolution. The feature-laden user interfaces found in car dashboards in the last five years mirror the trajectory of the treadmill UIs described above.
I won't dwell on this (as others have covered this topic before), but, suffice it to say, most automotive interface user experiences are just bad. They are still in the early days, akin to the first smartphone era circa 2006, where more and more technology could be crammed into a small space for relatively cheap. And the UI design is there, but, again, it's the UX consideration that's lacking. Here's an image of such a UI:
Toyota's Entune System
Another example is a screen that shows a list of traffic incidents nearby. Yes, this is relevant to me as a driver. But what I really care about is: how long is it going to take me to get where I want to go? and is there a better route than the one I'm on now? And extra non-driving related features such as weather, stocks, and sports scores make it harder to find the functions I actually do want.
Let's look at some of the reviews of the Toyota Entune mobile app, the companion app for the dashboard experience.
Entune app reviews
I love everything about this car EXCEPT Entune!
I feel ripped off big time.
Are these the experiences people should have in a product they just paid tens of thousands of dollars for?
More Examples from the Next Frontier
Here are just a few more products calling out for help, though there are many more.
Kiosks and Self-Checkout Machines
The other day I was at a supermarket with Ben Norris and the self-checkout machine didn't recognize the bar code on what he was buying, so he tried typing in the bar code himself, at which point, seeing his frustration, the employee assigned to the self-checkout machines came over and took over, knowing that Ben wasn't going to get where he wanted to go.
The "Assist mode" screen
He'd seen this problem before and knew that anyone who hadn't been trained on these machines wouldn't be able to figure it out. It happened a lot he said, quipping, "these are the reasons I still have a job."
And now the "smart" watch flood is beginning. Here we're going to see UIs taken from other products applied to a new device, poorly (at least initially). With smartphones we had the infamous "if you see a stylus, they blew it", and now:
Why is everyone fixated on Apple building a television? It's because the current experience of watching internet programming on your television is terrible. The UX is awful. I recently spent 2 hours trying to figure out why my parents' "smart" blu-ray player wouldn't play their Netflix movies. The Samsung "smarthub" experience is much like the treadmill: Lots of options for things I don't care about (more options to change the wallpaper) and a lot of steps and difficulty for the things that I do care about. Alan Cooper posed the question: "What do you get when you cross a car with a computer?" (Answer: a computer with a motor and wheels.) Today, crossing a TV with a computer yields a computer with a remote control.
Closing the Gap (No Experience Left Behind)
Yes, user experience is a buzzword these days, but I would argue that it is far from a fad.
Looking a little deeper, what we call user experience design is really just traditional design principles applied to digital products. Good design has always been about thinking about the user of the product and the way they use it. Dieter Rams designed great experiences long before the term "user experience" existed; it's clear that his products are not just pretty, not just useful, but considered. Design is about solving problems, and user experience design is really just a shorthand way of stating that something should be designed around the user's goals and their psychological, physical and contextually-defined limitations.
The lesson of the UX revolution has been that the products with the best user experience win. Those industries that are still competing on features alone should be on guard.
Why has Apple been so successful? Because they figured out early on that it's not about features as much as it is about solutions. They think about conveniences, like pausing playback when you pull the headphones out of your music player.
Inevitably, these user experience gaps will close. It is starting to happen already. Some manufacturers of existing products are catching on and ramping up their UX expertise while smaller, nimbler, and/or more UX-aware companies (Tesla, Square, Roku, to name a few) are emerging to take on the markets that the UX laggards once had a stronghold on.
Suggestions for Companies Seeking to Prosper in the UX Economy
What if your products are the UX equivalent of a pre-iPhone smartphone? Where should you start?
First off, on our own site, you can read Craig Willis's story about being promoted to product manager based on first-hand knowledge of his product's usability problems. Or, read about Yarone Goren's firm which helps companies create a UX vision for their products. You can also build up your UX skills in-house via UX Apprentice and other sites that teach the basics of sound UX methodologies.
Then, start wireframing your ideas (using Balsamiq Mockups, or whatever suits you best). Test, iterate, refine them. Work low-fidelity, technology-agnostic first. Only then think about which technologies can help guide you to your solution, and start building. Remember that, though not always true, the best UI is often no UI. Usability does not come from adding a touch screen and UX is not a verb.
But, even before that, learn to say no. Many bad experiences come out of not being able to decide on which features are most important and therefore just including them all. This is not what your customers want from you.
A Call to Action for UXers
These industries represent a huge series of UX opportunities. As members of the UX community, let's not limit ourselves to websites and mobile apps. Does the world really need another photo filter app? If you really want to make a difference as a UX designer, go where UX is lacking. This will also add longevity to your career as you carve out your own niche within UX. Seek out bad experiences in the world and ask yourself, "could I make this better?" Be the Tom Joad of user experience.
Do this by approaching companies that don't get UX and convincing them to hire you, even if that makes you a UX team of one. Don't expect it to be easy or for change to happen right away. You may have to start out as a UX guerrilla, and you may spend more time educating your teammates about UX than designing award-winning experiences. But this is how it starts.
Many of us got into UX because of our own frustration with poorly-designed technology. Now, each day a new product comes out that has a screen that didn't have one before. There are many UX mountains yet to be ascended, many UX lands yet unexplored, many UX roads still unpaved. Go forth.
Do you have examples of products that have been left behind in the UX revolution? Do you have ideas for how some of these products could be improved? We'd love to hear about it in the comments below.
A few weeks ago I posted an interview with JR Harrell on our Balsamiq Champions blog. He is a UI/UX Designer who shared some great tips about how he uses Mockups and how to succeed as a designer today. He has recently been focusing on "flat"-style design and had a lot to say about the current design trend. I thought it would be worthwhile to publish those thoughts here on the UX blog for the design and UX community. I'd love to hear your thoughts as well, so feel free to leave a comment below.
I asked him if flat design is just a passing fad, and whether he thinks flat style is purely aesthetic or if there's something more to it. Here's what he had to say...
Leading up to Flat
On Apple, Moore's law and design evolving in-step with technology...
Design is what bridges humans to the technology of the day and beyond.
I believe that good interface and marketing design works in harmony with current and future technology. Design is what bridges humans to the technology of the day and beyond. Accordingly, prevailing design has to constantly evolve in order to keep up with and take advantage of the computing power that doubles every 18 months according to Moore's law.
It was Moore's law that paved the way for the most recent technological wave of mobile computing in the form of tiny computer processors. These tiny processors are capable of amazing computing feats in small, thin mobile devices.
Apple implemented these small processors in its iPhones and iPads to create this last wave of design and computing. Steve Jobs knew that interface design had to be completely re-imagined in order to make the most of the technology, a small screen and in order to give rise to acceptance of mobile computing. People initially asked if this design philosophy was just a fad too.
The impact of Apple's mobile devices on the world of design was seismic and has had an amazing run for the last 5 years. But, times have changed. Here's where flat design comes in.
The Business Case for Flat
JR sees both business and development benefits to flat design...
Due to the huge amount of money that is at stake, aggressive competition, inevitable innovation and some widely publicized court cases, the mobile space has opened up to a number of non-Apple devices that are widely and heavily used by consumers. It's an obvious fact that businesses must go and will go where the consumers are at.
Flat design works well with these mobile devices and marries up nicely with responsive design. Flat design allows businesses to be able to build websites, apps and more one single time and run them across multiple devices and go where these consumer dollars are at.
With flat design the cost of development goes down because more consumers can access a single design set.
With flat design, at least in theory, the cost of development and ownership goes down because more consumers can access a single, agnostic design set. I personally believe that flat design is beneficial to both businesses and users because it increases engagement through better accessibility overall.
As much as I love Apple (I have an app in the App Store), it's no secret to say that they are begrudgingly playing a bit of catchup with flat design.
So, I would argue that flat design isn't a passing fad, it's simply the next step in design that reflects the growth in computing power and how humans will use it. It's a good thing.
A flat site design that JR did that's also responsive (via drawnn.com)
JR sees flat design extending beyond mobile apps and websites...
Looking beyond today and into the future, flat design is a way forward for the next phase of design and computing interaction for devices like LEAP, Google Glass, Kinect for Windows, Nest environmental control systems and more. It is easier for these devices to render interactions with flat objects than it is with skeuomorphic designs. Not only that, but consumers will grow accustomed to flat design, so these devices will implement it in some form initially so that they will be better received in the marketplace.
While these devices will initially adopt some semblance of flat design, that too will give way to new design regimens that will mostly supplant flat design. It's a cycle.
JR has even started applying a flat aesthetic to t-shirt designs (via drawnn.com)
Keeping Pace with Change
Rather than fearing what comes after flat design, JR is already trying to anticipate and even guide what's next...
The beautiful thing about Balsamiq Mockups is that I won't have to remove it from my tool bag as flat design grows in popularity.
I understand this natural evolution and embrace it and am already working on projects with forward thinking clients that will be the face of this next era in design and computing. I am really excited about it.
As Paul Graham teaches us: "Live in the future, then build what's missing." The beautiful thing about Balsamiq Mockups is that I won't have to remove it from my tool bag as flat design and interactive computing grows in popularity.
In fact, I am able to create incredible flat design and interactive computing wireframes that are amazingly similar to the ultimate end result in the finished design. This makes Mockups that much more important to what I do on a daily basis.
Before and after designs for a weather app
Thanks again to JR Harrell for contributing your insights! For those of you who are interested in keeping up with his thoughts and work, you can follow him on twitter at @drawnnit.
To add your comments on flat design or anything else UX related, drop a note in the comments section below.
Hi, I'm Ben. This is my first blog post for Balsamiq, so I thought I would do a brief introduction. I am a long-time user and fanboy of Balsamiq, and starting this last April, I am partnering with Balsamiq to help ensure the software is of as high quality as possible. As part of my responsibilities around testing, I monitor the community forum and report issues that come in. This means that I spend a LOT of time in the GetSatisfaction community. In May, GetSatisfaction had their first annual customer success summit. I went to connect with other people working with online communities and to hear about what is coming.
We thought it would be fun to share with you the notes that I took at the conference. I am an avid sketchnoter, and it can be kind of fun to look at sketchnotes, even if you were not part of the event. Hopefully you enjoy these!
(If you've never heard of sketchnotes before, Mike Rohde's book: The Sketchnote Handbook is a great place to start!)
I've started trying to teach sketchnoting to others at Balsamiq so you might see more sketchnotes around here in the future!
Until next time, Ben
I have a confession to make. For the first few years of my UX Design career I was afraid to call myself a designer.
I rejected the designer moniker to gain acceptance at the technically focused, development-led enterprise software company where I started my UX career. In order to be involved in the process, I felt that I had to prove that I was an insider, and, where I worked, "designers" were outsiders.
This was in an era (~10 years ago) where the standards for software usability were much lower and product decisions were driven strictly by requirements for what functions a product should perform, not how it should behave. While my company did have a small user experience team, our influence was limited and our skills as usability experts were underutilized. My manager called what we did "guerrilla" usability, because it felt as if the real work we were trying to do wasn't officially sanctioned or supported from the top.
We were seen by many on the development team as "design-types", who had no role in creating software, except for adding some sparkle or polish at the end. Another member of my team, who had been there for a few years, alternately described what we did as either "putting lipstick on a pig" (as when we were asked to provide icons or splash screens) or "giving the pope's blessing" to products as they were sent out the door (as if we had much choice when they were already past deadline and had been committed to being released the following week).
We tried to involve ourselves early and take our position up front, as we had been taught we should. Our typical process was to take the set of product requirements and approach the design from a holistic perspective, looking for all the ways we could improve the overall experience. We would emerge after a while with what was often a great design. The stakeholders would all nod when we showed it to them and agree on its merits. And then it would get ignored.
After going through this a few times, I realized that if I wanted to make a real impact, I had to change tactics.
I suspected that the individual developers held the keys to the end user experience of our products, more so than the product managers or development managers, so I decided to infiltrate their ranks. I set out to become a guerrilla UX warrior and enhance the usability of our products from the inside out, from the bottom up, one small step at a time.
I focused on small wins and tried to get them however I could. I threw my early ideals about awesomely-designed, intuitive, flow-inducing experiences out the window and, humbled, lowered my expectations.
Rather than starting with a comprehensive design (the "big design up front" approach) and focusing on getting approval from a development manager, I decided to target the developers themselves and work within the existing process.
In the trenches
Since I was not usually included in the process until the very end, I couldn't wait for the developers to come to me, so my first step was to go to them. But not with designs in hand, or a list of UI guidelines to follow. I would just casually stop by their cubicles and ask what they were working on - "how is it going?," "could I take a look at what you've got so far?," "do you need any help with anything?" Sometimes this last question would return a look of bewilderment that said "wait, what do you do, again?"
When I did get a response to it, it would often be along the lines of "I need a new icon for the toolbar, could you make me one for an XSLT transformation?" But every once in a while I'd get: "Um yeah, maybe. I'm working on this settings dialog and I'm not really sure where all the fields should go. Can you help with that?"
Aha! An invitation. An opportunity.
Despite the simplistic request, I'd try to be as enthusiastic as possible. "Sure, I can do that for you. What are the fields and values? Maybe you can send me a screen shot of what you've got now?" I wouldn't question whether the user really needed all those settings, I'd just go about using best practices to lay out the fields in a logical order and group and align them appropriately. It was UX Design 101. It was also a chance to hone my design fundamentals. I got really good at figuring out when to use radio buttons vs. combo boxes.
I'd quickly return with a design and they'd be pleased. Not because it was a good design, but because I'd just done some work they didn't want to do. I'd made their job easier (as well as making the user experience better). I made sure not to scare them off by getting all "design-y" on their simple settings dialogs.
It started working. With some developers, this turned into a habit. The "cue" was me stopping by. The "routine" was asking me for help on something UI-related that they didn't really know or care about. And the "reward" was less time spent doing UI design.
Eventually, some of them even started coming to me at the beginning of the process. I called this approach "one developer at a time."
I learned what we'd been doing wrong all along. We had been trying to promote UX at the top level by positioning it as a benefit to our customers. But what really allowed it to take hold was promoting it at the ground level as a benefit to our developers.
It didn't work with every developer, of course. I was still viewed by some as the person who was there to make their jobs harder by giving them "pie-in-the-sky" designs that would take months to build. And some developers just didn't want to relinquish any control over "their" product and never really took to my approach.
But, I slowly built a cadre of developers who liked working with me and I made sure to seek them out and give them a good experience working with me whenever I could.
Another tactic I employed was sitting in on lots of development meetings, even if the topic was strictly back-end stuff. It was all part of just being available, without forcing design down their throats. I didn't talk much unless asked a direct question. In those instances, I'd try to wow them every once in a while. "What's the primary use case here? Can we just default to those settings and remove the dialog entirely?" Did you see that? I just saved work and made the end user's life easier.
Over time, these tactics bore fruit and I started to see my work in our delivered products. I began to judge my abilities less by the quality of my designs and more by my influence on shipped code. I'd delight in seeing consistent use of capitalization, and spaces between property names where there was once camelCase (e.g., First Name vs. firstName). There were bigger wins as well, like a dashboard product that I worked on iteratively with a developer that ended up matching my storyboard nearly exactly.
It may not have produced the most ideal, intuitive experiences, but, in my mind, some improvement was better than no improvement, and I think our users were better off for it. Heck, even Steve Jobs believed that "real artists ship."
Long after leaving that job, I'm still trying to unlearn some of these habits. Balsamiq has a decidedly un-guerilla-like User Experience Design environment. Valuing good design is core to everything we do. I'm starting to think more ambitiously about what's possible and have higher standards for usability than I have in the past. Intuitively designed interfaces are important, after all. Usability matters. (It can even be the difference between life and death.)
Yet, I'm grateful for my experiences early on. I believe that designers exist to solve real problems, not win awards or promote themselves. And it's OK to have to earn your place on a team by proving that you can work well with the existing members. Because of my early role, I don't take my ability to contribute as a UX Designer for granted. And I still think about designing for implementability and am cautious about "over-designing". I try to avoid design for its own sake.
In the end, you can't forget who you're designing for. It's typically someone who really doesn't want to use your product, even if they love what it does for them. UX Designers should try to help them do what they need to do quickly and easily, so they can move on to the next thing. Get your customers to not notice the work you do and they'll actually appreciate it more.
Are you a UX guerrilla? Do you have battle stories you'd like to share? Or, are you a developer who's worked with overly "design-y" designers who have made your job harder? We'd love to hear all about it in the comments!
p.s. Big thanks to Ben for the awesome sketches!
Hello friends of Balsamiq, we have a very exciting new resource to announce today!
Balsamiq Mockups has helped democratize interface design in the communities who use it. A broad range of people coming from different roles and fields have adopted sketch-style wireframing. Making ideas come to life quickly with wireframes is a revelation. Your newfound power to create user interfaces is exhilarating!
Soon enough though, all beginning UX designers realize that creating products that are easy to use is actually quite hard! You have to know about information architecture, interaction design, copywriting, and lots more.
Meet UX Apprentice, a new site we created for people learning about User Experience Design.
We worked with Theresa Neil on developing a learning resource that covers some of the basics of the practice, and provides links for digging deeper and perfecting the craft.
We feel very lucky to have joined up with Theresa, who wrote the content and helped us design this site. She is a design consultant, and author of two O'Reilly books on interface design—Mobile Design Pattern Gallery: UI Patterns for Mobile Applications, and co-author of Designing Web Interfaces: Principles and Patterns for Rich Interaction. We called on her depth of teaching experience as an author and as a consultant who educates companies about UX Design to bring this knowledge to our awesome customers in the Balsamiq community.
We hope UX Apprentice helps many people who are getting started with interface design to both broaden and deepen their knowledge about UX Design.
Ready to dive in? Let's go!
Hello, blog readers!
This is my first blog post for Balsamiq. Anyone who's worked with me knows that I have been a user and fan of Balsamiq Mockups since the beginning, so I am super excited to be a part of this awesome team.
Before coming to Balsamiq, I worked as a User Experience Designer and Business Analyst in Agile software development environments, so I thought I'd focus my first blog post on some tips I developed for creating Agile User Stories that served me well.
First off, I think that Agile and Mockups go great together. Agile is fast, embraces change, and doesn't require precision. Just like Balsamiq Mockups!
In this post I'll explain my Story writing process by describing the steps I'd go through to create a User Story for a made up feature. These steps are: break up the design; order, prioritize, estimate; and write the recipe. I probably deviate a bit from the suggested formula and format for User Story writing, but I feel that it's still true to the principles of Agile.
Side Note: This post is written from the perspective of, and primarily for, someone who writes User Stories in an Agile Development environment. I'm thinking mostly of Product Managers, UX Designers, Business Analysts, and any other people who are primarily non-technical, but work closely with software developers who are the recipients of User Stories.
I'll start at the point that the mockup is finished. At this point a lot of the work is actually done, but it's important to take the next steps to craft a good User Story out of your design.
Let's say that you've come up with a design that allows users to view a list of customer demographic information. Something like this:
Now, it's tempting to just drop this into a User Story and say "build this". But it's important not to discount how much information is in your head about how this relatively simple page should function. There are some gaps that need to be filled in for the developer who's going to be building it. But don't under- or over-think these gaps. My Story writing approach is focused on "the art of maximizing the amount of work not done", which is one of the reasons I use Balsamiq Mockups.
This approach is all about taking advantage of the 80/20 rule.
The trick here is to combine the 20% effort that gets you 80% of the detail in a visual representation with the 20% effort that gets you 80% of the detail in a text specification.
There's no question that developers need detail in User Stories. Mockups is great because it will get you 80% of the information that you need to communicate with 20% of the effort of a more interactive or pixel-perfect tool. Now, don't spend 80% of your effort on that last 20% of the detail, just describe it using plain language in the User Story (I'll describe how later). The goal is not to have a huge, impressive-looking specification or prototype, the goal is to ship a product that allows your users to accomplish their goals.
Your User Story should be just enough to get it built successfully. Any effort beyond that is waste.
Step 1 - Break up the design
What often surprises product managers is how long it takes to develop user interfaces. A lot of that frustration is due to a lack of understanding about how user interfaces are actually built. There is rarely a correlation between how long it takes to design and how long it takes to build. That's why I like to take the time to divide up the design into smaller chunks.
Even this simple design can be broken down into pieces. Pieces, mind you, that can be delivered individually (as long as an order is obeyed). You can't deliver an incomplete feature, but you can deliver a small part of a larger feature. There's a difference. A button that doesn't do anything when you click it is incomplete. A data table that you can view but not edit, for example, can stand on its own.
Here's how I might break this feature up into pieces:
- The table and its content
- The search field
- The edit and delete functionality
- The ability to export
Note that, in that order, they can be delivered, and even released, in pieces. A table that doesn't have search may not be as useful as one that does, but it's still contributing towards the original feature requirement. Each Story should add some amount of value, however small, for the customer.
Side Note: Just because you're going to break up your work doesn't mean that you should think this way during the design phase. The value of Mockups is that it allows you to easily get what's in your head onto the page. And, more often than not, what's in your head is at a high level. So, go with it, and design what's in your head. Don't worry about the Story writing when you're designing.
Step 2 - Order, prioritize, estimate
A note about the ordering of the Stories. The important thing when breaking up a design into pieces is to find the foundation, the piece that other pieces will be built upon. In this case, I chose the table itself. You could argue that this is also the most important piece of functionality. The foundation often is. That's why I write this Story first. Writing the most important Stories first helps ensure that the most important features get delivered. With fixed release dates and shifting agendas, never assume that everything will get shipped. Start with the important stuff and you'll at least be maximizing the value of your time.
When I insert the mockup into the User Story (as an embedded image, attachment, etc.) I don't necessarily remove the peripheral information once I've decided how to break the design into its components. One of the things I like to do is show the full mockup that I created, but obscure the parts that don't apply to the specific Story. That way, it's clear what the objective of the Story is, but you're also keeping in focus the end goal.
I might do something like this, for example:
I've greyed-out the peripheral pieces, yet left them visible for everyone on the team to see where we're headed. The numbers refer to the Story numbers of the other pieces.
One real benefit of breaking up the design like this is that now you can get estimates on each of the pieces (and the mockups alone should be enough to get estimates), which should not only be more accurate, but can be divided up across sprints. Let's say that after the estimation meeting the point values end up something like this:
- Table with customer data - 2 points
- Edit and delete functionality - 4 points
- Search - 1 point
- Export - 3 points
This will allow the product owner to make better cost-benefit decisions about the overall set of features. Maybe the export function is something that one noisy customer keeps asking for but that you know won't be used by most of your customers. Seeing that this piece is relatively more "expensive" than some of the other pieces might prompt you to put it off until the next release. This wouldn't have been possible if all you had was a 10 point estimate for the whole design.
We've actually come a long way already at this point. But don't stop there, there's one more step!
Step 3 - Write the "recipe"
The final phase is to use the mockup to help you figure out the details that the developers need to know to build it. A trick I learned to do this is to imagine yourself using it. Mockups is awesome because it clarifies the picture in your head of what you're building and allows you to picture its use. I've found this process to be extremely helpful in providing the details that the developers want while building it.
Creating a mockup is kind of like cooking something. Think about cooking your favorite dish. Now, think about writing a recipe for how to cook what you've made. It's a different process entirely. It's shifted from creating to communicating. It's all about putting yourself in their shoes and not making too many assumptions about their level of understanding or knowledge.
The lesson here is that the process of creating the mockup is actually more for you than for the developer. It helps you figure out what you want to build, which, in turn, makes it easier to communicate how to build it (even if you're completely non-technical).
The structure of a User Story that I was taught is the following:
- Summary/Story Narrative
- Acceptance Criteria
Side Note: I like to include the "why" of what we're building in the Story Narrative section and explain what value this feature provides. Believe it or not, developers care about this. And this explanation should pass their "smell test" too. If you can't get them to "buy it", maybe you should revisit why you're doing it.
The third part is Acceptance Criteria (also called Conditions of Satisfaction, Acceptance Tests, etc.). This section is both for the developers and the testers. Here is where I think I take a bit of liberty with the traditional format. I like to think of this section as the recipe part. Here is where you, to the best of your ability, tell the developers how to bulid it. Don't worry if you have a hard time with this at first, one of the benefits of this process is that it helps you learn what information developers need to build things. It opens the window into the development process, which benefits everyone.
Again, here we start with a foundation. Don't be afraid to get very basic. I might start, for example, with "Create a table with the following columns: Last Name, First Name, Address, Phone". Small pieces make it easy to check things off, and often actually correspond to the chunks of code the developer has to write.
Now that you can see this table with customer information in it, picture using it. Aside from the features that you've deliberately split off into other Stories, what might you, as a user, see and do here? Can you sort columns? If so, all columns, or just some of them? Anything that you can come up with along these lines is most likely information that the developer needs to know.
As a bonus, if you're somewhat techincally savvy, you might be able to think of other things the developer might want to know. You might know that address data is stored in separate database fields (street, city, state, zip, for example). If you don't specify, the developer may create separate columns in the table for each of these, because that's how they see "address". But, you may know that users prefer to see these fields together (maybe so they can easily copy and paste them all at once). So, add to your recipe that the address field should include street, city, state and zip together. Trust me, stuff like this is important.
But, also, realize then that users probably won't be able to sort the table by city, for example, because "city" is not a distinct column in the table. Product managers often want it both ways. Being forced to write the recipe yourself doesn't allow for that. It's a trade-off: do you want a more human-readable address field, or do you want to be able to sort by each part of the address? It's up to you. This is not the developer's problem.
For this particular Story, here's what my acceptance criteria might look like, just to give an idea of some other possible details I might include.
1. Create a table with the following columns: Last Name, First Name, Address, Phone
2. Add a level 3 heading title above the table with the label "Customers"
3. The Last Name, First Name, and Phone columns should include the last name, first name, and primary phone number fields, respectively, for each customer
4. The Address column should be comprised of the following fields (in this order): street, city, state (abbreviated), and zip code (5 digits only). Wrap the text to the next line at 100 characters.
4. By default, order the table by customer last name (ascending)
5. Allow the table to be sorted by last name or first name
6. Add pagination at 25 rows
See how many details there can be for a simple 4-column table?! The take-away here is not about how hard it is to build this table (it may take only 30 minutes if you already have a table framework in place), but how many decisions need to be made when building it. And that, if you don't specify them, those decisions will either be made by the developer or the framework you're using. As in many cases, not making a decision is making a decision. Now, if you don't care, that's another thing. But I would argue, as would many others, that details matter.
At this point, I would show the Story to the development team for a reality check, make any modifications necessary based on their feedback, and put it in the development queue. That's it! Then, on to the next Story… ;-)
A few final tips:
- Sometimes you'll want to make minor tweaks to the Story after the mockup is done (label changes, etc.). Even though updating the mockup is easy, sometimes I'll just update the text of the Story. I make it known that if there's a discrepancy between the text and the mockup, always follow what the text says.
- Be casual in your language. Write like you would write for someone who's looking after your dog while you're away. Don't be afraid to write thing like "the styling should look like our other tables" or "work with the graphic designer to create an export icon". Only include as much detail as necessary. Ask the developer if anything is unclear to them.
- Every developer is different, so you may end up changing the level of detail based on your team. Some just look at the mockup, some go straight for the acceptance criteria. Some improvise when details are missing, others refuse to continue until they get clarification. Try to learn their styles and preferences. Ultimately, try to take responsibility for making your Story clear and easy to understand.
This process has been successful for me. What's your Story writing process? What tips have you developed for writing User Stories? If you have any thoughts on the process I've described or your own tips for writing User Stories, feel free to share in the comments.
Next Page »