Autodesk in Manchester, NH offered up meeting space for the latest NH Usability Professionals Association meeting on Wednesday night (March 25th). Rather than a speaker, the activity was a “Design Slam”. We had a real-life client tell us about his non-profit, Sustain NH, which matches talents of volunteers with technical needs of other non-profits in New Hampshire. In this way, the non-profits can increase their organizational efficiency while keeping their money going toward their primary concerns. Sustain NH is looking to build a website soon, so we learned about the audience they would like to speak to, the information they would like to convey, and their need to collect information from possible volunteers and sponsor businesses.
With this info, we broke up into groups of 5 people and spent 45 minutes tackling aspects of the design. Once finished, we got together and presented to the rest of the attendees and the client. Some of the groups ended up with a wireframe of a site design, noting specific functional areas that should be on the front page. One of the groups did a task flow of somebody visiting the site, highlighting the areas they felt were the most important to put up front. And one of the groups produced two main personas and described what each of those personas would need, in terms of information and ways to contribute, when they came to the site.
The experience provided a way to stretch our brains a bit, work on something new, work with new people, and see what ideas other groups came up with. And it was all for a great cause! Our client can now take these great ideas and put them into the site he’s building for Sustain NH.
Everything was proceeding as one might expect in the business review of Project Dragonfly earlier this year. Development on the application had been very productive since we had transitioned from our proof of concept phase in the fall of last year. Stakeholders were well aware that we had quickly gone from research to proof of concept to product. We even had three user studies under our belt. Confidence was high. And then we heard it.
“Get it out there now. Get in the game.”
Our plan was to market Project Dragonfly virally. Going out now meant that we were a little early and many details were still on the to-do list. As a user centered design practitioner working with an Agile Development process, I was comfortable working in an iterative manner to engage users quickly so that we think through details and bring solutions forward. Yet something about this situation seemed different to me. We wanted the world to broadcast about the benefits of Project Dragonfly while our marketing efforts simply facilitated the conversation. It seemed to me, then, that the design would need to be polished. I mean, you only get one chance to make a first impression right? Or do you? The process which unfolded led us to a few insights about going viral.
Quickly I realized that our thinking about user engagement would have to change. Where users and feedback had been dialed into the project at specific points to review specific functionality, our feedback link within the application and postings on our various social networking sites would create multiple direct lines for users to provide continual input. If we wanted the world outside to broadcast about the benefits of Project Dragonfly, then our response to feedback would need to be honest and transparent. We would need to build loyalty. Design of the product (in whatever state it was in) would be vibrant and public. We would need to work at filtering feedback in order to guide the design in the direction indicated by the input. The more we matched user expectations, the stronger our viral broadcast signal would become. Change happened for me when I realized that sometimes being in the game with users and solving problems collaboratively is more important than coming to the game with solutions fully formed.
Change Your Application Inside and Out
Once I had changed, I realized that a few other changes were on the horizon as well. In order to get the world talking about the benefits of Project Dragonfly, we would need to create an environment that would make going viral as easy as possible. The application would need to change inside and out.
Frictionless – Remove everything that is a barrier to using your application.
Right at Hand – Make the most useful part of your app right there at hand.
Impactful – Maximize your reach when you broadcast your message.
Targeted – Focus on features that add value to the users using your app the most.
Outreach – Get sites to link to your application.
Outside of Project Dragonfly, we have begun engaging the world with the help of next-generation Web marketing experts Nobles Studios, Inc. The initial goal is to raise awareness and gather feedback. I’m proud to report that the team has already taken action on the highest priority feedback items. Our next update will include some very creative solutions to top requested items like stretchable content and more obvious 2D/3D transition. Launching on the social sites Facebook, MySpace, Twitter and Flickr we look to get our message out to the world and keep followers up to date on these exciting changes. Over time, we will iterate on the approach and media outlets that stick with users will remain while those that don’t will fade away. As a team, we are working to gain actionable feedback, talk straight and develop loyalty. We want engagement to build loyalty and loyalty to build virality. As for the world, it appears to be interested as evidenced by our coverage in the NY Times technology blog.
A common mandate at many software companies is “Make our products consistent!” I’ve heard this clarion call for consistency at every company I’ve worked for that has more than a single product or service. The rationale behind the consistency mandate is that it will reduce design and development costs, improve the overall quality of the software, strengthen the brand (“the products should all look like they come from the same company”), make learning easier for users, and reduce errors when multiple products are used together. These are all great goals, but there is a problem with the consistency mandate – consistency is complex, multi-dimensional, and sometimes at odds with other important goals like usability.
To illustrate the multi-dimensionality of consistency, take a look at the diagram below and answer the question, “Is this consistent?”
This simple diagram is consistent in several ways:
The fill color
The use of straight line segments
The line color
The line size
The rotation of the objects
But it is also inconsistent in other ways:
The number of line segments
The location of the baselines of the objects
The area enclosed by the lines
The angles at the intersections of lines
This simple abstract diagram illustrates that consistency is not a singular concept. In the design of software user interfaces, consistency has many layers and dimensions. Here is a partial list of some of the many layers and dimensions of consistency (note that this list is intentionally long):
Consistency with the ways that different classes of users work (perhaps the most important consistency consideration)
Consistency with operating system (OS) user interface guidelines
Consistency with other corporate products
Consistency with other applications that are used with your product (a common refrain that I’ve heard over the last decade is “Why isn’t your product consistent with Microsoft® Excel®?)
Consistency between the system model and the user’s mental model
Visual consistency in the use of icon styles, object templates, and color
Control consistency (for example, different dialogs or Web pages should use the same controls for the same functions)
Error prevention consistency (for example, in one case you provide a cue about the required format for phone numbers; elsewhere, you provide no cues and display an error message if users key in a number with the wrong format)
Terminology inconsistencies (“Login” and “Log in” are both used as labels in different parts of the site or product and “sign-in” is used in the Help system for the product)
Consistency across different media (at a corporate level, this can involve marketing materials, user documentation, technical guides for support, advertising, and the software interface)
Consistency of Web pages across different devices such as PCs, mobile phones, and PDAs
When the call comes to “Make our products consistent”, the questions you should ask to avoid confusion and hostility are:
“Which layers and dimensions of consistency are most important for meeting our business and user experience goals?” “How do we promote a shared understanding about consistency (style guides, pattern libraries, consistency inspections, checklists, consistency fairs, and so on)?” “When we have conflicts between the different types of consistency, how do we determine what type of consistency takes precedence?”
For example, you might have a consistency principle stating that you should use checkboxes for binary choices – a fine guideline most of the time, but not always the right thing to do. You might want to violate the rule about checkboxes (control consistency) when the choice is not clearly binary. In the following example, there is no clear opposite; a user would not quite know what would happen in the OFF state:
In this example, the opposite of Spot Fill is Flood Fill, which is not a clear “OFF” choice, so the appropriate controls to ensure user understanding would be two radio buttons. Here, consistency of understanding overrides consistency of controls.
One of the biggest mistakes that organizations can make is to assume that consistency with specific rules is always the right. Sometimes it is better to be inconsistent. Jonathon Grudin wrote in his classic paper, The Case against User Interface Consistency1, that there can be both good and bad consistency and it is important to consider when consistency should be traded off against efficiency or other usability attributes. For example, in a Web application you might design a form that people use often (say 50 times a day) to be more efficient than a form they fill out once (trade-off of visual and interaction consistency against efficiency). This is sometimes referred to as the usability versus consistency debate. If we are too dogmatic with visual or interaction consistency requirements, we can end up with frustrated users.
What methods can you employ to improve the consistency of your products? In a follow-up article I will discuss some interesting methods, including consistency fairs, GUI rolls, consistency inspections, consistency posters, and synergy reviews.
1Grudin, J. (1989): The Case against User Interface Consistency. Communications of the ACM 32, 10 (Oct. 1989), 1164-1173.
As interaction designers at Autodesk, we sometimes engage in design and thought investigations that are not directly related to the task at hand. These investigations are ways to frame problems by venturing into related design disciplines. For example, in order to understand what might be an appropriate transition when changing views in a 3d model, we try to understand how a video artist would create a transition between two scenes in a video. To understand how to improve the graphic quality of elements drawn in a building information model, we look at lots of pencil sketches drawn by architects. We think, what would happen if an on-screen element was made from physical material? How can we further improve the interaction with that element? In addition to thinking about design problems in a different way, at times we go a step further: we make a short movie to understand how a video artist would approach scene transitions, or we make a physical representation of an on screen control.
One such example is the Tangible View Cube, a small, wireless handheld device used for controlling the orientation of an on-screen 3D model. The Tangible View Cube is a physical representation of the ViewCube® available in many Autodesk applications. The interaction with the cube does not require a user to be a product expert to change the orientation of the on-screen 3D model. The cube has a single button on the top: one click unlocks the sensor inside the cube and the user can change the orientation of the 3D model. Click again to lock the orientation, and pass the tangible device to another person to share. You can see the Tangible View Cube at work in this video:
This was a small and well-focused project that did not require many resources to make. While the investigation was not an end in itself, it was a “kick in the side of the head,” that helped us to unblock our thoughts. By temporarily removing ourselves from the problem, we were able to understand interaction with an on-screen control from a different perspective.
One of the great things about my job as an Interaction Designer is that I get to constantly learn about new professions, people and workplaces. Understanding the use context for the software I design is a basic starting point for any project. This means learning about who the target user is, how they work and where they work. This kind of workplace anthropology is one of the things I like best about user experience design work. However, the reality is, it is hard to have regular and sufficient access to your target users, and in some technical or specialized domains, the complexity of even understanding what they are doing can be a fulltime job.
This is where the role of an in-house subject matter expert (SME) can come in. An SME is someone who has been trained and has worked in the area that is being targeted for the new application. At Autodesk, we have found that pairing SMEs with Interaction Designers is the most efficient and successful way of meeting user centered design goals.
The subject matter experts participate in product definition, concept designs, defining user personas and more. At first it may seem that the capabilities and responsibilities of a SME would overlap too much with those of an Interaction Designer. One might think that having both roles on a project is redundant. My experience has shown that, in fact, the different perspectives, education, and training creates a synergistic effect that is greater than either professional working alone.
Subject matter experts really understand the problem space. They have a deep and intuitive understanding of what works and doesn’t work in the task flows. They often have a vision of what a possible solution may look like. Possibly most important of all, they bring a passion and determination to the project. There is no better cheerleader for producing a better design than someone who has lived through the experience of using a sub-optimal solution.
Interaction designers are good at diagnosing and articulating a problem. We are able to observe the workflow, identify the goals and generate problem solutions from a more detached perspective. Designing without bias allows us to differentiate between general problems in the task flow and personal pet peeves. This outsider relationship to the problem puts Interaction Designers into a better position to make the kind of conceptual leaps necessary for true innovation.
Practically speaking this means that the research and design tasks will need to be shared. In a recent project where I was working very closely with an SME we took turns owning each of the design process steps. The SME started with the initial requirements and product concept definition, which he elicited through a series of customer visits. At those same visits, I was developing our product personas and generating use case scenarios. Coming from the perspective of the product personas, I was then able to work with the SME to refine and prioritize the requirements. He in turn was able to use his real life experience to spot gaps in the use cases and to provide some measure of validation on the personas.
During the subsequent ideation, reflection and refinement phases we would each take a part of the application to take the role of design lead. This back and forth, iterative way of working allowed us to largely work in parallel to each other and thus get more done. Much like ‘pair programming’, an extreme programming technique, we share the design work so that the knowledge base for the design is distributed and so that multiple perspectives are incorporated. At the same time, this method provides the checks and balances we needed to keep the design aligned to our user’s goals.
By closely involving the SME in the interaction design of the product we have found that both parties benefit. The interaction designer gains ready access to deep domain expertise while the subject matter expert can engage with the user centered design process to produce the most appropriate solutions. Which, really, is the biggest benefit of all.
I’m part of the AEC User Experience Team at Autodesk. Our goal is to design a great user experience for our customers, but just what does that mean? Our definition of user experience focuses on all the touchpoints that current or new users have with our product. For example, the downloading of software trials is often the beginning of one’s user experience with a product. If you have to fill out forms that ask for too much information, (should “cell phone number” be a required field on a trial download form?) or present you with too many obstacles, the likelihood of a positive user experience will be low. Your interactions with technical support, documentation, the product, and even other products that you use, are all aspects of the user experience. So, our general definition of user experience includes the following goals:
Provide our customers with products that meet observed and future needs
Design products and services so they are easy to learn, and once learned, efficient to use
Design from a holistic perspective; ensure that there are smooth flows between different products, people, and locations
Reduce the chance for errors and make error recovery simple and straightforward
Design products and services that delight our users and go beyond meeting basic needs.
Provide a seamless and integrated system from the first contact to repeated and long-term use of products and services
These goals can be translated into the user experience pyramid shown in Figure 1. At the bottom of the pyramid we have usefulness. Is the product useful in the context of your work? Does it meet your basic needs. Next up the pyramid is usability. Usability is often spoken as though it was a single attribute of a product, but in fact, usability has many dimensions including ease of learning, efficiency, satisfaction, consistency, responsiveness, and error rates. Some of those dimensions can even conflict – like ease of learning and efficiency – you can make something really easy to learn, but what makes it easy to learn might reduce its efficiency for experts. Usability is the substrate for the attributes that make a great user experience like joy, delight, pleasure, elegance, integration, and attractiveness. You can have a useful and usable product that allows you get your work done, but to have a great user experience you need to transcend usability.
Figure 1: The user experience pyramid
Designing a great user experience is a challenge so I thought that I would share some of the methods that we employ.
Methods for Designing a Great User Experience
User-centered design involves repeated contact with users, continuous evaluation of design concepts and prototypes, and constant testing of assumptions about users, tasks, workflow, and context. Here are some short descriptions of methods that we use to help us create a positive user experience.
First Experience Studies. What is the experience of a person who downloads an Autodesk product from the Web and tries it out for the first time? First impressions are powerful and observing users during their very first attempt to a use a new product or feature can reveal obstacles that are not at all obvious to more experienced users.
Customer Satisfaction Surveys. We have Customer Councils comprised of users from all over the world. Once a year, we ask members to give us feedback on many aspects of products to assess overall satisfaction. This feedback is used internally as input for product requirements and to look at areas where we need improve. Between the yearly satisfaction surveys we solicit survey input on areas where we intend to focus on in future releases.
Site Visits. Site visits, where we spend one or more days observing how groups use our products, are incredibly valuable for understanding how our products support collaboration within and between offices. Site visits helps us answer questions like: What are the issues faced by companies that are working with multiple contractors, in different locations, using different versions of software? What can we do to make high-frequency tasks more efficient? What errors are most common when groups are spread out geographically?
Remote and Local Usability Testing. A key theme of user-centered design is to start testing early in design and continue testing through the design and development process. We often start our testing with paper prototypes to get early feedback on different conceptual designs and then move to medium-fidelity prototypes, and finally to working prototypes. At each stage of testing, we look at different issues. Paper prototyping focuses on general concepts, terminology, and high-level understanding; later, higher-fidelity prototypes examine detailed interactions, feedback, and performance. A method we are employing more often is remote testing where we use collaboration software like GoToMeeting to present users with early prototypes and get feedback without anyone leaving their offices.
Vision Workshops. Our design team needs to look ahead and one way to do this is to hold vision workshops where we:
Identify the common problems or issues with a particular (current) product or situation.
Generate visions about a concept of the future.
Discuss and analyze the viability of the ideas and solutions about the vision of the future.
To meet our goal of delighting users, we need to think several versions ahead and consider what we will need to design to bring joy to our customers. We also need to consider that delighters, over time, come to be expected features. In the early days of the graphical user interface (GUI), the pop-up menu was a delighter because it cut down the time required to access a function from the menu bar. Now, pop-up menus are standard features and not the delighters they were 20 years ago.
The Spotlight Shines Brightly on the User Experience
When I started my career in the early 1980s, product reviews were found in IT journals, ComputerWorld, and Byte. There are still reviews in technical magazines and journals that highlight poor and great user experiences, but social networking tools and viral reporting about user experience with a product can quickly lead to user outrage and corporate panic. Blogging and twittering about a product or YouTube satire of a product can influence product design and induce ulcers. We fought for years to make usability and then user experience as important as any other product attribute and are now in the spotlight. The design of a good user experience requires political savvy, solid design skills, constant interaction with users, and continuous study of emerging technologies and disciplines like persuasive technology, ambient computing, emotional computing, mobile computing, and ubiquitous computing. This is a great field, but not one for the faint of heart.
Design teams working on projects that employ a purely sequential development process – such as the waterfall model – are challenged to deliver the right solution the first time. This is unrealistic with regard to user-centered design methods, which rely on an iterative feedback-and-refinement loop. On a sequential project, however, requests for changes to a design that is already in the Development phase are weighed directly against stability, performance, and overall completeness. What if designers could own more of the UI work that developers normally must do, for example change the layout of a dialog, adjust the look of a control, or change a few text strings?
XAML stands for eXtensible Application Markup Language and was created by Microsoft. It is currently the primary mechanism for declaratively creating the user interface in a Windows Presentation Foundation (WPF) application. WPF is part of the .NET 3.0 framework. Why discuss these very technical things in a design blog post? The answer is simple: because XAML is designed for designers. It has other uses of course, but one of its main tenets is that XAML enables the separation of UI and logic (code).
That is a very powerful concept! In this and future posts, I will explain how a few of us at Autodesk are using XAML in our design process as a way to enable design refinement during the Development phase.
Separation of UI and Code
What does it mean to have a separation of UI and code? Typically in an application, code for the UI and code for the logic and data handling is tied up together. The two might be in separate files, but it doesn’t mean they are separate. The UI is created by using code. For example, code to create a button can look something like this:
Button okButton = new Button();
What if you want to change the location of the button or the appearance of all the buttons in a dialog? There is code for that too. Inevitably, as we refine designs through usability tests and customer validation, we create the need for someone to make changes to code. Using XAML, we designers can make our own UI changes without the need to rely on the programmers. Let’s look at some XAML to see a simple example of how this works.
XAML is XML and is stored in a file with an extension of .xaml. The following snippet of XAML adds a ingle button to a grid:
<Button Name="myButton" Width="130" Height="35">
This is a Button
This XAML creates the following output when displayed:
What if we wanted to add an image inside the button? This is easy to accomplish in XAML:
<TextBlock VerticalAlignment="Center" Margin="2">This is a button</TextBlock>
The updated XAML produces the following:
As you can see, most of the attributes in the XAML are easy to understand: Width and Height, for example. The basics are accessible enough for any designer to manage; more technically oriented designers can go deeper with XAML for additional control of UI elements.
So how does XAML help to separate the UI from the logic? Notice there is nothing in the XAML snippet that relates to event handling, which is still mostly handled in the code along with anything logic oriented. The look and feel of the user experience – ranging from the location of controls to rollover animation effects - is all handled in XAML. Designers can even control button- click behaviors as long as the associated events affect UI elements that are also defined in the XAML.
A single attribute of the Button creates a bridge between the UI and the logic, which enables the separation. The ‘Name’ attribute (in this case “myButton”) enables a developer to handle all events for the button, for example the click event. A developer makes changes to the click event in the code file; a designer changes the look-and-feel and location in the XAML file. The Name of the button in the XAML or the code file must remain unchanged by the designer or developer.
Many simple design tweaks such as change of location and appearance are easy with XAML, but these examples only begin to tell the story of XAML and WPF. In future posts, I will describe how designers use animation, control templates, data binding and styles in XAML to take full control over the user experience.
For a more comprehensive examination of XAML and the designer/developer relationship, check out this article by Karsten Januszewski and Jaime Rodriguez.
Like many companies, we are being more mindful of our expenses. One challenge this creates is fewer opportunities for face-to-face interaction with our peers from across the company. With design sites on three continents we're constantly on the lookout for tools than support the engagement of remote teams in creative activities such as brainstorming.
We recently tested MindMeister from MeisterLabs. It is a Web 2.0 mind mapping tool that supports real-time collaboration between remote participants. Setting up an account was a snap, as was creating our first map, and giving team members access. With a group of 14 participating in a brainstorming exercise, the phone lines fell silent as team members became engrossed in adding and then organizing concepts. Surprisingly, there was little lag to interrupt our work; the tool supported the flow of the exercise well.
In three 15 minute brainstorming sessions, we generated over 300 ideas. I think we were all pleased with our first outing with the tool and expect to spend more time exercising its capabilities. What new tools have your teams been using to support design collaboration between remote workers? Let us know.
We at Autodesk are pleased to be having our largest presence ever at SIGCHI in 2009. Not only are we a Champion Sponsor (more on that at a later date), but we have six people presenting this year on a variety of topics.
Lillian Smith and Greg Demchak are showing Project Chicago: Green Researchin the Video Showcase on Tuesday, from 6:30 to 8:00pm. Their video showcases a highly graphic, interactive technology concept for evaluating water and energy reduction, indoor environmental quality, and carbon footprint impacts and giving designers an immediate sense of the results of different building designs. This proposed sustainability dashboard concept is demonstrated on a 6’x3’ touch screen to explore its potential use as a collaborative tool. The dashboard is presented by Autodesk as a technology concept; it is not a commercially available product.
Lynn Miller and Desiree Sy are holding an Agile User Experience SIG on Wednesday from 9 to 10:30am. The goal of this SIG is to draw upon the shared experience of UX practitioners to uncover the best practices for agile user-centered design which facilitate optimal product development.
Lira Nikolovska, Greg Demchak and Matt Jezyk are presenting two papers as part of Designing for Discovery on Wednesday from 4:30 to 6:00pm. The first paper, Simplified User Interfaces for Design and User Testing of Architecture Software Applications, describes the value of creating simplified user interfaces for use in early conceptual design phases. By simplifying the interface, the team was able to solicit specific feedback about new tools without the overhead or pre-conceptions associated with using an existing software platform. As a result, the team was able to iterate rapidly on specific problems. The second paper, Understanding User Needs for Conceptual Design Phases of Architecture Projects, describes design research methods used to understand user needs, identify user requirements and create new conceptual design workflows for an existing architectural software application.
And last but not least, Autodesk employee Chauncey Wilson is a member of the organizing committee for the User Experience and Usability community.
It was Monday, January 5th, 2009. Business had just resumed after a two-week break and Product Design was reviewing short-term and long-term goals. One outstanding item from 2008: “fill-in R2 Marketing Requirements Document (MRD) gaps”. Faced with such an open-ended assignment we did what any good corporate citizen would do: we scheduled a meeting.
This is the story of how the Process and Power Product Design team went from 0 - 60 in Contextual Inquiries in just two weeks.
The Process and Power team hadn’t conducted contextual inquires before. Since the group was originally launched as a start-up within a larger organization, the Product Design team often found itself in an ad-hoc rapid process with Software Development (SWD) – working frantically to develop the right amount of specificity to keep the SWD machine cranking and the goal of first release clearly in sights.
And so our first meeting to discuss Discovery user research was small, just three people. We met early Tuesday morning to discuss putting together a user research plan to present to Product Management. It became apparent quite quickly, though, that any research done now should cover the entire MRD – not just gaps.
And so another meeting was called, the same day. This one included another designer and Product Management. In a rapid-fire session the team reviewed research options: phone interviews, surveys, site visits. Having a diverse team – ranging from two members with substantial domain experience (Ursula Sadiq and Damian Willcox) to a member with an advanced degree in Human Factors (Jake Pierson) – the group agreed that it was time to document user goals and needs via an objective, and neutral, methodology.
We decided that contextual inquiries would be the best place to start. After the in-person visits, phone interviews would be organized to validate the findings with a greater user population.
The MRD was to be completed by the end of January – research needed to begin the following week. Would it be possible to meet with users on such short notice? Someone wondered how many users we would need to meet with. “Five to eight?” offered another.
“We could probably find enough companies here in the bay area,” suggested someone.
“But do we really want to limit our research to the bay area in the beginning?” considered another.
“What about Houston? It’ll be easy to recruit users in Houston.”
“If we go to Houston we should consider Calgary – and if we go to Calgary, Damian can be there too.” (Damian is located in Calgary.)
“Can we travel?” asked someone (thinking of soft-shelled crab in Houston).
Action items were assigned: for one, a follow-up conversation regarding budget; for another, a spreadsheet of our MyFeedback (beta customer) users; for another, setting up the interviewing template for the contextual inquiries.
We met again the next day, this time with the entire Product Design team and Product Management. Budget had been approved – visits were to be planned in Calgary and Houston. Contacts in Houston and Calgary were quickly identified. The team discussed the characteristics and job titles of applicable users and wrote the recruiting screener. More action items were assigned and the team disbursed: calls needed to be made and training set up.
Thursday and Friday found the group recruiting users, organizing schedules, gathering supplies, and booking travel. By the end of the week the team had scheduled eight site visits in Calgary and Houston for the following Tuesday, Wednesday, and Thursday. Steve Arnold, Senior Product Designer for Platform Services, gave the team an overview of Contextual Inquiry interviewing process and best practices. In a just a week’s time, we were ready to go.
Following the visits – and now back in our own office - we spent two weeks organizing and aggregating the data using an affinity diagramming method. The team worked together, meeting daily to review the findings, discuss the merits of each, and categorize them.
Having the entire team so familiar with the findings made subsequent steps easier. The group decided to focus first on what the users needed, prioritizing how it needed to be built to later investigations to take place during Conceptual Design. When the group focused solely on what need to be built, features fell out of the research quickly and easily and Feature Briefs were assigned to capture the what while still fresh.
The team has completed the first drafts of Feature Briefs to be reviewed by Product Management. Ursula has also created an exceptionally detailed Ecosystem Diagram of the Plant Industry based, in part, on our research.
The affinity diagrams have given the hallway some very colorful new wallpaper.