Designing for everyone

At the last Communitech usability peer-to-peer meeting, Adam Baker, UI Designer at Google, took us through an interesting exercise. Working in teams of four, we had to design the user interface for an application used to order pizza. Each team was given a constraint to work with. My team's constraint was that our user has an old blackberry and is travelling home from work, on a train.

All my team members had had sufficient time to introduce ourselves to each other, and we did not find it very hard to communicate our ideas, to talk about our design decisions and come to a compromise where needed. Our design met the simplicity criteria and consisted of one screen that asked for input for the telephone number, the delivery address and the delivery time. We considered using one screen per input to accommodate the small screen size, but settled on the one-screen design for ease of readability and navigation.

At the end of the eight minutes allotted for the exercise, we were asked to merge with another team and to re-design to accommodate the second set of constraints. The new constraint we had to deal with was that our user is blind. To adapt to this new constraint, we adopted the merging team’s idea of a voice-enabled application that tried to automatically get all the input from information already stored on the blackberry, and then repeated all this information to ask for a verbal confirmation. Since we were also working with an old blackberry, we designed the application to simply dial the phone number of the pizza store and to let the computer system at the store handle the voice input processing. We also switched to our original design consideration of one screen per input to simplify voice processing.

Our merge flustered us a little bit initially, but we thought the new constraint did not change the user interface design enough to cause us much concern. However, we were asked to merge yet again. This time, we moved from eight team members to sixteen, and we took on two more constraints; the first was that we were dealing with a first-time online user, and the second constraint was that the user had only two minutes to order the pizza.

The last merge was more challenging, particularly because the team size was too large to be able to gather and ponder over every person’s input, and because we had the least amount of time to make design changes. We were faced with numerous questions; are we mandated to use an online application, instead of an installed application? How will a voice-enabled system be able to verify all the input within two minutes? If the application is dependent on a phone connection, and the user is travelling on a train, what will happen if the train goes through a tunnel and the connection is lost? Our blind user will be caught unawares in this situation. How will the application recover from this and will the user have to start all over?

We did not have enough time to answer these questions in a satisfactory manner. There were, however, many lessons to learn.

1. The exercise tries to simulate what it is like to design for an extremely large audience, all with different constraints.
2. The larger the design team, the harder it is to come up with a simple solution.
3. Different design teams bring different perspectives into the design process.
4. One solution is not necessarily correct.
5. The more constraints there are, the more complex the interface becomes, and it risks becoming inconsistent.*
   
   

Here are some general guidelines and retrospectives that Adam shared with us:

1. Understanding your users requires creativity. You have to be able to differentiate between different users and recognise common patterns in order to group your users. Instrumentation and A/B Testing are two techniques commonly used to recognise usage patterns. We can measure by answering questions such as how long, how many, how often and when.
2. Designing Google’s Search UI was like designing for the back-country, where everything must be light-weight, multi-purpose, fast and adaptable.
3. Little things matter. Simply changing the shade of a line colour can make a large difference in the user’s satisfaction.
4. Intent is ambiguous. What does it mean when a user types in “TV” into the search UI? Does the user want to know the difference between a plasma and an LCD TV, or does the user just want to know what’s on TV? Keeping in mind sensitive issues, what results do you display when someone types in “Where do babies come from?”?
5. The design of Google’s search UI was all about co-operation between people from various disciplines.
6. The aim is for speed and simplicity of design. While most people do not search all day, many people search something every day, so speed is crucial. Similarly, a simple UI should highlight the obvious, and then provide details that users can delve into if they want.
7. The design commonly reflects trade-offs between speed and elegance.
   
   

* The combinations of constraints other teams dealt with were:

• The user is a nine-year old with an I-Pad, and is ‘just like us’.
• The user has both an I-Pad and an old blackberry, has two minutes to order the pizza, and cannot type.
• The user is a nine-year old, is blind and illiterate and wants to order hundred pizzas for hundred separate locations.

What drives the need for Safer Systems Development Processes with ISO 26262

Posted on behalf of Christoph Bräuchle,
Customer Requirements Manager, MKS Inc.

As ISO 26262, the new standard for functional safety in road vehicles, comes closer to the final publication stage (the final draft international standard will be released in December), automotive manufacturers and suppliers must prepare to meet these requirements in development processes, work products and documentation. MKS supports automotive engineering organizations to be compliant while maintaining efficiency and productivity.

Process management and full support for most parts of ISO/DIS 26262
MKS provides extended support for hazard analysis and risk assessment and provides rich functionality for creating functional safety concepts (ISO/DIS 26262 part 3). Through all phases in product development (part 4-6) MKS manages processes, activities and work products. Full traceability between the work products from Requirements to Test assets on system, hardware or software level is one of the core strengths of MKS Integrity. Most of the supporting processes, such as Change and Configuration Management across all domains and development phases can be managed in MKS Integrity.

Safety Manual and reference process
Alongside with the FDIS of the standard MKS will release a safety manual for MKS Integrity providing guidance how to apply best practices and processes for functional safety management to existing processes managed in MKS Integrity. A reference process implementation will give a starting point for organizations that want to quickly adapt MKS Integrity for functional safety development and management.

Close cooperation with certification bodies
MKS cooperates with certification bodies with a long history and experience in functional safety management to relieve its customers from the burden of tool qualification according to ISO 26262 and ensure safe production use even in development projects with high ASIL levels.

To Learn more, register for the on-demand webinar on "ISO 26262 and its Impact on Engineering: Eliminating Risks Based on Mal-Functional Behavior of Embedded Systems" – Featuring Juergen Belz, CEO, PROMETO and Christoph Braeuchle, Customer Requirements Manager, MKS Solutions for Automotive, MKS

Metrics Matter – Real-time 360 Degree Visibility Improves Project Outcomes

Posted on behalf of Doug Akers,
Director, Product Management, MKS Inc.

It has been some time since we last took a deep look at metrics and how to measure the various aspects of development. At the time when I wrote "Metrics Matter" the market was very much centered around IT organizations and doing more with less and so the types of numbers being prescribed aligned with cost savings and maximizing productivity as would be expected. We grouped the metrics that were of most interest to CIO's into five categories – team efficiency (productivity), process efficiency (predictability), project efficiency (cost/schedule), value and effectiveness (alignment) and quality (uh quality) and today, for the most part, these categories still hold true (although we call them by new names).

Since then though a number of things happened to the market that cause us to take a different approach to what we focus on, the value of or at least the priority of metrics and measurements that inform our decision making processes.

First of all, software has busted out of IT in a huge way. In the last 5 years the amount of software in complex products like automobiles, airplanes, operating theaters and mobile phones for example has grown exponentially. What's more in these highly competitive industries software is THE differentiator and THE source of greatest innovation for the manufacturers. The numbers informing IT are vastly different than the numbers driving product organizations. Don't get me wrong, cost and productivity are important to these companies, but quality and cycle time – whether its defect fix cycle, change review cycle or product release cycle – are critical in these highly competitive markets. The value of reuse statistics, change propagation metrics, test coverage and risk mitigation numbers is what gets organizations ahead of the curve (or the auditor as the case may be).

Second there's the ground swell of Agile and other development methodologies intermixing with more traditional ways and means of delivering applications. Velocity, rework percentage, or running tested features are all examples of the types of project or business level metrics that are born out of the Agile era that most organizations hadn’t even heard of 5 years ago.

Third, the cost of failure has grown as competition expands, pace increases and innovation comes from unexpected areas. You may argue this one but from my observations of the customers and businesses I've been in touch with – never before has hitting a market window been so critical to the continued success of an organization. Where you were producing one device or product annually, now its 5 – oh and there is 50 variants of each of those across geographies, OEM's, carriers, or some other orthogonal dimension. But you still need to hit the 3 week window before the holidays.

Finally, we've just gotten better at this. We understand more about process, the right process and right amount of process. We know more about what metrics are useful and which are not (hello Kloc, I'm talking to you). And we know that that measurement is essential to continuous improvement – the question is not if we use metrics to inform our business but rather which measures will provide the most value.

There is definitely lots to think about for sure and there are a ton of resources out there (just google "Agile metrics" for example) to inform our thinking. But every once in a while it's a good idea to look back at something like "Metrics Matter" just to ensure that the core principles still hold true. Personally, I am glad they do – simple frameworks are often best and will stand the test of time.

Visit our website to learn more on MKS Integrity or sign up today for our Webinar on "Metrics that Matter to the Engineering Organization"