Cloudforge brings a suite of open source tools into a cloud based service. Version control, issue tracking, deployment, etc are centralized into a nifty little UI that IT managers can use to setup software development teams. The heart of the Cloudforge monetization scheme is the billing system. There are multiple account types with various costs and features but they all share a single UI/UX when it comes to managing those choices. Let’s examine the business goals, the design process, and the results for this essential piece of a complex application.
The Goals
Help Legacy Users: Remember that this is not a build for a new product. It is a redesign which has a whole set of issues not found when creating an app from scratch. You have hundreds if not thousands of legacy users who are used to the old UI/UX. Regardless if they actually like it or not, the fact remains that they have become accustomed to interacting with a very different paradigm. One of our goals is to make ensure that we carry as many users as possible into the new look and feel smoothly. We don’t want to lose anyone due to confusion or loss of expected features.
Meet Compliance: We can’t just bill Fortune 500 companies and then expect them to keep their own records. Having an easily accessible repository of past invoices is key for many customers. For many of them, an invoice is how they get reimbursed from their employer.
Show Value: There’s a distinct need to communicate not only what the customer is paying for but also how to make the most of their dollar being spent. Therefore it’s imperative that the UI have an easy to understand, motivational, and actionable display of the features that the user is entitled to and using.
Offer Up-Sells: Remember that Collabnet has other services that these users may be interested in. We need to provide a place on the page that offers a path into things like Scrum training without hitting our users over the head with it. These are IT managers and engineers. They don’t mind a good suggestion but they also don’t like being sold to.
Make Payments Convenient: We want to make it easy for someone to give us money… quickly.
Show Authorized Admins: Remember that we’re dealing with everything from a guy in his garage to Fortune 500 corporations to long established educational institutions. The person paying the bill may not be the person who manages the account. It’s very important to show who has access and how.
The Design Process
Initially the product owner came in with a very “waterfall” based approached. We hired an outside firm that came in and met with us several times. They learned as much as they could about our business, went away for weeks, then came back with sets of designs. This went on for months as the team was never fully satisfied with the results. There was always one very crucial understanding about our system, our business, or our customers that was missed. Eventually we brought the entire design in house and made it part of our agile process. Yes!
We decided to approach the designs in the same way we built software features and dove into Lean UX territory. This means that we had clearly defined design goals stated in the daily SCRUM meeting along with team involved design iterations. We got a handful of stakeholders (business, engineering, etc.) in a room and drew a wireframe on the board. We took this wireframe and made a design file that could be iterated upon. This gave us a 1-3 day turn arounds instead of weeks with an outside agency. When the designs come back they were VERY close to final because the team had input throughout the day, even after they were turned in. Any concerns or issues could be addressed in implementation. We didn’t want to hold up engineers for small detail changes in design files.
Along the way I created an adhoc style guide. As we developed buttons, navigation, and other widgets I was either entering those into a searchable Wiki or my own personal documents so I can enter them into a Wiki within the week. Creating living guides like this provides engineers with aesthetic information on their terms. They can reference the guide and ask questions as needed instead of bottle necking.
Once the design was implemented it went through the first round of usability, the team. We all used the feature and made sure that we felt like the goals were being addressed, not necessarily solved, but addressed. Further iterations were assigned and delivered as part of the daily SCRUM. Once we’d reached this point the owner could drop the new feature into second round usability. This could have been other teams in the organization, a BETA testing group, or live users. Whatever they deemed appropriate for the feature.
The Results
The proof is in the pudding. Let’s take a look at where the team’s Lean UX design approach landed by focusing in on a few isolated parts. The thing to remember is that while each part has it’s own set of challenges and decisions, they always tally up to create a single unified presentation known as the application’s “style”.
The summary is broken up into three distinct areas; Quota, Up-Sell, and Status.
Billing Summary: This section lives at the top of the page and contains the most important information as dictated by the goals. The Quota widget displays how many users you have versus how many you can have, how many projects you’re housing versus how many you can house, space… services… etc. We went with iconic representations of services in order to achieve maximum familiarity and perceived value. In the center we have an “up sell” area that presents itself as more of a setting than an advertisement. We used a conspicuous color on the “buy” button to draw the eye without coming off as gaudy. To the far right is the money pane with the essential bottom line, how much. Note the easily accessible “make payment” and “change plan” buttons.
Invoices can be downloaded as PDF files.
Invoices: This is the compliance area but we didn’t want it to come off as a such. I added a bit of the old fashioned ledger look and feel and made sure to use icons. This introduces some fun into a normally mundane experience and lessens any perceived “sticker shock”. We want it to be usable, professional, but not too serious. The user needs to feel good about the money they are spending as much as possible.
A simple widget that is representative of the over all style guide. Simple functionality, plain language, and clear actions.
Delegated Billing: This is a very small widget but it has some big ideas going on. These ideas can be seen throughout the entire Cloudforge application so I feel like it’s a great example.
The “Change Users” button and the view toggle are blatant. We don’t want users to search for action. The view toggle enables small sized organizations to see the large icons, not an empty box. Switching to the list view accommodates larger organizations with numerous entries. We want both to feel at home here. The UI is sticky so these settings stay active the next time this user logs in. It’s a customized UI.
The explanatory text for this feature is in plain site and in plain English. There’s nothing worse than making a great widget or feature that never gets used because users don’t know what it is, much less how to utilize it. In fact, if a feature cannot be explained in two sentences… maybe it should be split into separate features. This not only prevents user confusion, it helps make managing that feature easier on engineers.
I follow many of the same rules for UI/UX that I follow for programming. You don’t want fewer methods with all sorts of functionality crammed into them. You want more methods with concise functionality so you can write effective tests, provide easier debugging, and make it a lot easier for the next person to pick up what you made and understand what’s happening. Designing features is no different. When a feature has too much functionality it becomes a ball of confusion, not only to the user but to the team maintaining it. Make more widgets with distinct functions, clear explanations, and intuitive UI elements.