Modified by mgothe
Last year, AmyS blogged on the progress defining our internal Continuous Delivery process. To follow up on those concepts, I would like to share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.
Design is good business!
IBM recognizes that good design is good business. And there is a long tradition to back up that statement. Lately, IBM Design Thinking has gathered design practices to identify and ideate on the aspects that makes a solution desirable to its users; the Who, the What and the Wow! These aspects become the mission for release(s) and the business requirements for the solution. Amy identifies these as the business planning artifacts at the top of the planning taxonomy. We call these Release Hills.
Figure 1. Cross-Solution Planning Taxonomy
The use of Hills to capture the WOW’s
For delivery of improved capabilities for product line engineering, the team has focused on three Hills to drive innovation, to drive our work, and to organize and track our activities. Our first Hill ‘Work in configurations with artifacts and links’ focuses on core capabilities introduced in our solution on configuration management, with streams and baselines of engineering artifacts. The second Hill ‘Create and use product definitions’ extends the value of the first Hill with more targeted support for advanced product line engineering practices and use-cases. Our third Hill ‘Track and report on configurations of engineering artifacts’ is orthogonal to the first two and adds complementary capabilities to the solution with dashboards, queries and reports. To refine our mission to a focused and executable level we have also defined sub-hills that narrow-in scope and prioritize sets of features.
Organizing our solution artifacts by Hills
At the next level in the planning taxonomy we use the Hills as our primary organizational item for solution artifacts. At this level we use Rational Team Concert work items to capture our Epics and Features. And we use Categories to represent the Hills. This makes the process of classifying new capabilities simple by just using the Filed Against field when assigning Epics and Features to a Hill. We refine Hills into Epics to represent our sub hills. Features then become children under their parent Epics to further refine the capabilities into work that we can execute on within a single release cycle.
Our solution features are to be delivered by the impacted products, e.g. Rational Team Concert, Rational Quality Manager, Rational Doors Next Generation and Rhapsody Design Manager product development teams. Any enhancements to products are planned using Plan Items and Stories in each impacted product backlog respectively. To manage relations between solution features and application plan items we use cross-project Tracks links. This linking provides transparency to commitment and plan of delivery. It also provides transparency to progress on work and in-context collaboration.
Figure 2. Artifacts used for solution and product planning
Using scenarios and playbacks to explore and validating our design
Scenarios are a key concept in our design thinking. They ensure that we can deliver our features in a coherent, usable and desirable solution. Scenarios also support our activities on innovation, exploration and validation. Much like a movie script we let our personas act out in the scenes using scripted steps. Hence, each scenario Act is decomposed into Scenes where the scenario personas act through Steps interacting with the tools and collaborating in context of a configuration of engineering artifacts. As indicated in Figure 2 above, our scenarios are linked to the features used in each scene using an Implements relation. Using these links in figure 2 we can report on important delivery metrics. As a few examples, lately we have been using the Rational Engineering Lifecycle Manager (RELM) product and the Lifecycle Query Engine (LQE) to index our solution artifacts and provide traceability reports that outline the dependencies and coverage of Plan Items to Features, Epics, Scenes and Hills. This creates a great overview of the design artifacts. On our delivery dashboard we use the artifacts to present key design metrics like; ‘Scenarios with no features’, ‘Features with no scenarios’, ‘Features with no Tracks’.
For our PLE scenario we use a storyline on ‘Fixing a defect in a product variant’. This scenario is exploring in the first act how the scenario personas will initially ‘reproduce the defect’ using the engineering artifacts in the released baseline configuration. In the second act the team will ‘create a new delivery configuration’ with updated engineering artifacts resolving the defect. In the third act the team explores the opportunities for reusing the fix when ‘delivering and baselining a fix to the product line’. Our personas acting in the scenario are the Product Line Manager, the Project manager responsible for product line delivery, the Development lead responsible for platform component delivery, the Configuration lead, a Systems engineer, a Embedded SW Developer and a Tester. To show progress on the solution delivery we conduct frequent playbacks of the scenarios using initially low fidelity mockups and prototypes. Over time we converge to more stabile high fidelity wireframes and working code by milestone.
Exploring design options and usability
Lately we have been using playbacks to explore design options and usability aspects on how the scenario personas are interacting with the configuration management application when creating streams and baselines of configurations. Using a scenario and playback design approach helps us in clarifying implications to usability and consistency across the solution.
Modified by TheresaRamsey
The importance of a team in design
As an IBM Scenario Designer, one of the major successes I see in design is working as a team with shared responsibility and commitment to a common goal.
My real world experience with teams comes from the days when I rowed competitively and I very quickly discovered that in boat of 4 or 8 that each had their own skill; some were stronger, some quicker, some fitter, some with better technique. To get the best performance we all needed to be working together with the same tempo, same strength, same synchronicity and same commitment otherwise our individual actions hurt the team and our overall goal.
Boat positions within an 8+ shell - from http://en.wikipedia.org/wiki/Boat_positions.
The rower closest to the front or bow of a multi-person shell. The bow pair, who are the two rowers closest to the boat's bow, are more responsible for the stability (called "set") and the direction of the boat than any other pair of rowers, and are often very technical rowers. The bow of a stern-coxed boat is subject to the greatest amount of pitching, requiring the bow pair to be adaptable and quick in their movements. Bowmen tend to be the smallest of the rowers in the boat.
Coxswain or "cox"
The oar-less crew-member who is responsible for steering, race strategy and providing motivation and encouragement to the crew.
The middle rowers of a crew (numbers 2 and 3 in a four, and 3, 4, 5 and 6 in an eight) are normally the most powerful and heaviest rowers, colloquially known as the Fuel Tank, Engine Room, Power House or Meat Wagon. The boat pitches and yaws less in the middle, and the rowers there have less effect on these movements, being closer to the centre of mass and centre of buoyancy. Therefore the rowers in the middle of the boat do not have to be as technically sound or reactive to the movements of the boat, and can focus more on pulling as hard as they can. It is common practice among crews to put the most technically proficient rowers at the bow and stern and the physically strongest and heaviest rowers in the centre.
The rower closest to the stern of the boat, responsible for the stroke rate and rhythm. Everyone else follows the stroke's timing - placing their blades in and out of the water at the same time as stroke. Because of the great responsibilities, the rower in the stroke seat will usually be one of the most technically sound members of the boat.
I see this life experience applicable to design when you have multiple people with different skills and roles participating in the design process, including those roles that represent leadership, the business, engineering and design, with some roles representing mostly the user, some the buyer and some the technical aspects of the solution and these roles often do overlap so this can cause conflict.
So each person on the team has their purpose and it is important for each to understand the boundaries and how to leverage the skills of the others.
An example of how a team might interact to support design can be shown in this example Stakeholder Map for a specific capability of the system:
Now it might seem that a lot of people are needed to be effective in design but many people play multiple roles in the process and understanding the role being played and their perspective is essential to getting an effective design. Back to my rowing example: if I am rowing in the bow (at the front of the boat) there is no point in trying to set the rowing stroke rate (tempo) where nobody can see my tempo but it is my role to alter my strength to help keep the boat on course, as after the cox who is steering, bow can most influence the direction and stability of the boat, whilst stroke sets the tempo.
Throughout a race there is constant adjustment, where there is a high tempo and strength at the start to get ahead of the competition, then a period of stability, before the final push to the end. Racing is tactical and requires not only the physical capabilities, but strategy to adjust to the competition, and understanding each other’s strengths and weakness. There is no point in rowing at 50 beats per minute for the entire race, if nobody can keep up, so accommodation is needed.
Now to develop these race skills, requires the team to constantly training at different pace, distance and endurance, all as part of a plan and common goal. The race is won in the months before.
The same is true, in creating effective design, it requires team collaboration, with constant adjustment. It means allowing a visual designer to iteratively create an esthetically pleasing, accessible and enjoyable look and feel to the solution, whilst adjusting to the sponsor user feedback on their perception of both the visuals and the interactions, as well as ensuring that the business value of the buyer is achieved, and it is all technically feasible. It requires the design team to try different things, to iteration, collaborate, and validate, building on the strengths of each other all towards a common goal.
So which position do you play in this race - Cox, Stroke, Engine room or Bow?
Modified by TheresaRamsey
Ever had a horrific customer experience just trying to obtain service from a company, for example, a DSL provider? I did recently and it was unbelievably heinous, the net of which was that after 8 days, 6+ hours of my time on the phone, and interacting with all of the following people and systems in the “service” providers’ organization, I was worse off than when I started:
Chris in Sales
A service machine that sent three emails
Beth in Order Processing
David in Sales
A service machine that sent two texts
Andrea, then John, then Abe in Customer Care
Chris in Winbacks
Corey – installer
Amanda in DSL tech support
None of the systems in use had consistent or shared information. My order was lost. My order was scheduled for delivery by 8pm. Not there? Can’t find it; you will have to start over . . . I provided my name, address, phone number three different order numbers at least 20 times. It was maddening!
So how do bad solutions impact well-intending teams in large organizations with huge system development staff?
Team interaction design focuses outside-in, looking at the scenarios of interaction between people in different roles and using different systems. As Amy Silberbauer discusses in her blog entry, being business-driven means flying up at a higher altitude than a specific system or role and a “big-ole-bucket-o-features” view point. The solution-level scenario provides context for the "lower altitude" interactions of a single persona and her interactions with capabilities in a single product.
Here’s a simple sketch of a team interaction flow (click for larger image):
Beyond the user research on the individual personas, we need to reason about these kinds of team questions:
How many Project Managers does a Program Manager normally interact with? Are they in the same organization? Same geography?
Is there a 1:1 correlation of Project Managers to Dev Leads?
What role knows about the operations work related to the proposed Features? What roles in development interact with operations?
In the absence of this kind of analysis, we fall into the trap of building systems that are fit-for-purpose of a single role, but significantly impede the progress of the team.
In addition to flows, we craft team interaction narratives that we then implement in our products to understand and validate (or flag a correction needed) the team effectiveness with a solution.
Here’s an example, detailed from the flow above:
Act 1: An Idea from Business Gets to Development
Goal: An urgent business need comes in and must be prioritized and allocated to work that will be done by the teams involved.
Dennis - Business Owner (Exec)
Lonnie - Business Stakeholder
Phil - Program Manager
Bob - Product Owner
Pete - Project Manager
Marco - Dev Lead
Lonnie has an idea to offer a lower rate to Gold Star customers on the Holiday Loan special that is to start soon so he submits a new Business Requirement describing his request.
Phil is notified of new Business Requirement, so he reviews it and determines it fits within the existing Holiday Loans initiative.
Phil creates a new Feature for the JKE Foundation development area
Bob and Pete are notified of new Feature
Bob, Pete and Marco discuss the scope and risk to understand rough sizing, impacted components, etc. in order to prioritize in the current Release.
Marco works with development team (and optionally, enterprise architect) to determine what work must be performed by what teams. The work will be represented as User Stories that are Plan Items for the agile teams and Tasks that are Plan Items for the waterfall teams.
Marco opens plan items in Mobile and Core Project Areas, links each to the Feature, and allocates them to the respective Plans for current sprint/release
Pete accepts the Feature, and adds it to the current JKE Foundation Release Plan
And another act in the same narrative:
Act 5: Feature is Delivered into Production
Goal: Development teams deliver their parts of the solution independently and business is notified of the availability of the feature.
Mobile development team
Phil - program manager
Mainframe services team
Lonnie - Business Stakeholder
The mobile team completes their development and testing and deploys their application with the required feature into production.
As a subscriber of the mobile user story, Phil is notified of the delivery.
The mainframe services team completes their service, tests with the mobile front end virtual service, and deploys the service into production.
As a subscriber of the mainframe services task, Phil is notified of the delivery.
He sees that all the children of the Feature are delivered, so he marks the Feature as delivered. As a result, Lonnie is notified.
We socialize our flows and narratives with our development teams, of course, and they also become a rallying point for other stakeholders:
Sponsor users and customers to validate and refine
User assistance developers to leverage in delivering help files, tutorials, videos and other user aids
Proof of Technology engineers for defining the scripts for hands-on workshops
Business partners for identifying where their solutions are used to extend our capabilities
System verification testers to capture solution-focused test cases
Services teams who help customers transform their organizations using our solutions
User Experience and Visual Designers working at the product level
Do you do something similar for your solutions? If so, please share. Do you find the flow diagram easily understood?
Are there other roles in your organization who leverage flows and narratives?
I am happy to share more details and examples in additional blog entries. If you are interested, please comment on this entry to that effect.
Modified by TheresaRamsey
It’s been two weeks since my last blog on the transformation of our internal Continuous Delivery process, and while the progress has been slow, the ‘baby steps’ approach is moving into ‘toddler’ mode – at times chaotic and all over the place, but the interest and enthusiasm for change is intoxicating, motivating me to stick with it and press on.
Last time, I focused on how I applied design thinking to transform the way we planned for Continuous Delivery within the ALM organization. Let’s turn now to the specifics of the planning process itself and how I propose we integrate design thinking as part of planning for Continuous Delivery to ensure our success. In a recent Gartner report, Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology, they wrote "DevOps is not a set of technology tools…it is a cultural shift to improve quality of solutions that are business oriented.” Precisely! And in our effort to ‘walk the talk’ and be a good example to the rest of you struggling with this cultural shift, I want to explain why design matters as part of the transformation to a Continuous Delivery model.
Good Design is Good Business!
IBM recognizes that good design is good business. That’s great, but unless design is actually an integral part of planning and execution, we’re kind of insignificant in the overall scheme of things. My challenge is to come up with a process for our internal ALM organization that involves design in a practical way, that shows how we operate, what we deliver, how we really contribute tangibly to Continuous Delivery. Design is relevant for Continuous Delivery and brings real value to the overall process, but believing it and doing it are worlds apart.
I start by proposing this: if we as an organization are to make that cultural shift to improve the quality of solutions that are business-oriented, we must shift from a process that supports the delivery of features in products (with little or no business context) to a process that considers the business requirements first and then delivers solutions comprised of products with features to support them. We are really turning the existing process on its head, focusing on the delivery of business-oriented solutions not just feature-packed products.
The taxonomy below defines the planning artifacts we are employing as part of our new process. Design activities bridge the gap between business planning and IT execution by focusing on the articulation of Business Requirements to define the capabilities required by users, identifying the gaps in our existing solutions to support those requirements, then ultimately refining them into work items that drive IT execution and delivery of product-level capabilities.
The design exercise examines the business-oriented solution from the outside in, from the perspective of the user, performing user-level research, exploring existing capabilities and deriving the vision for our solutions going forward. Development teams try to do this, but it’s not their day job…in a quarterly release cycle, with a chunk of time devoted to prioritizing a backlog of work and another chunk devoted to creating spreadsheets and attending meetings to report on status, it’s kind of amazing that anything gets delivered at all. Having a team dedicated to the design activities allows us to focus on that very critical aspect of the overall process, which is explored in detail in the illustration below.
Creating Actionable Designs
At this point in my spiel, I get a lot of nodding heads. No real disagreement. But tell a technologist, a developer, an IT architect, a technical lead, that a bunch of pretty pictures is a key part of the overall planning process and that it can help them prioritize the tremendous set of work on their backlog and all niceties go out the door. Design is fine, but there is real work to do! My challenge is to not only show where design fits within the planning process, but how it will actually make a difference. Time for another Wow!
Working with scenario design leads on my team, we brainstormed on the idea of creating actionable scenarios in order to take this beyond a drawing exercise. No offense to my fellow designers, but we have an image that needs a bit of work if we are to be taken seriously. We came up with a proposed list of deliverables that development is typically responsible for that could be seeded from design scenarios:
Task Guides (reflections of User Stories that could be used for betas or technology previews)
Online Help Outlines
Proofs of Technology Tables of Contents
We also considered the significant contribution design can make to our testing effort. Rational’s quality management organization is successful in validating the quality of our products, but validation of solutions is far more difficult. Enter design. The scenarios we develop can, and should, provide the foundation for our solution-level test plans. In fact, our detailed design artifacts, which include wire frames, acts and scenes, actually begin to identify the steps required to accomplish a business task – the skeleton for a test script.
We’ve covered the development and test organizations and made a strong case for how design can help. One last critical group of stakeholders to impress remains - the decision-makers, the business leaders in our organization. The Wow! for this group of users is two-fold: inform them about the business capabilities that will be delivered to customers, and tell them when it will happen. At the end of a release cycle, the bottom line is “what can my customer do with this?” By including design as an integral part of the overall planning process, we can answer that question and many more about what will be coming in the next delivery cycle and the next and the next. We have a complete process, one that ensures quality of our solutions, not just from a feature/function perspective, but from an understanding that in the end, we have delivered what is required from a business perspective.
Modified by TheresaRamsey
As the lead functional designer in charge of complex IT scenarios for the IBM Rational Design Team, I was challenged recently to help our internal development organization ‘walk the talk’ – drink our own champagne, practice what we preach, use what we sell. After all, we are a large enterprise. We develop software solutions that epitomize the same complex IT scenarios I’m trying to get my head around. What a great opportunity to practice this, to use our own organization to validate my scenarios. In this blog, I give you a window into my designing mind so that you can see how I applied design principles in a practical way to help our organization transition to a Continuous Delivery process. Ultimately, this project is also helping me refine the complex IT planning and management scenarios that lay the foundation for the solutions we deliver to delight all of you. This blog is not about Continuous Delivery specifically, it is about design. For more information on the details of this journey, please visit DevOps on jazz.net, where you will find blogs from me and others on how we are actually doing this.
Making the move from more traditional methods to an agile, Continuous Delivery model is anything but trivial. (If it's a new term to you, watch this Continuous Delivery video.) Particularly in an enterprise organization like IBM, there are all the typical challenges associated with large scale transformational efforts. But change is good, right? Sure…it’s also really hard. So where do we start? When challenged with a complex problem, my go-to approach is to take ‘baby steps’…understand the challenge, articulate the short- and long-term goals, try it out, revise, repeat. By practicing what we preach, only then am I confident in sharing the process with others. I believe that we must first act as the consumers of our software to solve a real business problem before we can even propose to understand how another organization might do it. Man, do I love this idea!
Designing the Continuous Planning Process
This ‘baby steps’ approach might be more accurately portrayed as a ‘design thinking’ approach. Design thinking dictates that I consider the Who, the What, and the Wow. My goal with this project was to do that for our organization. By embracing this challenge, I get to play the role of the user, the Program Manager who needs to spin up a complex project from business planning to development and test and finally to deployment. I also get to try out this scenario with some of the executives in our organization to not only help them do their jobs, but also show them how our software allows them to do that. This is going to be fun!
With my ‘design thinking’ hat on, I started by tackling the Who, identifying the roles in our organization involved in the Continuous Delivery process. The short list from a planning perspective includes the executive stakeholders, the business leaders that make investment decisions, and IT Program, Project and Product Managers that must ensure we deliver on those objectives.
Next, the What. What are the activities these roles engage in, what information do they need to plan and manage a complex project throughout this process? In particular, what would Dibbe Edwards, our VP of Development, need to know in order to better manage the software development and delivery process for CLM? Got the Who and the What. Now how do we Wow! them?
In trying to come up with the Wow! solution to this challenge of planning and managing complex projects to enable Continuous Delivery, I considered what a “day in the life of Dibbe” looks like and how she does her job today. In short, spreadsheets and meetings. Sound familiar? There is a better way, and not just for Dibbe and the other business stakeholders. Better for Dibbe means better for managers all the way through the development lifecycle. Here is the Wow! My goal is to eliminate the spreadsheets and minimize the meetings. This doesn’t address all of the problems with our Continuous Delivery transformation, not by a long shot. But it is a perfectly reasonable ‘baby step’, a Wow! for some of the key roles in this scenario.
We are just starting this journey and have a way to go before we can claim success, but by applying design thinking principles I have been able to frame the problem by looking at the users and what would excite them about a solution that helps them do a better job every day.
What can we do to make your job better every day?
Modified by TheresaRamsey
Have you looked at modules in Rational Requirements Composer (RRC) or DOORS Next Generation (DNG) yet? If not, I would suggest you take a look to see if it can help you better organize and manage your requirements. We think they're kind of a big deal, but we'd love to hear what you think of them. We know we still have work to do, and we'd like to have your input to influence our design directions.
First, I'd like to briefly describe what a module is, and some of the reasons why we think they're a big deal. Then, I'll tell you about where we think we need to focus to make it more usable and ask for your comments on the design direction.
Modules were introduced to RRC and DNG in Version 4.0.1 as a way to organize, structure and provide context to requirement artifacts. (If you're a DOORS user, you already know about modules, although modules in DNG and RRC are different in some significant ways). Prior to V4.0.1, the primary way to organize and structure requirements was through "composite" documents or collections.
A composite document is a "master" document that embeds requirement artifacts, and provides the structure and context around those requirements. Composite documents can read like a requirement specification document, but are limited in management of those requirements; you can't edit the requirements directly from the master document, you can't create views or filters of those requirements, and you can't show requirement attributes on all the requirements (you can only hover on one embedded requirement at a time to see it's attributes).
Figure 1. Example of a composite document. Note that the numbers are manually added. (Click to see larger image.)
A collection also allows you to group requirements. With collections, you can show attributes of the requirements in the collection (in separate columns), and create views and filters on those requirements. However, they are unordered and unstructured, so they don't read like a specification document and are not as easy to consume.
Figure 2. Example of a collection. (Click to see larger image.)
Modules combine the best of composite documents and collections, and then takes it up a notch. Modules are a collection of other artifacts, and use the same "grid" display for artifacts that collections use, so you can show attributes and create filters and views. However, modules allow you to order requirements, create a hierarchy and add headings, so you can provide structure. Headings are also automatically numbered based on their position in the hierarchy. So a module looks like a requirements specification document and is easier to consume. Additionally, you can edit requirement content and attributes and create new requirements right from the module, so they are easier to manage as well.
Figure 3. Example of a module (Click to see larger image.)
I'd like to mention a few more things that make modules a big deal before talking about what we'd like to improve in the future.
Context-specific properties. As with composite documents and collections, artifacts can be reused in multiple modules; and changing them in one place will change them in all places they are used. However, modules do provide a few context-specific properties. When you add comments, tags and links to a requirement artifact in a given module, they are specific to that instance of the requirement in that module. You can also link to a specific instance of a requirement within a module.
Module templates. Module templates are a step up from standard artifact templates. You can create a module template which contains headings, process guidance text, and other things which you want to be common across multiple modules, as well as "placeholder" requirements for each section of the module. When a new module is created from the template, the common parts of the template will be reused in the new module (and later changes to those artifacts in the template will also be changed in the new module), but the placeholder requirements will be duplicated (e.g., new artifacts will be created just for that module).
Converting requirement specs to modules. If you already have a requirements specification in a single document (either in RRC/DNG or externally in a Word document), you can easily convert that to a module. There is an import wizard that will essentially look in the existing document, extract headings and requirements, create individual requirement artifacts for each of them, and put them into a new module. The resulting module will resemble the original document, but is now made up of individual requirement artifacts in RRC/DNG.
Future usability improvements
Hopefully I've convinced you that modules are a big deal. (Please, don't just take my word for it -- try them out yourself). That being said, we're just getting started. We know that we still have work to do to make modules read and edit like a requirements specification document, and make it easier to manage your requirements within a module. We've already received a lot of user feedback from beta programs, design partner programs, usability tests, Innovate conference, etc., so we know some of the things we need to improve. Below are some of the things that our module design team has identified as top priorities based on that feedback (as well as our internal usability reviews).
Future focus areas:
Simplify process of creating new artifacts within a module
Avoid use of New Artifact dialog as much as possible; it breaks the user flow, it's confusing in the context of a module, etc.
Make it easier to pick artifact type, be smarter about artifact type choices
Be smarter about displaying artifacts as headings (e.g., specify "heading" artifact types that are always displayed as headings).
Improve performance of creating and editing requirements in a module
Drag and drop to rearrange artifacts within a module (in addition to the current cut and paste method)
Improve module print (print what you see on the screen)
Better review and commenting of artifacts within a module
Easier to view and modify artifact properties within a module
Easier to summarize and navigate within a module
Additionally, you can look at the following documents to see what our goals are, both from a product perspective and from a design perspective.
From a product perspective, you can view the requirements specification for modules (presented as a requirements module of course ;-): 12640: URS-Core Module Support
From a usability and design perspective, the following document summarizes and organizes some of the larger usability issues we are aware of with modules: 14840: Scenario: Using Modules
Finally, we welcome any feedback on our design focus. If you find additional usability problems or have input on our priorities, please let us know either through RTC work items or comments to this blog.
Kirk Grotjohn (UX Designer for Rational Requirements Management)
Modified by Corrie Kwan
I love my job. I do! Who doesn’t love a job that makes the world a better place to live in?
When I was very little, I once wanted to be a bus driver. Not just any bus driver, I wanted to give my passengers the biggest smile as they hop onto my bus so they would have a great start in the morning. I wanted them to have the most delightful journey to work, so they will feel great for the rest of the day.
As a user experience practitioner, I don’t drive a bus, but we certainly strive for making our products more delightful for our users.
I work on a product called JazzHub (https://hub.jazz.net/). It is a task tracking and planning tool on the cloud, with coding capabilities.
We have been taking a lean approach to conduct user research. Users are invited to our studies (in the lab or remote), exploring and validating the latest designs. During the usability sessions, users are given a set of scenarios to walk through using our tool, and are asked to use the “Think Aloud” technique when going through the tasks. By observing and asking questions, we pay attention to their stumbling blocks: Did users get lost within the tool? Are users confused by a certain widget?
By being lean, we run tests more frequently (once every 3 weeks) and have a much tighter feedback cycle, communicating what we hear from the user research to the team within a week, making possible improvements that will be rolled out again for next set of design validations. The JazzHub team has made great improvements, especially its getting started experience during the past months.
What also excites us is that when we first tell users about JazzHub, many did not think they had a need for the tool. But 5 minutes into the conversation and they start learning and seeing more, most would say: “Ah! I can see a good use for JazzHub. Let me take some notes about it as well."
Even though it's still in beta, JazzHub does provide great value for a wide variety of users. Creating a public project is free. (Yes, it’s FREE!) so I encourage you to try it out by registering at https://hub.jazz.net/. Drop me a note to let me know how you feel about its usability or better yet, email me to learn more about the usability sessions, it only takes an hour and it is fun! You can also use the JazzHub itself to provide feedback. I hope we hear from you!
Modified by kgoscimi
Where to begin..
My head is still reeling. So much sharing, so much learning, so much fabulous geekery! Expedition Everest wasn’t the only rollercoaster I rode last week. During Innovate, from one moment to another I was up and down (and sometimes upside-down): energized from all the intense knowledge, camaraderie, and opportunities to learn (and gallons of caffeine!) then exhausted from all the over-stimulation and long days (and caffeine withdrawal); and then back around for another ride the next day.
So, now that I’m back on solid ground again, what did I take away?
I had no idea what I was getting into
… but it was fabulous madness. I’m sure I made a million newbie mistakes, but that just leaves me wanting to head back next year to get better at it. A few things I learned (which I’m sure every newbie before me figured out):
Always have business cards with you
.. even when you think you’re just grabbing a nightcap on your way to bed. But don’t despair if you get caught without.. just get creative and exchange info on drink receipts. :)
Keep a little notepad handy.
I tucked a notepad and pen into my badge holder and it came in handy for exchanging contact info, taking notes, drawing pictures, and soaking up spilled coffee.
Be a hero; bring an extra power cord.
I did. It saved someone. I felt like a hero. Not the kind they make movies about, but maybe the kind they write tiny footnotes about. ;)
Take brief mental breaks when you can. It takes energy to maintain focus and enthusiasm. It takes breaks to maintain energy. Despite what I felt Tuesday morning, it turns out there is life after Innovate.. unless you never escape the insanely-air-conditioned Expo (does it really need to feel arctic?) and wind up cryogenically frozen to your station.
Schedule time to connect.
The conference has so many great things going on and so many interesting people to talk to, that it's helpful to schedule a time connect with folks. It's also helpful if your cell phone has texting so you can connect on the fly.
Be ready to improvise.
You can plan all you want, but be prepared to go with the flow. I stuck to the script 0% of the time, but I learned something valuable from 100% of my interactions.
Anticipation of presenting is much worse than the presentation itself.
The nervousness leading up to my presentation (co-written with the lovely and talented Kelly Raposo), Smarter Documentation: Shedding Light on the Black Box of Reporting Data, seemed so silly after the fact because it was a really enjoyable experience. There was so much great audience participation and exchanging of ideas, and I got a lot of useful feedback on the subject of reporting documentation. Thanks to all who attended and helped in the preparation. Special thanks to Kelly, Arthur, and Jackie!
Read more about what we learned and our plans in my upcoming blog: Insights from Innovate 2013: Making Smarter Documentation Even Smarter
Personas help us understand our users. We had persona trading cards and posters that we ask people to comment on. I had a self-proclaimed Allison and a Marco and a Susan and a Tammy sitting across from me. I even had someone who wanted to get Tanuj’s autograph.
I want to talk to our users all the time!
It’s so energizing. The positive feedback is wonderful, and the negative feedback is empowering. Any time we can identify a problem, it’s an opportunity to make something better, and when you talk to the person who’s actually having the problem, you get to see how you can make this person’s life better. That’s pretty awesome. And we want to start or continue the conversation with all of our users.
The work we’re doing on the Jazz Platform is valuable.
For our work on the evolution of the Jazz platform, we understand that people need to get at their data across their repositories and across their tools to help them get work done and make important decisions. People also need to have an easy way to share with others in their organization. We're excited and happy when we show someone early previews and they ask “When can we have this?”
Everyone needs reporting, and it needs to be easier and faster.
Not a shocking revelation (I’ve been working in reporting for quite a while), but I had the chance to talk to folks about specifics, and I plan to continue the conversation with a variety of folks who said they were willing. Look for more insights on querying and reporting on my upcoming blog: Insights from Innovate 2013: What we learned about querying and reporting.
Thank you, Steve Wozniak, for not just saying that you support the kids and education, but for living it. I was hanging around the Expo after hours Tuesday evening and wandered into the Code Rally room. Turns out that all the students who got a shout out during the morning’s general session were doing their awesome, brainy thing, hacking and racing and having a great time. The room moderator told me that they’d all spent a couple hours with the Woz, and that despite a press agent tugging on his sleeve, Steve would not leave until he’d spoken to and taken pictures with every last kid. Rock on, Woz, rock on.
Dinosaurs never go out of style. Thank you for the reminder, Animal Kingdom.
Read more about this in my upcoming blog: Why dinosaurs will never be extinct -- Kidding!
The feeling of camaraderie, the sense of technology racing ahead and data accumulating at the speed of light, the impression that everyone you speak to (and don't get to speak to) has something really interesting to say, the spirit of support for education and our future… those things stuck with me. (The rainbow of ribbons I accumulated stuck with me too..until I went out in Tropical Storm Andrea, that is.)
I was personally inspired by the talks on innovation, disruptive and incremental. You can watch the General Sessions and other videos at Innovate 2013: The Technical Summit video library. From what I heard in the sessions, on the Expo floor, at the lunch table, over drinks.. we’re all passionate about innovating. And we can't do it without you! Follow the blog and participate in the IBM Rational Design Community to learn more about how you can get involved and make Rational software work better for you!
Modified by TheresaRamsey
The Rational Design team, as part of the Rational software team and IBM as a whole, is on a mission to make our products useful, usable and desirable. We know that many people rely on IBM products and solutions to help them do their jobs. We want to make the client experience not just dependable, but also delightful.
The Rational Design team is comprised of professionals in areas such as user research, scenario design, user experience, and visual design working within the product teams to design best-of-breed, innovative solutions that customers need and want to use. We are passionate about building software that people enjoy using, even if it's for their job. (Although we enjoy playing Angry Birds too).
The characteristics of "useful," "usable" and "desirable" are all centered in the human experience. Having a deep understanding of the people who use our products is the most important element in product design. By knowing what you need, how you approach your day to day tasks, and what challenges we can help you overcome are core to our being able to define what features you will find useful, what interaction patterns will make them usable, and what surprises we can add that make them desirable.
We'd like to get to know you, our users (even if it's virtual, though we'd prefer to see you). Users might be the actual people buying, recommending or using our software. Users might also be people that work in service delivery, business partners, and various other stakeholders.
If you are using (or might use) Rational software, we hope you will help us accomplish our mission. The Rational Design community is one way to interact directly with designers of Rational software. We'll use this community to solicit user input on the design of Rational software, involve users in design activities, and inform folks how we're incorporating user input to make our products better. We hope to collaborate with you to make sure our software meets your needs and hopefully makes your job and your life a little easier and happier.
We look forward to an exciting trip and hope your join us on the way!