Hi, everyone. This year we're working on some projects to polish Mockups, and we want to give you a preview of one of them—the redesign of the application interface or app chrome.
Application chrome refers to the user interface elements of the application window outside of the canvas. This includes such things as the menu bars, toolbars, progress bars, ui library browser, dialogs, and inspectors. Essentially what we're doing is polishing the design of Mockups itself.
With the release of myBalsamiq, we've started introducing some new interface elements in the app, especially the app bar. The chrome design hasn't changed much since Mockups was released, but with myBalsamiq, the accretion of elements has become noticable, and the changes more drastic. We wanted to refine this area, see what could be cleaned up or removed, and prepare for the future.
Goals
Now is the right time to focus on these:
- Fix usability issues related to visual design (contrast of scrollbars, for example).
- Making the myBalsamiq editor chrome match the design of the html views.
- Create a coherent design language and style that works across the Desktop, myBalsamiq, and plugin versions.
- Create an aesthetically pleasing experience that we want to look at every day.
- Prepare for desktop/myBalsamiq integration, and Mockups for Desktop Pro(jects).
On the surface you might say it's just a re-skinning of the chrome, and you'd be right. We're starting by cleaning up the current functionality.
If you look closely at the design for mybalsamiq you'll also see that the interface includes a project (and symbol library) browser sidebar. As we move towards our goal of bridging Desktop and myBalsamiq, some of the design elements of the myBalsamiq editor will make it to the Desktop app.
Preview
Here are some design comps of what we've started implementing. Click to view larger.
Desktop App Preview
myBalsamiq App
That's a quick preview at where we're headed. We hope you'll agree that the direction we're taking is a sensible one at this time. As always, we welcome your feedback with open eyes and ears. Leave a comment or email me at mike@balsamiq.com.
We know we have a long way to go. Every day we take another step.
You can try the pre-release here on the web or download the latest 2.2 candidate here. Bookmark that page and check it daily! ;)
Opinions matter
Every so often we'll get a request to add features that would change Mockups from a sketchy wireframing tool to a prototyping tool. When these requests bubble up, I take the time to explain to people what Mockups was designed for, and often point them to our Manifesto, which discusses this and other beliefs we hold as a company.
We have a tutorial that illustrates various methods for designing for interaction, and shows where Mockups fits into this picture. It sometimes helps to share this, because occasionally I'll discover that the person asking is not aware of these methods for specifying interaction. More often than not, they're satisfied to have this information.
Mockups is primarily an application for describing interactive behaviors with static pictures, and this statement doesn't always sit well with people who believe that deliverables have to come very close to the real product in order to communicate the design. We have a different opinion.
The debate: sketching vs. prototyping
There are arguments on either side of the debate about whether or not you have to use interactive prototypes to describe interactive behaviors. On the prototyping side, the argument is that you can't communicate interaction without working prototypes that resemble the real thing. But animators and film makers have communicated motion with static drawings for as long as these media have existed, and at least in early-stage ideation, many still do. The same holds true for designing interaction.
Probably the most important reason we stick to this mode of design early on, using sketch-style static documents, is that doing so keeps us focussed on exploring ideas until the right design emerges from the volume of alternatives we consider.
BIll Buxton makes another point about the value of early-stage, low-fidelity design in Sketching the User Experience. Buxton believes that iterative sketching has a dramatic impact on risk, exploration and innovation.
"Jumping in and immediately starting to build the product, even if it does get completed and ship, is almost guaranteed to produce a mediocre product in which there is little innovation or market differentiation. When you have only one kick at the can, the behaviour of the entire team and process is as predictable as it will be pedestrian."
We believe this. Moreover, as a small business, it's of utmost importance to us to find the right design early. Selecting a wrong design that we would need to pivot on later could cost us and our customers in time to ship, in usability, and worse of all, relevance.
There is no silver bullet
I watched and participated in theoretical discussions about what the "ultimate IA/IXD tool" could look like on IA mailing lists. A lot of that discussion ended up with people going in separate directions:
- sticking to wireframing in graphics tools
- doing full-on prototyping with heavier graphics tools
- using some hybrid and manual approach: focus on ideation and then jump to building/prototyping in the medium of intended use (html, flash, etc.)
- wireframing and prototyping purely with HTML (manually or using an MVC framework)
Mockups undercut the different approaches that evolved out of that time by focussing on one thing, suggesting that you don't need to do it all in one tool. Instead Mockups focuses on sketchy wireframing and at most, static click-throughs. I saw it as a logical evolution of tools like Denim, rather than a continuation of the process past wireframing. Your use of Mockups should end when UI decisions are selected, so you can build.
I was one of those people who clamored for a holy grail UI design and prototyping tool for designers. But looking back, I was the first to jump ship after trying different prototyping tools. They depended more on spending time learning to use the tools and less on producing more ideas.
I felt like there was a possibility of using these tools, but in all of my attempts, what worked for me was to build my own tool from frameworks to do HTML prototyping. That approach seemed fine, but in the end I abandoned it, because I found that I was faster at sketching and wireframing. It was back to pen, paper, and wireframes. Then Mockups came along.
I want to focus on ideas, not design artifacts. Can interactive design be demonstrated more effectively with interaction? That depends on a lot of things. I think the better question is, for exploring design ideas and finding the right solution, is interactive prototyping necessary?
Why we aren't designing Mockups for rich prototyping
We in no way underestimate the value of prototyping. We also do not want to go there with Mockups for now. I'm taking the time to explain why because I take this issue seriously, and I sympathize with the desire for interaction in the app. I also apologize because I know what I say doesn't get you what you're asking for, if you're asking for interaction right now. But I have to tell you, that once I gave up on the idea of being able to both wireframe and prototype in one tool, I felt more free as a designer, and am able to work faster and smarter.
Having used it for a few solid years now, I think we're doing the right thing in keeping rich interaction out for now. I don't think we're precluded from going there some day, but Peldi's vision is clear, I support it, and I agree with the reasoning behind it.
As an early user, I asked for interactive features because I was used to working in separate modes to design, specify, and prototype: sketching, wireframing, and building. I wished for a way to move more fluidly between each mode. What I never stopped to ask was, "why?" Why do I need interaction for exploring design ideas? The answer is that I don't. Now I strongly believe that having it all in one tool comes at a cost in terms of complexity. I don't want to incur that cost, and that's one good reason to keep Mockups from going there.
We believe Mockups is effective as it is because rough and simple sketches are great for generating ideas. We don't want to compromise the application with features outside of that main purpose.
More is less
With each new feature that is added below the surface of our application, the iceberg gets heavier. My main concern having used many complex prototyping tools out there was that if I didn't get it in 10-15 minutes of use, I had to read the manual. Once I had, I thought, "Why would I want to invest myself in doing this?" To me, it's bad enough that I can't just tell someone what to build by just sketching on paper.
Mockups cannot turn into a knob-heavy surface, like an airplane dashboard. Can we design it more elegantly to stick with the zen-like approach of working on one thing at a time that characterizes Mockups now? Probably. But now is not the time for us to even consider going down that path.
I've been told in certain situations, that interaction is the pitch. It depends on who the audience for the design document is. In some cases, I know it's hard to sell what people can't try or can't see. But for many people out there, there are ways to make that pitch creatively without compromising your project.
Will it benefit you for Mockups to become a heavier piece of software rather than a focussed experience? I don't think so. We have a vision to keep it as simple as possible now. We still have a long way to get there. We have bugs to kill, we have problems to fix. These, in my opinion are way higher up the list than demonstrating state changes at this phase of design communication.
This debate will go on, but that's what debates are for. In the end we want to build, and if we get to the end goal of making Mockups what we consider a polished tool and the ideal experience to match with the vision in Peldi's manifesto, I think we'll be in a better position to see where to go next.
Do what works for you
There are many ways to communicate design. There is no right or wrong way. We say, ignore anyone who says that your method is wrong. We've heard arguments on either side of the wireframe vs. prototype argument repeatedly. We won't try to sell you on our side, we'll just tell you what our opinion is, because we believe in it strongly.
We would never make absolute claims about what's right versus what's wrong. There is room in the world for many points of view. We think you need to do what works for you, and if your opinion differs from ours, we'll point you to software that fits with yours. We do have a strong point of view, however, that is based on the belief that early-stage ideation is effective at low-fidelity, and that is represented in our product.
We've aded a new tutorial in the support section to suggest some best practices for specifying interaction using Mockups.
Software designers and developers designing for the screen have an arsenal of well-known practices for communicating interaction in static documents. Many of the techniques have been borrowed and adapted from motion designers, filmmakers, and animators.
Read the tutorial to learn more about doing interaction design with Mockups.
Interface sketching is a path focussed on generating ideas and finding solutions.
I feel good when I have a drawing pen or pencil in my hand. Doodling, sketching, and drawing has always made me happy, whether it's trying to be artsy in life drawing classes, imagining characters while drawing with my son, or capturing ideas for interfaces. I'm not the most skilled with a pencil, but I enjoy it. It's the quick and spontaneous creation that I've always loved, and I love being able to sketch as an interface designer.
Sketching interfaces is a path focussed on generating many ideas, and to borrow from Bill Buxton, is an activity that leads to finding the right design. It's focussed on finding solutions to problems. Lately I've been thinking about how to further take the activity of physically sketching on paper, to get the same results in Mockups.
Sketching in the physical world
I think there's something interesting about capturing interface design ideas in sketches as a disposable, spontaneous action. After the conversation and research about the problem you're solving, there is always the need to visualize the solution. The quick sketch is the right tool at this time because it can be focussed on the idea without becoming attached to how it's represented visually—form is rough and function is usually the focus.
Here are some key things to keep in mind when doing interface sketches.
- create quickly
- create a lot
- don't worry about how it looks
- don't become attached
A lot of interaction designers and information architects make this part of the ideation phase easier by creating templates with small spaces for teams to create sketches within. These look like little storyboards. They're compartmentalized sheets of paper, usually 6-up or 8-up for thumbnail sketches. The idea is to produce as many ideas as possible at this stage and at this scale, and progressively add information, select, iterate, and refine.
Brandon Schauer and Leah Buley at Adaptive Path talk about using Sketchboards as a way of generating ideas with sketches and quickly performing iterations on many possible solutions. Todd Zaki Warfel of Message First also has a similar sketchboarding technique that he calls a the 6-8-5 method, where individuals produce 6-8 sketches in 5 minutes.
I've done most of my intertaface sketching on paper, but I've been wondering how to do that same sort of rapid-fire sketching early on in Mockups.
Sketching in Mockups
Over the past year I've continued to sketch on paper, and occasionally scanned and shared them with my team. But when the myBalsamiq beta/gamma matured and became more stable, I started finding myself experimenting with how to use it to do nearly everything.
Our design process at Balsamiq is a bit like a conversation that can start from any point, but which usually flows down a similar path. Here's one typical design/dev cycle for me.
- A feature is introduced from somewhere, internally or externally. A feature might be discussed in Pivotal Tracker, our issue tracker, or a quick Skype conversation may start it. From here, the story is described more completely.
- Ideas are are mocked up. We set down broad strokes. Traditionally, this is where I sketched. It's like the beginning of a conversation about a new topic, where one person introduces the topic and the dialogue ensues.
- The idea is iterated, a solution might be selected. We quickly select the idea with the most merit and iterate over it, filling in details about the flow and interaction required by the feature.
- The mockup becomes a UI Requirement when we finally all approve, and we build.
Previously I was doing all the sketching on paper, but now I'm starting to do some rougher, sketch-style ideation in Mockups using myBalsamiq. We're also doing all of our Mockups work in myBalsamiq now, so the critique and review sessions are happening there. And since myBalsamiq is much like using a wiki with version control, alternate proposals and the iterations are happening there too. All the ideation is being moved into the ecosystem we're building for ourselves.
What's a thumbnail Mockup?
Mockups has the low-fi aspect of sketch-wireframing covered. But we're still dealing with wireframes when we work in Mockups. There's already a level of detail working at wireframe scale, and when you work too early at that scale, there's the danger of diving deep before you're really ready.
It's hard to imagine that low-fidelity wireframes made with Mockups can become precious documents. The thick, crooked, sharpie-like lines and the unattractive hand drawn font are there to keep you from fussing and making things pretty and real. But they can become precious, and for many people they will. It's natural. You work with something for long enough and you become attached. This is especially why I think there is a step that you might consider before diving into full-scale Mockups, where you're even further from sweating the details, so you can see the bigger picture.
This is where thumbnail sketching steps in. I hardly ever start full scale on a wireframe. Before I have the chance to even think about the details I work with thumbnail sketches. It's like zooming 20 feet away from the thing you're designing, blurring your eyes, and just seeing the major elements of the page.
The idea with thumbnail sketching is to draw a smallish representation of your design, roughing out boxes and greeking lines of text to get an idea of what your interface will look like. You actually don't even need text to sketch the interface, just scribbled lines. You can use text captions to describe what's happening in the story.
Here's a picture to give you an idea of what I create on paper.
Ryan Singer of 37signals wrote a nice article in 2004 that illustrates his interface design approach, and shows some nice sketches like this if you're interested in seeing more sketches at this kind of scale.
Now here's a screenshot to give you an idea of how I've been doing the same thing with Mockups
I think this give you an idea of how I'm trying to make it close to the same experience in terms of speed and fidelity.
How to make thumbnail Mockups
To create our Mockups at this scale, we start out with two simple shapes: the box and the line (straight and squiggly). With these two, you can pretty much draw most of what you need for web and app interfaces, although you occasionally need other basic shapes like ellipses and triangles. Then, of course, you will probably need arrows to show directional flow.
I've created a thumbnail sketch symbols library that includes 2 sets of templates for 6 up or 8 up sets of thumbnail sketches, and a thumbnail sketching elements library. Download the "Sketch Templates" symbols library here.
Here's the basic set of sketch elements in the sketch library:
There's not much to it. These are the basic elements I used. There are straight and squiggly style lines for the text elements.
- Title/Heading
- Subtitle/Subheading
- Paragraph
- Sentence
- List
- Label
- Text Input
- Textarea
- Checkbox
- Radio button
- Button
- Horizontal rule
I can combine these with whatever geometric shapes and rectangles might be needed. I start to build up layouts quickly by dropping these blocks into place and annotate as I go.
Next you step through parts of the interface or entire views, by sketching the interaction and flow through some functionality, either in story-board form or by breaking out parts of the page into a sidebar, or what Dan Brown calls page description diagrams, illustrating state changes.
It might help to get an idea of how I do iterations on a single sketch board, so we've made one of our internal myBalsamiq projects for redesigning the Mockups heads-up-displays available for you to look at here. In particular you might want to check out the history page for my sketchboard to see how I stepped through iterations on that sketch.
Finally, you can look at how we started to work at the right resolution once we selected a concept from the sketchboard that represented the direction we wanted to go in. The wireframes for the HUD are worked on at 1:1 scale or something close to it when we're ready to start considering more than just abstract gray boxes.
What do you think?
Mockups gets faster for me when I focus on doing the right thing at the right time, and this idea is working for me for making quick sketching, or sketch-like activity more collaborative. I'm going to keep experimenting with this technique and updating the sketch library as I continue to evolve it.
Here's a bonus. If you haven't seen Dave Gray's Forms Fields and Flows video, you should check it out. In it, he writes about how sketching is just combining forms and lines, and all you really need to be able to come up with pictures is to see and use these basic shapes. This is what I'm doing most of the time when I'm designing outside of the intended use of Mockups' UI library.
Have fun!
This week we quietly relaunched balsamiq.com, overhauling and re-tuning the site to align with our new priorities as a growing company. On the surface it may not seem like a huge effort, but it was challenging.
I'll run down the goals of this project, and talk through some of the steps we took to make it happen, in the interest of sharing what we learned.
Defining the Project Goals
When I came on board, Peldi expressed the need to look at the web site and learn how we can help make it easier for our customers to accomplish a few key tasks. Peldi's blog talks a bit about how we're slowly growing the company, and over the last two years as the site has grown both deep and wide, finding things has become harder.
Our high-level goals were to focus on information architecture and findability, with a little effort to smooth out rough edges. From the top, here were the priorities we thought the new site needed to focus on:
For Current Customers
- Make the update process simpler and the badge/button easier to find
- Provide clear paths to support materials, e.g. documentation, updates
- Simplify the site navigation and reduce verbose copy on very long pages
- Make the documentation navigable
For Prospective Customers
- Introduce customers to the company and reassure them of our mission--we compete on usability and customer service
- Provide clear, no hassle path to try the product right now
- Cut redundant content, get to the point about what our products are
- Provide clear call to action--aka make the button bigger and redder ;)
- Simplify the buy process
For Us
- Tell the story of our growing family
- Make it easier to maintain content
- Centralize frequently used elements
- Emphasize the voice established by Peldi and bring in the entire family
Planning Our Design
Overhauling is the right word to describe what we did here. If you've ever had a car or bicycle overhauled you know that it's a process of systematically taking something apart to examine it, look for things that need repair, and putting it back together so that it runs as good as new or better. That's what I had in mind for us to do.
I started, as many of us do, doing both top down and bottom up activities to define the problems. The top down was defining the goals and planning the navigation to suit. The bottom up was the nitty gritty of taking inventory of the original site. The goal was to get an idea of what content and services we were providing and see what entry points we provide.
The screen below shows my initial content inventory and a flow chart Peldi did for the new single Buy page.
Before the content inventory, I also started observing the points of pain by talking to customers. I started doing customer support with Balsamiq on day 1. This was and continues to be the biggest factor in helping me understand what we need to improve with the Balsamiq user experience. I learned about what blocked people at the point of purchase, getting software updated, and getting help or requesting features using the product daily.
In the first few months, we handled some of the quick fixes. We had issues with people finding out how to update the software, so we provided a simple link in the app, and a download link in the site header. We did that immediately. The next phase was tackling the bigger usability issues, e.g. providing an information architecture that suited customer needs better, and providing a cleaner purchase experience. We built an outline of a new IA and started mocking up.
Finding Our Story
The next step, and the hardest for me, is finding the right design. Being a design director is perhaps similar to being director of a film. Given a premise and story, you set out to develop the vision for how the story will be portrayed, you gather the actors and crew and creative team, and you provide the schematics for execution. That's a simplified analogy, of course.
All the practical work of serving needs being hashed out, we had to find a way to respect the history and personality of the original site and make it represent the new us, now that we were company of 6 (+2). On our small scale, it meant meeting with the entire company on our retreat and learning what our story was, talking with everyone to develop a concept that depicted that story, and then telling it with this site.
There were things I didn't want to change about the original site because they represented a key element about why I wanted to be a part of this small company. The thing that I found to be pretty awesome about Peldi's design of Balsamiq.com was the voice. You can still see it in the informal screencasts Peldi does. It's like he's actually sitting next to you showing you the software. Some may find the quality of the recording rough, but I like it because it's natural and friendly, and keeping that informal delivery means we can be ourselves and do screencasts more frequently and directly. That's the way we do support--we engage people directly and try to be as approachable as possible. That voice carries through the site, and wanted to be sure that we retained it.
I wanted to focus on this idea of the company as a corner bistro--like a small family restaurant. I was introduced to this idea of the "little Italian restaurant on the web" after reading an interview with Peldi on 37signals. The idea came from David Heinemeier Hansson, who refers to this idea of being the little business you returned to because you know the owners, and you prefer the quality of what they produce. That's what kind of set the tone for how to write the copy to reflect the new us that was still part of the voice that Peldi brought to the site originally.
If I were a journalist, this would be like researching a story and finding and writing the lede. The lede sets the tone for the rest of the article.
I focussed on 2 stories that I wanted to set the tone for the site:
1. The first story is about the company.
Peldi emphasized that we should communicate as much about who we were and what we stood for as it did about the product. I didn't get that immediately, but I see the value in making that a priority. There were a few messages about the company that I wanted to communicate and they're sprinkled throughout. The first bit is sort of a mission. We compete on usability and customer service. We're essentially a small company that cares about what we do, and who we serve.
This lead to the message on the front page, "Balsamiq is a small group of passionate individuals who believe work should be fun and that life is too short for bad software." On the company page we tell the story a little more deeply.
This story also lead to us using customer quotes and testimonials liberally throughout the site. We exist because of our customers--people who want to use our software and work with us to improve it--and we want to acknowledge that the continued success depends on that relationship, and we'll do everything we can to nurture it.
2. The second story is about the product.
The story about Mockups is very simple actually. It's made for frictionless ideation and iteration that everyone can participate in, and the low-fidelity sketch-style wireframes they produce keep you focussed on functionality. There's a secondary story that will be told with myBalsamiq, but the first two points are the main ones to communicate, and we wanted to do that with a few sketch-note style graphics, and to continue to use our simple screencast and web demo. I think this is communicated efficiently on the home page, and slightly more in depth on the product pages, where we preview screenshots and sample deliverables.
Mocking up Screens
The biggest factor in helping us get our ideas out, and selecting and refining them, is that we used myBalsamiq, our web version of Mockups that's in beta, to iterate on wireframes. We created mockups, commented on each version, and Peldi and I iterated in the app.
The screen below shows the Balsamiq.com project in myBalsamiq, with all the versioned artifacts of our planning and design process.
We do iterations fast, we keep the wireframes simple, and get far enough to find the right solution that we agree on. From there I could start working on building the real thing. We only modeled a few pages before going on to design.
One cool thing about using myBalsamiq is that we are also able to figure out which features we need in the app and can work designing those to help our process. One of those ideas, for example is creating mockup revisions based on what came out of comments and finding way to develop a feature around that.
Visual Design
With wireframes in place, it was time to start on visual design. With our IA and priorities in mind, I started sketching some concepts. Those are the sketches you see on the bottom left. Then I reflected on the company retreat we had, I started to get a pretty good idea of what I wanted to convey visually.
The stories above are really what helped me find a concept for the visual design. I don't consider myself a visual designer as much as I do an interface designer, but I think I represented this idea of who we were as a company.
From these sketches I began to explore some visual concepts in Photoshop and created visual design comprehensives. I needed a way to share the visual design comps I was working on so that we could critique and review those and I could continue to refine them with feedback. I used the image component in Mockups to post comps that we reviewed in myBalsamiq.
Below are comps for the home page and company page at different points in our design review.
View full size: Home Page Comp or Company Page Comp
Several iterations later and we had agreement on the visual design concept. I got to work developing the site.
WordPress as a CMS
We decided to use WordPress to settle on a single system to publish both our static content on the main site and our blogs. We really didn't have too much content to migrate on the main site, but what we did have, were a lot of Drupal nodes that needed some cleaner HTML and layout and typography stylesheets that we could evolve over time. We chose to host our own WordPress for the main site, and run our blogs on WP Engine.
For the main site we're creating pages with parent-child relationships to create the navigation. We have some custom PHP in our templates to handle the global and local navigation. We're relying on SuperCache to serve cached content and WP Minify to compress scripts and stylesheets. There aren't major modifications that we made to WordPress, besides using custom fields to handle discrete modules of content and output them into different areas of our templates.
We also use the BluePrint CSS Framework for layout, and TypeKit for rendering headings in Myriad Pro, our house font. We discovered, as many people seem to have, that a bug in pre-iOS 4 Safari (e.g. iPads) crashes that browser when serving multiple font weights and styles. That's one issue I am still looking for a resolution for. TypeKit is awesome, otherwise.
We did need to tune our server a little. We had a nice spike in traffic when Hacker News picked up our relaunch. Luis, with the usual quick response from Slicehost (thanks, guys!) helped get us get configured perfectly for our needs.
WP Engine for WordPress Blogs
Migrating WordPress blogs to WP Engine was a simple decision for us. The guys at WP Engine are awesome, and they had a solution for multi-site WordPress hosting that took the hassle out of us having to keep WP up to date. Takes the worry out of handling traffic and performance issues on our main server, they can serve all of our images from a CDN, and provide support for keeping the blogs up and running, so we can focus on just communicating and working on our product. They even helped us figure out some of the issues we caused with our 301 redirects that were interfering with image rendering. Good stuff.
Testing and Checking Copy
I took most of the existing copy on the old site, and copyedited it to fit with the new combined founder and company voice. I then created some copy in other parts that were consistent with this. Peldi did several rounds of copyediting from there and we iterated on some pages to fit and for voice.
The rest of the company then joined in and started testing the site and began recording issues and providing feedback in PivotalTracker, the agile project management tool we use. Our reviews uncovered parts of pages where the calls to action could be clearer and more visible, so we did a few more iterations on those pages that could be improved. With the pieces in place, we launched.
What's Next?
The last bit of the process has been fixing the problems that inevitably crop up post-launch. There are only small issues to deal with now. The continued reports from our users are helping us find the issues. Thanks, as always, to our awesome customers for helping us out!
That's the somewhat long story of Balsamiq.com's new face. I hope you like this aspect of our site's evolution, and most importantly that you find things easier, and that the user experience is better. There are more improvements on my list that can come later. I'm working on how to improve our onboarding experience with each category of product purchase, and as always, will continue to look for things that we can improve by listening for feedback in the forums. I look forward to hearing how we can make Balsamiq better for you!
Today marks a new chapter in the ongoing evolution of Balsamiq. In the spirit of openness and transparency that you've come to know from the crew at Balsamiq, I'm going to be writing the UX blog to talk about how we do user experience design.
What can you expect?
You can expect to read about topics ranging from specific feature design, to discussing our design philosophy. You can also expect to see me asking you about your experience using the products.
I want to know how you're using Mockups and myBalsamiq. Are we successful at providing an experience that maps to your mental models? Is our purchase, installation or upgrade process not working for you? Maybe part of that discussion is also discovering and introducing each other to new ideas for using Mockups more efficiently or in ways that are unfamiliar, but potentially useful? Any question related to your experience with Balsamiq is fair game.
Sharing our process
I think a big part of this blog will also be about sharing our process with you, being open about how we do design, what we're researching, and discussing the process of vetting and designing features. We're committed to sharing as much as we can, and what I intend to do is put my thoughts and most of my research out here so that you can understand how we're approaching problem solving.
One of the first things I will be working on, for instance, is a new component skin. While some people love our current interface component style, we also hear people asking for elements with slightly cleaner lines that still retain a low fidelity sketch appearance. As I work on this, I'll post my references here so you'll see where I think the design of those components should be headed.
Peldi recently started a discussion on the design of shared component feature, which will let you share grouped masters like page headers, or reusable components like forms. We're essentially asking you as users what you think of the model, and what works and doesn't work for you before it gets released. That's designing in the open, and I think we may see more of that happening.
Communicating the path
Lastly, as I dive into the support queue on Get Satisfaction, I'll try to distill the feature request discussion into a dialogue that relates back to the bigger picture for Balsamiq. It will be helpful for me to get my head around how the product evolves to match the mental models we have for interface design as a varied audience that ranges from developers and ux designers to business analysts.
So that's the plan and enough talk for now. Time to get started.
