I was a brand new co-op. My first week on the job, I was asked to peer review a senior developer's code changes. At the time I thought it was crazy - give the new guy some time to ramp up before he can start pointing out others' mistakes... right?

Well here I am, a few years later, a project leader asking new hires to participate in code review from the first week too. In fact, at Macadamian, we've found that one of the best ways to jump start a new team member is to involve him in code review. But wait! Before we send the new guy into the wild, we need to arm him with some essential code review techniques.

Today, we'll look at the 5 essential techniques we recommend to all new team members so they can be fully functional code reviewers from day one.

Ask questions

Many developers believe that the goal of code review is to point out others? mistakes. New developers will often ask "How am I supposed find mistakes in 's code? He's been on the project for 5 years." Unfortunately, this line of thinking is a one-way ticket to ineffective code review.

If you learn anything from this article, it should be this: the primary goal of any code review is to ask questions. Why wasn't that variable initialized? Why does this have to run on a separate thread? Shouldn't the error be displayed to the user? What does this code do?

If there is anything you don't understand, ask about it. Even if you think it?s a silly question. If you don't understand a block of code, maybe it should be better commented, or maybe there's something wrong with it. At best, you'll make the patch author realize he made a mistake or should add a comment. At worst, the patch author will explain the code to you and you'll have a better understanding of what's going on.

Ask for more testing...

At Macadamian, developers are asked to unit-test their own code and give a summary of the tests they performed. As the reviewer, your job is not only to review the author's code changes but also the summary of tests performed. If you think the testing is incomplete, don't hesitate to ask for further testing in other areas, even seeemingly unrelated areas. For example, if a patch changes code to manage fonts in an instant messenger product, it's not enough to verify that message fonts are now fixed. The author should re-test basic sending and receiving of messages, emoticons, message color and font combinations, etc. Unexpected regressions in a product occur because the developer only tested that the bug at hand was fixed. The danger area is actually the surrounding code which may have been adversely affected by the change.

... or test it yourself

Although generally we believe that the author should be the one doing all the testing (keeping him fully accountable for the code's quality), sometimes the best way for a new team member to turn up issues and familiarize himself with the product at the same time is to test the code himself.

In this case, put on your QC hat and approach the product from a new user's perspective (it shouldn't be too hard, you are a new hire after all). Is the feature's behavior intuitive? Are there any visual glitches that catch your eye? Often senior developers are desensitized to illogical work flows and known visual glitches, and they never get fixed. Your fresh eyes are more likely to catch these problems.

Next, try to go out of bounds. For example, if you're reviewing a new blur effect in an image processor, apply the effect a hundred times on a very large image. If that doesn't turn anything up, apply the effect on a 1-pixel image. Has the app crashed yet?

Enforce the rules

If you are a new team member, chances are you were given a presentation of the project's high-level architecture. The UI layer can call directly into the Model layer but not the reverse. Two projects use the same core graphics engine. That sort of thing. You might also have been given a coding standards document.

Sometimes even the most senior developers lose sight of the project's big picture when dealing with code details. Breaking the architecture slightly in order to get a feature done on time can be very tempting. Making a quick fix to project A and project B's shared code but only testing its use in project A is very common. Same with neglecting coding standards.

With the high-level details fresh in your mind, you are in a perfect position to remind developers of the project "rules". Later on, the maintenace team will thank you!

Find your niche

A developer who's been working on the project for years will probably have a firm grasp on the technology he's been working with. It will be hard for a new developer to challenge his code from that perspective. That's when it's time to change perspectives.

For example, it is highly unlikely that a new team member on a VoIP product will be able to find mistakes in a senior developer's use of SIP or RTP. The senior dev probably knows the protocols inside and out.

Time to changes perspectives. If you have some background in security, look for buffer overruns. If you've done Windows programming in the past, verify the code is making the right API calls.

Code can be reviewed from any number of perspectives: code clarity, design, maintainability, speed, efficiency, security, portability, user experience, etc. The list is huge. No developer, senior or otherwise, can be an expert in everything. Pick the ones you like or that your team is missing, and make that your niche.

It is crucial that your new team members understand how to approach code review. It is a collaborative process - asking questions, initiating discussions, uncovering problems, and determining solutions with your peers. Give each new team member a run-down of these ideas. It will instill them with the confidence they need to dig into even the most senior programmer's code. From day one.

Windows Phone is a serious contender: Never mind that Nokia is a force, with strong presence and brand globally. Windows Phone is gathering steam, and will gan market share with Windows 8. Microsoft is strong in enterprise, and over the next year, IT departments will be looking for a way out of managing apps and support for a multitude of devices. They will be looking for common platforms on which to deploy in-house enterprise apps. Because of it's strong installed base of Windows, IT organizations will be drawn to the promise of interoperability between desktop, smartphone, and tablet apps on Windows 8. 

Smart TVs lack compelling use cases: There were an overwhelming number of Smart TVs on display, and other than streaming from services like Netflix, which most Blueray players, gaming consoles, and PVRs already do, Smart TVs lack a compelling use case, and a compelling reason to buy. So far, consumers see it as a "nice to have", but will you really tweet from your TV? And besides, Angry Birds on your TV just isn't the same...

Android tablets - where is the differentiation? Just like last year's CES, I counted dozens upon dozens of tablet manufacturers, and many had at least 2 different form factors. There was no clear differentiation between any of them. Most were using very similar (or exactly the same) hardware, and almost all were running plain-vanilla Android. Aside from price, why would I be compelled to buy a Viewsonic tablet over one from Huawei? The only standout was the Samsung Note, which offers a new form factor a bit bigger than a smartphone, great for portability and note taking. And their launch was brilliant, employing artists to paint portraits of attendees using Samsung Notes.

Design is King: I was really impressed with a few companies that clearly stood out from the pack with great design. One was Belkin, a company previously known for commodity accessories like cell phone chargers. Belkin has been investing heavily in industrial design and User Experience design, and it shows - not only are their products beautiful, but they were showing a number of very useful, compelling products for home security, networking, and energy. 

The Healthcare Democracy - a number of companies like Withings and Zeo are producing personal health devices that are now at consumer-friendly pricepoints. With low-cost sensors, wireless connectivity, and smartphones, personal health monitoring is about to hit mainstream. 

Android will be everywhere - the real story for Android is not in tablets and smartphones, it's in embedding it in cars, appliances, and TVs. As I looked around, I saw hints of Android peeking through everything from in-car navigation to kitchen appliances. With low-cost hardware, it's becoming cheaper and easier to make everything touch, and everything Internet connected.

2012 will be a very interesting year in consumer electronics. We'll see who suffers from innovators dilemma, and who breaks through with well designed tablets, TVs, connected home devices, and personal health devices that stand out from the crowd.

Stay tuned. 

Avoid Functional and Geographical Silos

There are a number of underlying root causes for these problems. Here are a few we frequently encounter:

• Product management works with the design team at Global HQ, then ships the design offshore. Everyone crosses their fingers and hopes the finished product comes back as beautiful as the original design (hint: it won’t!).
• An understaffed design team (in many cases, a single designer) within the organization serves all of the development teams. Naturally, design is swamped. Managers and developers lose faith that design can deliver and, as a result, begin to exclude designers from projects.
• An external design firm creates a design and “throws it over the wall” to your development team, never to be heard from again once engineering begins. Leading product firms like Apple, Google and Facebook are much more integrated, because the silo-ed approach inevitably leads to problems. When a design team is pushed to work in a vacuum, the development team often end up with a bunch of pretty pictures (in their words) and is left to interpret and fill in a lot of blanks. What does clicking this button in the corner do? What happens when the user navigates back? What do we show when the app loses connectivity? How should controls resize and anchor on the screen when you pinch and zoom?

Certainly there are advantages to working in a functional group or having multi-site teams spread out geographically. But being in a separate function or geography is no excuse to work in a vacuum.

Communication Accelerates Your Success

The same product leaders—Apple, Facebook and Google—could afford to use hundred-page style guides and detailed design documents that dictate the interaction and behavior of each and every control. Most organizations, however, don’t have the time or budget to write up such a detailed guide. In our experience, the fastest, most cost-effective and most efficient way to ensure the final design looks as great as the original mockups is to communicate as one team.

Daily, detailed communication can only happen when all design disciplines (research, interaction design and visual design) are included as part of the team— in the daily scrum meetings, in the same project intranet, with the same product manager and project manager, and ideally in the same office.

Communicating daily as a team will:

• Ensure product strategy and design intent are maintained throughout product development. • Prevent the design team from making a blue sky design that the rest of the team doesn’t buy into or can’t build in the desired timeframe.
• Allow the design team to give input on the design and the kinds of interactions that may occur.
• Help developers show designers what the technology platform can do. • Allow designers to quickly explain complex interactions verbally and eliminate the need to spend days drafting diagrams to encapsulate every detail.
• Help designers and developers to better understand each others’ goals, motivations and processes.

This daily communication between all design disciplines allows for a superior design because it delivers a complete experience that leverages the available technology—not simply a static design that looks good in Photoshop.

Teams may be dispersed geographically or by function, but should be encouraged to work together as one team to ensure product success.

• Frequent (daily) communication between all team members ensures each function’s intent is understood and no context is lost.
• Ultimately, the investment in communication ensures less time wasted and a quality product.

This is just one of 5 patterns we've identified for creating great software. To find out more, read our new whitepaper How to get Amazing Software Out the Door Fast on modern software team integration, and how product management, design and development teams are finding new ways to work together to beat the competition.

But starting now, these software systems are in for a big change. From CRMs to ERPs to Content Management, market analysts are predicting seismic shifts in these products as five major trends hit us all.

1. New Solutions Driven by the Demand for SaaS

A recent EbizQ article projects the SaaS market will balloon to $21.3 billion in revenue through 2015.

"Corporations," they say, "are increasingly less concerned with issues such as security, availability and performance that were once viewed as significant stumbling blocks to the growth of SaaS. The growth of industry giant Salesforce.com is a testament to this – the multi-billion dollar corporation holds some of the most critical data a company can have: their customer and prospect data."

Now the race is on for vendors to design and build SaaS versions of their flagship products. Creating a new product means an opportunity to capture new audiences by renewing both design and workflow, while keeping the solution comfortingly familiar for current users. The key to success will be a balancing act between the fresh and the familiar, luring new customers while pleasing your bread-and-butter users.

On top of that challenge, you need a team that knows modern web technology stacks from the inside out to get the product released quickly and efficiently... before your competition does.

On this topic, we highly recommend reading our whitepaper How To Get Amazing Software Out The Door Fast, a collection of modern product management, UI design and software development techniques that form the basis of any major software creation (or re-creation) project.

2. Analytics and Business Intelligence

One of 2012's biggest buzzwords is analytics, ranked as Gartner’s #2 trend in this year’s Top 10. "The volume of information within enterprises continues to grow at an astonishing rate," say Ovum software market analysts, "and investment is needed to both manage this information and turn it into actionable intelligence, through technologies such as business intelligence and analytics".

But analytics could either be the boost your business needs to bring its A game, or a disappointing waste of time and resources. If you want to use analytics to turn an Information Management System into an intelligent Information Management System, you face two challenges:

• Understanding the technology and algorithms available to extract, clean and organize vast masses of data so that only the most relevant, most useful intel bubbles to the top.
• A clear perception of the audience – What types of analytics do the users want to see? How can you present them in the interface so that the user immediately finds what they need to know and can apply it in a way that adds value to their bottom line?

Collecting data for data’s sake and creating analytics for analytics’ sake is just throwing away time and money. Only when you understand the user's core needs and have the technology to extract the most useful data can you give your users what they want, at the right time, in the right format. Anything less is a waste of your resources, too.

3. Context-awareness

Analysts have been discussing context-awareness since mobile exploded in late 2010, but now it's starting to become a real force in the industry. This trend will only get hotter. True context-awareness centers on the user experience. Designers of context-aware features need to take into account:

• The user's state – habits, emotional state, biophysiological conditions.
• The user’s social environment – the presence of others, social interaction, group dynamics.
• The user’s tasks – spontaneous activity, engaged tasks, general goals.

But context-awareness isn't just about understanding how features should work. It’s about technology capabilities integrating different engines, from social networks, to presence and collaboration tools, to leveraging the data and analytics we talked about earlier.

Again, SalesForce.com is recognized as leading the charge with their introduction of new social and collaboration features. In the Healthcare space, Elsevier has been spearheading new initiatives in Clinical Decision Support, developing software that advises a physician on the best course of action given a patient’s context – information like symptoms, allergies and medications.

This is only the beginning. As context-awareness grows, instead of users being smarter about software, software will be smarter about its users.

4. Vertically-focused Software

One of Gartner’s 5 Trends for Enterprise Software predicts, "Vendors who are providing general technologies are moving towards vertically-specialized software, as the number of deployments they do in particular verticals rises."

We couldn't agree more.

This is particularly obvious in the Healthcare and Finance verticals, but this trend will spread in every domain, from Legal to Retail to Manufacturing. For example, look at Enterprise communications vendors Avaya, Cisco and Sprint Nextel, who have traditionally marketed their general purpose solutions to the Healthcare market. Recently, every one of them has released Healthcare-specific software.

As this trend continues, it's critical to have a product manager at the helm of every major market to outline the specific requirements each domain or vertical demands. The team is just as important. Team members, from the designer to the software developers, have to know their domain, from the usability standards mandated in some industries to engineering specifics like data exchange protocols.

5. Enterprise Tablets

Everyone has seen SAP hype its new mobile solutions, but many lower-profile organizations have put Enterprise solutions on tablets with varying degrees of success. After a year of excitement, we're left with two major issues for large Information Management Systems:

HTML5 or Native?

There are pros and cons for each. HTML5 becomes an attractive option as the technology matures, but most large organizations still opt for a native application, particularly for iOS, since analysts project the iPad will keep more than 50% of the tablet market through 2015.

HTML5 promises apps that run on all mobile platforms, and will work just as well on an iPad, Android device or BlackBerry Playbook. Unfortunately, HTML5 is young and still developing – the technology might not quite be ready for all the features you want to build. On the other hand, native APIs have the power... but that means different code for different devices, which costs more to develop.

But what you might not consider is a hybrid approach, and it could be your best option. A hybrid development strategy combines the flexibility of HTML5 with the features of a native app. At Macadamian, we've successfully developed several Enterprise-grade Healthcare applications using cross-mobile frameworks like Sencha (http://www.sencha.com/), and a judicious mix of HTML5 and native code. Doing this lets us create powerful, full-featured apps while saving money for our customers.

Every situation is different, so rather than ending the HTML5-vs-native debate once and for all in this article, we recommend you get the advice of a software expert who has built several mobile applications in your field.

How Can You Successfully “Port” a Complex Enterprise Product to Mobile?

Some of the worst mobile products are straight-up ports from desktop or Enterprise programs. Mobile users might be more hurried, switching cognitive context or just not able to use features the same way as they would with a monitor, mouse and keyboard. Many features either need to be dropped, simplified or adapted for users on the go.

Sometimes a mobile product shouldn't be a port of the flagship software at all, but an extension of the existing product, offering entirely new features that give mobile users what they're looking for.

Understanding the user needs and context for a mobile product, designing for the constraints of a mobile user and device and building it on the right technology platform are not decisions you should take lightly. You need the right mix of design and development skills to successfully carry out the promise of mobile for your users.

We recently covered this topic in some depth in our webinar Porting Complex Software To Mobile Platforms. Check out the recording.

Tracking the Trends

If your plans for the coming year include SaaS, analytics, context-awareness, vertically-focused software or Enterprise tablets, you won't be the first in the Enterprise software revolution.

But with any luck, you’ll get there before your competitors do.

We all remember what it was like supporting Internet Explorer 6, and 7, and 8, all for the same product. It was a nightmare! Weeks of wasted effort, all because what worked in one version of IE didn't work in another.

But we're past that now, aren't we? Every mobile browser supports HTML5 and CSS3. We should be safe with mobile Safari. Right?

Wrong.

Innovation has a Price

Apple overhauled Safari in iOS 5. We're now able to do things that were previously impossible, or at least excruciatingly difficult (I'm looking at you, sticky footer), with ease.

Here are just a handful of the incredible improvements added to Safari in iOS 5:

• Position: fixed;
• Overflow: scroll;
• Improved <input> elements.
• Web workers.

This is fantastic news for mobile web development. Now we can make better web applications, and make them faster than ever before. We can craft new experiences to delight our users, and spend less time in the trenches. This is great!

But what about iOS 4.3 and lower? They have none of this functionality, nor any of the bug fixes that came to Safari in iOS 5.

Is this something you should worry about?

Data analytics firm Chitika measured the adoption of iOS 5 at 38% for all iPhone users, one month after release. That's quite good after only one month of availability, but the majority of users are still running an older version of iOS, which means an older version of Safari.

We have a browser gap on our hands. Users with iOS 5 have a much more capable browser than users with any other version of iOS, and that opens the door to version-specific bugs — events that don't fire in 4.3, views that only seem to work in 5.0, you get the idea.

These bugs are unavoidable. If you're only testing against whatever version of iOS you happen to have on your iPhone, you're going to get burned sooner or later.

The solution is to test your webapp against multiple versions of iOS.

How to Test Multiple Versions of Mobile Safari

It's clear we need to support iOS 5, and at least one older version. How do we manage this on a large project?

In short: Make Apple's iOS Simulator your new best friend.

The simulator provides a simple menu for switching between iOS versions. With only a couple of clicks, you can switch from iOS 5 to any major release since 3.2. This makes it easy to track down, and fix version-specific bugs.

The iOS Simulator isn't just a tool for developers; it's valuable to the entire team. Your QA will be able to properly validate and retest version-specific bugs, your manager(s) will be able to demo the project to stakeholders, and your designers can better suggest tweaks to the visuals and the interactions.

By giving everyone on the project the ability to check how the app looks and feels in multiple iOS versions, you're well on your way towards an app that works properly in whatever version of mobile Safari your user happens to be running.

But there are still some situations where you just can't beat real hardware.

When to Test with Real Devices

Ultimately your users won't be carrying around a simulator in their pocket. Even though the iOS Simulator is very useful, it's important to keep a few devices on-hand for the following reasons:

1. Release testing. You're delivering a mobile web experience designed for a real iOS device, so especially around release time; you have to test using actual hardware. There's always a remote chance a bug will creep in that is somehow invisible to the simulator.
2. Performance. This is a major concern for anything mobile, and it's one area where the simulator generally fails. Your iOS Simulator is probably running on a quad-core machine with more RAM than it knows what to do with. A real device has strict processing and memory limits, so it's important to test with real hardware regularly, to ensure those fancy CSS 3 transforms aren't slowing your app to a crawl.
3. It's fun. Don't discount how novel it is to see your webapp running on a real device. This can help make the project feel more "real", and raise the team's investment in their work. It can boost spirits during crunch time. Apple's hardware is designed to elicit an emotional reaction, and sometimes that's reason enough to take a break from the simulator.

So far we've established that the simulator is great for general testing, but real hardware is necessary for some specific cases. There's one last point to address for browser inconsistencies in mobile Safari:

Shouldn't the Frameworks do this for Me?

In mobile web development, it makes a lot of sense to use a framework like Sencha Touch or jQuery Mobile. One of the things these libraries help with is writing web code that can be ported from one platform to another (like iPhone to Android or desktop). It's a sensible conclusion that these frameworks should handle browser version discrepancies as well.

They do to some extent.

Sencha and jQuery aren't going to put iOS 5-only code into their frameworks. They will do everything they can to make sure their functionality is backward-compatible, or at least ensure it degrades gracefully. But they can't stop you from shooting yourself in the foot.

It's up to you to make sure your app works in the browsers your users are equipped with. Don't rely on a framework to do this for you. Figure out which versions of iOS you want to support, then test all of them using the iOS Simulator and real devices.

Of course, the main interest of the kids is technology and actual coding but, as part of the mentoring, we're also helping them with some of the things that surround development. For example, we set them up on GitHub and taught them the basics of source control.

Yesterday, I had the privilege of meeting them for the first time and, as one of those non-coding activities, we ran a bit of a design workshop where we spent time on the whiteboard wireframing the UI for a particular user story for their application. 

It was really cool to break down the specific story into the various bits and to sketch a UI with them. We got them to get their first ideas on the board, and then challenged their design using the personas they had defined in previous weeks. By asking questions like "Would Tony really know what to pick here?" they were able to break down their assumptions (which were based on the physical model of the data) and redesign a UI which was more respectful of the user's mental model and their context of use.

At one point during the session, one of the kids turned to me and asked: "Do you really do this on projects?". I must have had this stupid grin on my face when I answered "yes". The voice in the back of my head was saying: "Can you believe that I get paid to do this?".

By the end of the session, we had a complete workflow documented that they will be able to go out and code this week. And the kids had a glimpse of one of the non-coding parts of what turns a piece of software into a product.

I'm really excited to see how it turns out.

To start, and well worth the read, check out this great article from fastcodesign on what businesses should be striving for -”What Good Does Design Do For Business?”. In short, businesses need to strive for a design mix in their activities made up of the following elements: collaboration, innovation, differentiation, simplification, and customer experience.

To achieve the design mix, what does one have to do?

It starts with the users. The most common thing I hear is "we know what our users want". This is rarely true. While we may know what our users are asking for (their want), we rarely understand what it means in the context of usage and if it’s valid in the context of usage. A want is something a user will ask for; a need is something a user may or may not consciously be aware of. To understand the needs behind the want is where user research becomes handy.

User research has two main aspects: identification of the various user populations or personas and rigorous observation. Segmenting the user population into personas allows for focus in the design mix. It keeps your team from designing for everyone and anyone and focuses them on a few categories. Rigorous observation is framing user interviews in a way that they will be experiential. Observing the user in the environment of usage, however light the prototype is, brings solid data forward so that we can understand the user needs better.

You also need an iterative mindset and mixed team. In software, this is both the design crew and the software crew working together to address the user needs. They work iteratively together because the process has a constant influx of user feedback. It’s difficult to get collaboration between these two groups. The main idea to overcome is that engineers don’t think like designers and designers don't think like engineers AND this is the strength of the team. Engineers think from the code out to the user. Designers think from the user standpoint irrelevant of the technology difficulties. What this team strives for is:

• Design informed by technology
• Technology informed by design

Achieving the design mix is great for business. It leads to greater results earlier on because it's about asking the right questions early in the process and it's about constantly validating the progress against the business goals AND the user models. It provides an opportunity to get the things that matter for the market in this version not the next one. Ultimately though it's all about the user and this is why it's good for business to put users at the centre!

So stop laughing. Even if I’m hair challenged I still need to cut my hair or get the clippers going regularly. I was getting ready for an important meeting and I needed a good beard and head clipping. I was traveling so I couldn’t go to my usual place. I found this hip place - bloody pricy but it was hip and I like to think I’m a hip guy!

The salon décor was just fantastic and the place looked great. It’s a happening place - kind of a club with a DJ spinning techno music with a good beat. While you wait there is an espresso bar and Lindt chocolate for all guests. It makes the wait easy on people; the chocolate puts you in a happy place. When your turn comes up, someone comes up and introduces himself/herself and is very professional and casual at the same time. Off you go on the chair. Then after they are done, it’s rinse time and sublime head massage. Last but not least you’re escorted to the door and waved goodbye!

As you can see they have thought of everything and they went all out to create a memorable experience. So where is the beef you think? For those who know me, messing up my hair cut is impossible. It’s clipper at 0 and head and beard. I see the tiny whiny clipper coming out and I think this is going to be interesting. Well you see, that clipper was not the right tool and I ended up with a beard that wasn’t clipped equally all around. It was not enough to look bad, but just enough for me to notice too late after I was gone.

The side show going on in this hair salon made a promise that I was in a place where they had the whole process and activity buttoned up. In the end though, the very first thing that made them was not up to par. An experience is total and satisfying if the core service and product are working as promised. You can serve me the best espresso in the world but I’m in a hair salon and all I want really is a good hair cut. My take away – I can put as much money and effort in putting on a great show to create a great experience but if the basic product I sell is not top quality itself it doesn’t matter. It’s something to remember every day in my activities.

Change one thing at a time
There's a popular business mantra that says "you can't manage what you can't measure". I also believe that to measure change, you can't change everything at once.

As a growing, maturing company, we're always tweaking, and always looking for things to improve. Lately though, I've found it increasingly more difficult to apply past metrics to our current situations because we're changing so many things at the same time.

In racing, we only change one thing at a time, and test its effect. You change your sway bar settings on one end of the car, and you test. You adjust your shock absorber rebound, and you test. If you were to change all these things at once, and you spun out in turn one, you'd have no idea what caused it, and lose precious hours going back to square one.

The same is true whether you are changing a business system, or changing an attribute of your product or web site. If you change your sign-up process, your home-page, and your PPC tactics all at the same time, you'll never know which one had the greatest return.

It takes a village
Even at the amateur level, successful racers have coaches, mechanics, and timers who are often paid in nothing other than free beer and BBQ. At the professional level, teams spend an enormous amount of time learning to work together in perfect harmony. They realize that everything, from the pit crew who refuel the car in seconds, to the suspension engineer who knows exactly how to set up a shock absorber for a specific track, have to come together flawlessly to win a race.

Here's a newsflash for budding entrepreneurs - sometimes you're wrong. The good news is there is probably someone, somewhere who has been through exactly what you’re going through who is willing to help. In my career I've been lucky to have a few people who were willing to sit down and talk through a business challenge for nothing more than a latte and the promise to pay it forward.

Successful management teams are staffed with people who compliment one another's strengths, and who think differently from one another - some big picture thinkers, some detail-oriented; some who are engineers and some who have arts backgrounds. Believe me, it's not easy - you'll disagree constantly, but in the end you'll make better decisions because they've been dissected from every angle.

The really successful teams invest time and money learning how to communicate better and work better as teams. They set aside personal ambition and break down silos to achieve a shared vision. Like a championship race team, great business teams are built with trust, shared respect, and communication.

If everything feels under control, you're not going fast enough

World champions drive their cars at the very edge of control. A little more steering input, or a fraction more throttle, and they would go careening off into the weeds. It's a strange sensation, to feel almost completely out of control, but at the same time, completely in control. The flip side of that coin is once and a while, you will spin out (ask me how I know).

If you're an auto racing fan, you've witnessed the two extremes - on one hand are the wildly aggressive drivers who lead one race by a half a lap, but crash in the next. They burn their teams out and burn their bridges. On the other hand are the backmarkers who are unwilling to be as aggressive as the winners. Champions find that perfect balance - they are blisteringly fast, take calculated risks, but are patient and persistent, tracking their opponents lap after lap, waiting for them to slip up so they can take the pass for the lead.

In business, I've seen companies who are unwilling to take risks, and unwilling to live on that edge of controlled chaos, and they usually plateau. I've also worked with companies that are in constant chaos, where the leadership team leaves burning bridges, burned out employees, and fried customers in their wake. The perfect flow is right down the middle - taking calculated risks, moving quickly, and working right in that zone where things feel a little out of control.

You'll never have all the data and all the answers - a napkin-sketch plan passionately executed will beat a perfect plan poorly executed every single time.

And remember, if you're still stuck on your hockey and football analogies - as Hemingway (or Ken Purdy, or Banarby Conrad, depending on who you ask) once said “There are only three sports: bullfighting, motor racing, and mountaineering; all the rest are merely games."

----------

If you’re looking to build an unbeatable product team so you can create better software, check out the white paper How to get Amazing Software Out the Door Fast.

(and not football, hockey, golf, or baseball.)

A couple months ago, we celebrated our 15th year in business. What a ride it's been. I've been at Macadamian for 14 of those years, and our anniversary has made me reflect on what I've learned working at a company that started with 4 people, has grown to 170, and now works with companies worldwide to help build better software products.

I set out to summarize my lessons in a series of analogies. I love analogies, but for years I've listened to my colleagues in Canada relate every business lesson to a hockey analogy. Everything will work out fine if we just "skate where the puck is". I do enjoy hockey, but I barely know the difference between offside and icing let alone who won the Stanley Cup in '72. So half of the time the analogy is completely lost on me.

In an effort to bridge the communication gap, I've related my learnings in business to one of my passions - auto racing. I hope this helps other business-minded gear-heads communicate more fluently with their peers, and if nothing else, I've laid the foundation for you to take your team to the Skip Barber racing school for "team-building".

Look to where you want to go

One of the deadliest errors, often made by beginners on the racetrack, but occasionally by experts, is called "Target Fixation". In a moment of high stress, your brain is so overloaded that it becomes fixated on exactly what you are trying to avoid - gravel in a corner, an obstacle, or another car. And you end up hitting it square on.

In business, it's very easy to get fixated on what you don't want - losing a key customer, a market downturn, your best performer leaving. More often than not, you run straight into what you were trying to avoid. It almost happened to us in the so-called "Great Recession". Around mid-2010, our pipeline was drying up, and in a somber management meeting, we told ourselves "I guess we'd better start planning to downsize". Luckily, one of our mentors, Joe Connelly, snapped us out of it. Joe wouldn't let us even mention downsizing until we had exhausted every possible option for filling up our project pipeline and hitting our revenue targets. It was every man on deck. He refocused us on the positive outcome, and guess what? We turned it around and headed straight into our best year in history.

To be a great auto racer, you need to have "wide eyes" - to learn to look far ahead, use every corner of your peripheral vision, and look where you want to go. Being a leader is no different - your job is to look further than tomorrow, get a lot of advice and input, and keep your team focused on where your business is headed.

It's a mental game

I recently had a very humbling experience at the race track. I thought I had wrung every last bit of performance out of my car and was driving to my absolute abilities. The car was set up perfectly, I had been slowly knocking 10nths of a second of my lap-time, and I was hitting a plateau. Then I had an idea. I invited a very fast, very experienced driver to drive me around the track in my car. After a warm-up, he did three blistering hot laps around Willow Springs, a full 3.5 seconds faster than I. We returned to the pits, reviewed the session, and he sent me on my way. The very next lap, I was 2 seconds faster, and the next 5 laps I was consistently 2.5 seconds faster than my previous laps (I'm still chasing that last second, and that's what makes racing so fun). It wasn't the car, or even my abilities that was slowing me down - it was my mental model of what was possible. Success in business has a lot to do with your mental attitude. Studies have found strong correlations between entrepreneurs with positive outlooks and business success. Most of the time, it's not your competition or the economy that's holding you back, it's your own attitude and beliefs. Those that have an attitude of abundance generally outperform those who believe the glass is half-empty.

Persevere!

In racing, no matter how practiced and prepared you are, you can suffer dramatic setbacks. Parts break, someone bumps you, or for whatever reason, your perfect setup just isn't working on a particular track like you thought it would. Even world-championship teams have bad weekends, and the best drivers have persevered through them. They learn, they adjust, and they go try again.

The business press loves the "overnight success story". What they fail to mention is that behind almost every business success is years of blood, sweat, and tears. Yes, one day they break through, but often these overnight success stories have been at it 10, 20, or even 30 years before they became a household name. Every business had failed starts, bad sales calls, unproductive employees - you name it. Things that are completely out of your control hit you from left field. The only thing you can do is dust yourself off and keep going. So much of success in business is just showing up and trying. If you're self-aware and inquisitive, you'll learn with every setback, and one day you'll wake up amazed at the progress you've made.

Read Part 2 of this series! If you’re looking to build an unbeatable product team so you can create better software, check out the white paper How to get Amazing Software Out the Door Fast.

Now that I've been using mine for a week, I'm struck by three distinct thoughts:

• I had no idea I got so little quality sleep,
• the folks at Jawbone are design rock stars,

this is just the beginning. Tracking your personal health, and sleeping a little better

The idea behind the Jawbone is that tracking your sleep, activity, and meals encourages you to sleep more, move more, and eat more fruits and veggies. Add in the notion of Challenges, where you sign up to participate in things like the 100,000 Steps in 10 Days challenge, and you’ll be more motivated and more aware of your personal health. I believe it. I'm already pretty active, but in the week that I've had my UP, I've made a number of small changes like walking to the office more, or making oatmeal in the morning instead of having Honey Nut Cheerios. It's a bit silly when you think about it, but it works. Jawbone also gives you the option of creating teams and sharing your activities. I believe that as the community grows, it will be the social element of supporting and challenging your friends and family that will make the biggest impact in improving people's health.

Jawbone Rocks at Design

The team at Jawbone definitely share the Apple ethos of design - make a beautiful, compelling, desirable product by employing minimalism, attention to detail, and a focus on aesthetic. The UP itself is a genius bit of packaging - a spring steel frame wrapped in a hypoallergenic rubber that gives the UP a light yet durable feel. The spring pattern reinforces the notion that you can bend and stretch it to fit around your wrist and the whole thing is light enough that you hardly notice that it's there. The band connects to your iPhone through the headphone jack. Sync'ing can be finicky at first (tip - your headphone volume needs to be at max), but once you've done it once, it's second nature. 

The app itself does a great job of visually representing your sleep and activity data in a clear and simple way. The main screen shows you your progress towards your overall sleep, eating, and activity goals for the day, and rotating your iPhone sideways gives you a detailed breakdown of your sleep patterns and activity levels. The first time you use it to track your sleep, you'll be hooked - you see when you sleep deeply, lightly, and how often you were awake. Jawbone has made the process of tracking your health simple, fun, and interesting.

It's only the beginning

There are a bunch of things missing, and it's clear that Jawbone also follows the Apple philosophy of getting the core features perfect rather than stuffing the product full of half-baked gimmicks. Using the UP for a week, I'm hungry for more, and I have no doubt that some of these ideas are in the works - better connectivity to social media to make it easier for me to discover friends who own an UP and share my activity on Facebook; a simpler way of tracking workouts other than walking (currently you can use the iPhone app to track your bike ride via GPS, but it's clearly a workaround). It boggles the mind to think where we're going to be two years from now.

Hats off to the Jawbone team for releasing a truly innovative product. How many companies do you know who have such a solid brand and market share in one category (Bluetooth headsets) do such a good job at using their technology and know-how to release a compelling product in a completely different segment like mHealth? I can't wait to see what's next!

Looking for advice on how to create better healthcare product? Read the whitepaper: Creating Successful Healthcare Software: 10 Critical Lessons

The voice of the article is an MD who enlightens readers on some of his and his colleagues’ complaints with EHR systems.

One of my favorite statements he makes is that: physicians are open to new technologies. As consultants trying to improve the user experience of vendors' EHR systems, we often come up against unfounded beliefs that physicians are uncomfortable with technology. We know the opposite to be true. In fact, there is also evidence of this with other clinicians who embrace new technologies all the time.  Examples of some of these technologies include: CT scanners, robotic surgery devices, ambulatory EEGs, and now smartphones. 

So why have we seen examples of slow, frustrating adoption of EHRs?  There are a number of reasons for this but the author nicely states: “…because we didn’t like them.  They weren’t market ready.” In our experience, physicians don’t “like them” because they don’t meet their needs and are difficult to use. In 2009, the HIMSS EHR Usability Task Force conducted a survey of clinical users to identify user "pain points" that contribute to difficulties in using an EHR. The report identified workflow as the overwhelming problem in almost all facets of EHR usage.

Hearing this type of feedback from an end user truly helps build the business case for multidisciplinary teams of which it is key to have user experience professionals involved.  At Macadamian, we use this approach to aid in the development of EHRs. Our work has taken us through the development process for multiple platforms and devices and because of our approach, the technologies have had positive reviews from their clinical end users. 

What does all of this mean for us?  If new technologies, such as the marriage of EHRs on hand-held devices like iPads, give clinicians what they actually want and can use, we can worry less about the technologies’ adoption rates.  If new technologies help clinicians work faster and more effectively, thereby improving their workflow, we have proof from the horse’s mouth that there will indeed be early adopters.

Article reference: www.healthcareitnews.com/news/5-points-view-ehr-end-user

HIMSS reference: www.himss.org/asp/ContentRedirector.asp

Part 1 of this series reviewed some of the most common reasons why the needs of the user can take a back seat to other, stronger influences and began to describe how a consensus was formed on some of the truths about a patient's needs in tracking their own healthcare:

• The patient has a different perspective.
• The patient speaks a different language.
• The patient has different needs.

So, how can we address these patient needs?

What if patients walked out of a clinic with a summary of what happened, captured in a language they can understand?

What if a patient had clear directions on:

• what the clinician was doing next?
• what he/she (the patient) was expected to do next?
• what the goals were for the coming weeks, months, years?

What if patients played a role in defining these goals?

What if patients could inform their healthcare providers of major life events (loss of a spouse, birth of a grandchild, plans for a once-in-a-lifetime vacation) that might impact the schedule or course of treatment planned?

What if patients had a central place to keep track of ways they are contributing to their own healthcare? (ex. Exercise, alternative treatments, uploading blood sugar readings, etc.)

What if patients with multiple healthcare providers had some way to see, at a glance their entire care team, and feel confident that they are communicating with one another to optimize their care, and nothing will fall through the cracks?

What if the patient’s care revolved around…. the patient?

These are just some of the opportunities for improvement we discussed. And we imagined them as anything from a printed document (with a few lines where patients can add their notes) to an iPad app with patient-facing and provider-facing interfaces. And we realized that we had barely scratched the surface of the work to be done, and the issues to be considered. (Who ‘owns’ the data? Will healthcare providers trust content entered by patients? How does it all stay synchronized in one central place? Will the patients actually even adopt these technologies, and enter their data?)

We’ve all returned to our own lives, jobs, and projects, aware that there is one more rather important stakeholder to consider when creating applications for the healthcare industry. The patient.

And maybe, some of the solutions which will make these medical records more patient-friendly, will in turn make the healthcare provider’s experience better too?

We all know this experiment would fool people until the ball is snapped on the first play from scrimmage; and then we’d have to do a body count.

No one would expect a team that just looks like the Packers to play like the Packers. But companies try this when they are designing products all the time. They look at the iPhone or some other product they want to emulate, decide they’ll make their product look as much like this as possible and are surprised when, on product release, they are sacked 20 yards behind the line of scrimmage.

The point about the Packers and products are the same. 90% of the value of the experience comes in how they work, not how they look.  Steve Jobs would emphasize this point all the time at Apple. Of course, it’s not that how it looks isn't important. It absolutely is. It’s just not nearly enough. 

This myth that some companies have that the essence of a fantastic experience and product success comes from how it looks is costing them. The importance of looks may hold true for a second or two. And it might be a very important second or two in purchasing decisions. However, if you are looking to have your product be endorsed by the market, you better spend time on much more than how its looks. Especially in a world where there are so many ways for product information and assessments to travel quickly. If someone actually ran that experiment with the Packers, the whole world would know in a matter of minutes.

A product that looks good, but doesn't deliver, faces the same challenge; rapid spread of its failure to deliver the experience promised by how good it looked.  In upcoming posts we'll discuss the three things that companies fail to spend time on in designing great experiences that are costing them possible success in the market.

Remember, anyone can be an armchair quarterback, but to drop back and thread a pass through a zone defence while 280 pound giants are bearing down on you requires more than just looking good in your uniform. Never make the mistake that what a product looks like is the same as what a product experience actually is. 

For more information on this topic, download our whitepaper: How to Get Amazing Software Out the Door Fast

Sometimes, it’s not about the user.

Scandalous! I know. Okay, maybe not that scandalous. We’re all familiar with the challenges of designing a product where the user’s needs take a backseat to some other strong influence.

• Designing for the approval of a client who is not the user (i.e., most projects)
• Designing for multiple, drastically distinct user groups (e.g., an ATM interface)
• Designing products where the (many) end users’ needs get trumped by one or two super-user’s or admin’s needs (e.g., our timesheet software, which will remain unnamed)
• But what about addressing the needs of the subject?

But what about addressing the needs of the subject?

Take healthcare applications, for example.

There’s been a tremendous amount of attention in recent years given to making Electronic Health Records (EHRs) more user-friendly. And who can argue with that? Supporting the needs and tasks of a healthcare provider improves not only their efficiency, but their ability to effectively care for a patient. And improving patient safety is something we can all agree on.

But, what if the EHR could better meet the needs of the patient?

A few weeks ago, I had the opportunity to attend a workshop focused on creating a patient-centred facet of an EHR (Patient Health Record, or PHR), hosted by IDEO and organized by CHCF. A group of 20 or so vendors, healthcare providers, UX designers, and other professionals who have been working in the healthcare IT industry came together for 1.5 days to look at making these applications more patient-centric.

IDEO did some exploratory research prior to the workshop with patients that have a range of medical conditions, and with varying levels of involvement in their medical care. The results were unanimous – patients felt excluded from their healthcare. Some accepted that as ‘the way things are’, while others went to great lengths to document their care, desperate to feel informed, involved, and in control.

We had our work cut out for us.

While I wish I could say we walked away 1.5 days later with perfect solutions, ready to implement, I’d be lying. We did a lot of brainstorming, scribbling ideas on Post-Its, and came to a consensus on some (rather obvious - now that we look at them) truths about a patient’s needs in the tracking of their own healthcare.

The patient has a different perspective.

Currently, EHRs focus on medical history. (Makes sense - it is a RECORD after all.) But this is not particularly important to a patient – they already know this. They were there when it happened. They don’t need it recited back to them. Their focus is on the future of their health and treatment… which is the total opposite of how most EHRs are structured – which is to bring a healthcare provider up to speed on a patient’s medical history.

On the other hand, the patient doesn’t have the medical experience to interpret most of the readings and results that are captured in an EHR. Sure, they can see when a reading is ‘abnormal’. But, are we talking ‘borderline’ high? Or ‘through the roof’? And maybe an ‘out of range’ reading is actually normal for a particular patient?

The patient speaks a different language.

Lower back pain is lower back pain. Not Dx code ICD-9-CM:724.2.
Aspirin is Aspirin. Not acetylsalicylic acid.
A cold is a cold. Not an upper respiratory infection.
Etc…

The patient has different needs.

A patient wants to know what to do, what to expect, and what to strive for.

The course of treatment for a given diagnosis might be completely standard/familiar to an experienced doctor, but for most patients it’s completely new, unfamiliar, and often frightening. While a few test results might tell a healthcare provider everything he needs to proceed with treating a condition, those same test results lead to an endless list of questions, concerns, and fears in a patient.

Patients want to feel in control of their health, especially when they’re not. They want to know how they can contribute to their own well-being.

Next week, Part 2 of this series uncovers how these patient needs are addressed.

One of the first questions we ask every new client is simply “Who’s in charge of your software design?” The most common answers are instantly revealing:

“Our software architect also designs of UI”

Most major universities now offer 3-4 year bachelor’s and graduate-level programs in Human-Computer Interaction (HCI) or Interaction Design—disciplines that have almost no crossover with a Computer Science degree. Unless your software architect has had formal training, it is unlikely he or she will have the formal UX background required to create a usable, intuitive UI. Moreover, architects are an extremely valuable resource—their time should not be split owning the user interface as well as the system architecture.

“We have a designer who takes care of it.”
Most often when we probe more into this answer, we find out that what they really have is a graphic designer, who is in charge of making their product “look good”. Great graphic designers (also known as visual designers) are essential. Good ones know how to present visual information in a way your users immediately “get”. They help make the potentially confounding analytics graphs in your product easy to understand. They design icons that help your users instinctively understand what to do. But there is a lot more to creating a design users love than visual look and feel.

It Takes Three
There are, in fact, three disciplines involved in creating a great design that are as different from one another as marketing, sales and engineering.

1. Design Research. Design researchers specialize in uncovering user needs. They train for years to learn how to interview and observe users. Their findings almost always yield incredible insights that can be used to determine the exact point in the workflow where users are abandoning your e-commerce website or even help you uncover the next big innovation in your product line.
2. Interaction Design. Interaction designers are the masters of intuitive layouts, workflows and content prioritization. They work with product management and design researchers to obtain market and user research and translate it into a draft of what the product will look like, how it will behave, and how it ties back to the user’s goals—usually in the form of sketches called “wireframes”. 
3. Visual Design. Visual designers are graphical experts that specializing in tools like Photoshop and Illustrator to add the right visual “wow” to software. Good visual designers can provide users with an instant emotional connection to a product even before they start using it. Each discipline is so different from the other that companies are best served with even part-time help from a specialist in each area rather than one full-time jack of all trades.

Product Managers and Design Researchers— Partners in Strategy
Sometimes a great product strategy might not even make it to market if it is first intercepted by internal executives with their own perceptions and biases. When a product manager and design researcher form a strong partnership, they can make sure they get the organization’s buy-in by focusing on the facts rather than opinions and speculation. The “facts” are a combination of user data and market data.

Market data is crucial information about customer demographics, perceptions, market demand and market opportunities. User data provides specific and actionable information on your particular end user (who may be different from the person actually purchasing the product). This information offers insight into what customers and users actually need—not just what they say they want or what the company thinks they want.

What works best is when a product manager and design researcher co-present the user and market data to all internal stakeholders along with the plan for product design and rollout, using storyboards, narratives, charts, and concept designs.

Once you have the right design competencies in place, it is equally critical to follow correct process within the software team. To find out more, read our new whitepaper How to get Amazing Software Out the Door Fast on modern software team integration, and how product managment, design and development teams are finding new ways to work together to beat the competition.

Sentiment analysis of the Twitter stream seems to have great potential. After all if you look at Deb Roy’s presentation at Web 2.0 Summit, you can quickly make sense of major trends if you zoom out of the Twitter stream to look more at the whole flow of conversations.

So Deb is explaining there is great opportunity for companies in filtering the Twitter stream against a structured data layer. So in case above, the structured layer is the TV grid and parsing the Twitter stream through it leads to some very interesting and new information.

From where I sit I compare Twitter messages to tcp/ip packets. They don’t make much sense on their own, but when all assembled they mean something. It’s just way too much information to process at the packet level. The business opportunity with Twitter is in connecting the dots between the packets.

Then a truly eye opening high order bit is done by Brad Rencher at Adobe. Brad goes on to talk about Vail resorts , a ski resort, and how it found a clear line of sight to the business impact of data. The lift tickets come with an RFID chip embedded. This allows for the uploading of ski data as a skier is doing runs and it has gamification to share performance and award badges. It changes how the skiers engage with Vail and how Vail engages with its customers.

In both presentations we clearly get that data is very important for good business. The power of data is in making more decisions faster, it's in more insight and in better decision making. The data power is also how it allows customers to engage with a brand and how a brand engages with customers to drive business impact to the bottom line.

Embrace your data fumes means:

If someone says "customer engagement" I equate this to the requirement to have great experience throughout the services I provide or products I sell. My point is you can't have engagement without intentional design of the experience itself. So if you are thinking about embracing your data fumes to drive more business impact, first and foremost carefully design the experience so that it is authentic for your users because, as Brad says 'You can't buy friends'

UC solutions such as Microsoft OCS, Cisco HealthPresence, Avaya and Telus - Community Health Care can help organizations fully integrate EMRs into their clinical workflows. An open source UC solution, Asterisk, is also quite popular.

What are the opportunities for innovation?

The component technologies of unified communications are of benefit to EMRs by facilitating professional-to-professional, professional-to-patient and patient-to-professional contact in order to create a much more fluid environment. With such technologies deployed, the EMR would become a meeting place where there would be:

• Recording of physician and patient consultations. These can be added to EMRs for patient playback in case something was missed.
• Virtual waiting rooms. Patients can queue remotely and wait in the comfort of their home, coming to the clinic only when the office is ready for them. The patients would be able to perform this action through the patient portal component of the EMR.
• Virtual consultations. Video conferencing would allow patients to visit physicians without having to actually come into the office.
• Supervised tests. Currently, with EMRs like GE Centricity, physicians can supervise tests via remote monitoring diagnostic systems. With integrated UC, they would be able to monitor both the computer terminal as well as the video from the examination room.
• Telehealth with video conferencing. At present, Telehealth solutions require users to call an expert by telephone. With the functionality of UC, video conferencing would be possible – giving the expert on call the ability to see symptoms and give more accurate advice.

By incorporating UC into your offerings, your organization could add a great deal of value to a hospital’s EMR since it would bind all communication services into one package.

How is UC applied in healthcare today?

Cisco and Allscripts have formed a partnership to integrate UC with their EMR solution, offering solutions like patient reminders, messaging, and intelligent call routing. GE Healthcare piloted Microsoft’s UC solution with fanfare, but these two software solutions currently operate independently.

What constraints does the technology face?

In addition to the general high cost of teleconferencing and videoconferencing hardware, integrating UC into the EMR poses the following limitations:

• Larger installation. An EMR is already a daunting task for a healthcare facility. Grouping a UC solution with that of an EMR would require an even larger overhaul of existing infrastructure. It may be better to install them separately with adapters in the EMR to allow for integration.
• Loss of personal contact. There is a strong value to face-to-face meetings in healthcare. It may be some time before the quality of low-cost virtual meetings is sufficient to inspire trust in workers and patients.

Despite these constraints, vendors are starting to explore how to best leverage current technology and innovate. EMR/UC integration is still at an early stage, however, which offers your organization the opportunity to be one of the first to truly utilize and promote unified communications in the healthcare industry.

EHR Usability Workshop

To help vendors understand and proactively address the NIST EHR usability criteria, Macadamian is now offering a Meaningful Use Usability Workshop for developers of EMR solutions that focuses on the use error criteria established by NIST to improve patient safety. In this interactive workshop with key members of your product development team, Macadamian’s usability research experts will help you develop a formal usability assessment plan. Working together, you will explore and establish the key components of a usability action plan. These include:

• A Usability Strategy: Macadamian will help you to develop a business case and concrete plan of action to meet the NIST requirements with a view of upcoming meaningful use requirements. We will walk you through the 7 key criteria of the EUP [EHR Usability Protocol] and their implications for your product[s]. We will work with you to select and adapt the appropriate usage scenarios/workflows provided by NIST for your clinical users.  

• Patient Safety Goals and Benchmarks: Following software usability best practices, Macadamian will help you to uncover the specific usability goals that will underpin your products’ differentiation. Employing the 8 Use Error categories defined by NIST we will describe how to set and attain achievable targets for usability. These goals will lay the foundation for the benchmarking and tracking of your product’s current usability status and future usability improvements.

• Action Plan and Timelines: Macadamian will help your team determine next steps and progression timeline.

  Register Today Our one-day EHR Usability Workshops are offered at our new Silicon Valley lab, or can be held on-site at your facility. For more information and to register for a custom workshop, please contact:

Didier Thizy
Director, Healthcare Division
613-739-5976 x136
didier@macadamian.com