8. Customers are libraries worldwide – academic, public, business, governmentUsers range from elementary school students to scholarly or scientific researchers.
20. The transformation Develop a single, unified search platform Become a unified, global UXD team Transfer from a waterfall development model to an agile model Design Business Case Deploy Define Functional Design (prototyping, JADs usability testing ) Business requirements Technical Design Functional requirements Develop Implementation Design documents Test Release
21. Process Before & After Transforming the ProQuest User Experience
22. Our process – before Business Case Business requirements Functional Design Technical Design Functional requirements Implementation Design documents UXD processes Test Release
23. Our process – introducing agile User research? UXD role? Prototyping? Business owner prioritizes product backlog Shippable product build 2 week development sprints Sprint backlog Usabilitytesting? Documentation? IA?
24. Our process – UXD role after agile Same role Different framework for collaboration (Scrum and user stories)
25. Our process – design activities after agile Incremental Iterative Just enough – just in time
26.
27.
28. Our process – user research after agile Multiple approaches to user research Formative usability testing Prototype and functioning system Remote usability testing – quick spin up Findings feed into next sprint Summative usability testing (long lead time) See how discrete functionality integrates to whole experience Findings feed into next release Customer feedback Demos Test partners User observations
29. Design Before & After Transforming the ProQuest User Experience
30. High level architecture - challenges Before - selecting databases Many products = how do users select? Many starting points Cross search vs. specialized functionality
31. High level architectureMultiple access points – home, subject area, database product ProQuest Search Home Arts & Humanities Business Natural Sciences & Technology <Subject Area> ABI A&H FT AFSA Product EntreP BHI Illustrata Product HAR IIMP NTIS Product
45. How successful was the transformation? Reactions from a range of users have been favorable “This would be really helpful for school. I'd definitely be a fan. Where can I find this?” – High School Student “I know how to use search engines and ProQuest is easy.” – Undergraduate student “While it looks more like the familiar interfaces that I’ve gotten accustomed to on some competitors’ platforms, ProQuest does offer some considerable improvements on them. I think ProQuest will be the new standard to emulate with the improvements it offers.” - Librarian
46. How successful was the transformation? Reactions from a range of users have been favorable We are now one global UXD team.
47. How successful was the transformation? Reactions from a range of users have been favorable We are now one global UXD team. Agile is our development method.
48. Lessons learned Be aware that agile can lead to feature creep. It is important to prioritize features. Don’t lose sight of your personas. Don’t over design – do the simplest thing that can possibly work. You can use agile to your advantage. Opportunity to rework. Opportunity to see features working earlier. User test frequently. Designing for both novice and expert searchers is challenging but possible. Advanced features are available but not obstacles. Design for discovery.
49. Transforming the process and team Separate UXD teams have come together into one global team that leverages the skills of the varied team members. UXD has gone from not fitting into the agile process to playing an integral role. It is still a challenge making time for testing and research. Our agile design process continues to evolve.
Introductions!Here to share our experience transforming ProQuest search. This transformation involved creating a next generation search interface to replace the search interfaces of three of our legacy platforms. This was a complex redesign The largest project that has ever been undertaken at ProQuest Worked on by an agile team across three different continents.
What we will cover today:I will share some Background info = to provide contextSerena will go over process before & afterbecause we found that over the course of the project, not only has the search experience been transformed but the ProQuest User Experience Design team and our processes have been transformed as well so 3. Chris will provide a sneak peak at the next generation platform and will share some of our design thinking4. I will wrap up with lessons learned5. Time for questions
For those of you that aren’t as familiar with ProQuest
ProQuest is made up of a lot of different units that are engaged in many different areas related to information.
About aggregation & databases: One of the largest areas of focus is the aggregation of content form publishers which we bundle up and sell as products referred to databases in our industry. We make these databases available via search interfaces such as the one I am currently showing.The ProQuest search platform: One of our legacy search platforms which is simply referred to as ProQuest. Tends to have more general research content Mainly used by college and university students Allows the users to search across all of the content to which their library subscribes.
No effort is made to bring the two organizations together.
Specialist, niche products. Generally search across one specific content set. Generally historical content.Highly visual in their design.
Each Chadwyck-Healey product has its own UI almost like a web-site with its own identity including imagery, colors, fonts. They also have custom search screens with product specific fields.
Both ProQuest and Chadwyck-Healey maintain their own UXD teams.
CIG already owns CSA which provides the CSA Illumina search interface which is very similar to ProQuest, searches across many databases at once. Users are slightly more advanced due to the more specialized content that is available, for example scientific literature.
Decision is made to create a more unified organization: Team and platform consolidation begins Move from being separate entities to being one organization – one platform, one development team.
Search content from ProQuest, CSA Illumina and Chadwyck-Healey products Merging the aggregated and the product specific Content is variedMeet the varied needs of users of current platformsMaintain what is loved about current platforms
Combine the ProQuest and Chadwyck-Healey UXD teams and supplement with team members from India. 3 continents, 3 time zones, 3 cultures All had different ways of working & processes as well as different perspectives that needed to be aligned28 UXD team members to 60+ developers
I am now going to hand it over to Serena who will tell you more about some of the processes we created and used in this transformation.
Prior to the start of this multi-faceted transformation, the UXD teamWas the primary advocate for the end userServed as a bridge between the business and technical teamsWorked primarily during a dedicated design period on tasks such as JAD sessions with cross disciplinary teamsPrototypingUser testing on those prototypesDelivered multi-page design spec at the end of the design phase
1 month before we began development of the largest, most complex project ProQuest has ever seen, we were informed that we would begin using agile development process. There were many unanswered questions for us: What would be the role of UXD in new process? (Business owner would be entering requirements in the backlog, when would we define and design?) When would we do user research? Would there be any need for prototyping? How would we approach big-picture tasks such as designing the information architecture of the new platform? How would we fit in usability testing?What, if any documentation, would we need to produce to support the project? (There was a perception going that we would do just in time design – “skipping” all the “burdensome” documentation tasks.)
As we began our agile experience, our process developed over time in an agile manner, raising needs and designing processes to meet the need and reworking when necessary. What would be UXD role in new process? After a few trialsSame roleServed as advocates of the end userStill a strong need for us to serve as a bridge between the business and technical teams business was entering stories, but not at the level of detail developers could estimate or work on, there was still a need to provide further definition. Different framework for collaboration > Used a scrum process with daily standup meetings with entire development team>> Due to size and location of team used online tool to create, prioritize and manage ‘story cards” or user stories.
Same fundamental activities – they just became Incremental (shorter cycles)Designing in small chunks (specifying things that could be developed in one or two days)“minijads” happened with ad hoc developer discussionsDiscovered we did need documentation, but we kept it to just enough (for us,annotated wireframes and user stories) – provided just in time.IterativeHand over partial or incomplete designsRevisit, refine, refactor (didn’t always make developers happy, but produced a much better end product in most cases)
Not without challenges and tensions: Designing piecemeal tends to keep you submerged in details. It can be a challenge to keep the big picture in focus. This meant we had to develop ability to do “bi-focal design” Attention to framework, architecture, big picture and what was coming in the future (click) -- sometimes working outside and ahead, sometimes looking back and reworking designs -- taking all new elements into consideration (We had to carve out time for this, no one told us to do this.) Deliver detailed design on very small aspects of system. (click)A related challenge was how to ensure our team of 28 different uxdcontributers -- all working incrementally and iteratively – shared the same big picture and could collectively build a unified and coherent end user experience? (Met this challenge with lots of planning, and lots of group reviews, and occasional re-factoring.)
One of the tools we found to help with these challenges was personas. We had personas as part of our toolkit before adopting an agile method, but found that we really started doing more focused persona-driven design to navigate the new terrain of agile development. Fortunately, we had been conducting extensive user observations in the months prior to the beginning of this project, so we had sound user research to base these personas on and also to prioritize them (our primary persona is the undergraduate student who is an intermediate – level searcher). How did persona’s drive our design? Helped over and over again in conversations about business requirement priorities In Agile projects, the ease and speed of going from requirement to working code, along with focusing on a small pieces of functionality at a time, creates a risk of feature creep – personas became a check point against this. Finally, they helped guide day to day design decisions. One of the complexities of the project was to balance the needs of varied users from community college students to niche researchers. > Persona exercise helped us with trade offs and challenge of transforming 3 distinct approaches in to a single approach. Example: Advanced search screen – who is it for? Complex for expert searcher or less daunting to support intermediate searcher (primary persona). Significant internal debate about who uses advanced search. But we knew from usability testing that our primary persona did use it, if needed.
Speaking of user research . . . . The last process transformation I’ll discuss today is user research and usability testing. How would we fit in usability testing?When would we do user research? Would there be any need for prototyping? Waterfall method – 1 opportunity to test, often difficult to fit in, depending on length of design phase. No latitude to change designs after the spec was delivered.Agile development - Challenges Difficult to fit in, we had to ensure it happened (e.g. had to work ahead enough to have resources available to do it, time it so enough time to feedback. )Had to be flexibleBenefitsMore iterations of testing (we did have longer window before launch than most)Able to incorporate multiple approaches to user research which gave us more opportunities to react to what we learned. Approaches include: formative usability testing used both prototypes and functioning system Remote testing - quick spin up worked well for us Often able to react to findings by the next sprintSummative usability testing see how discrete functionality integrates both big picture and discrete findings (complementing our bi-focal design approach) Some findings into next sprint, but other feed into next release.Customer Feedback (demos and test partners) – usually on alpha and beta versions of productUser observations - beginning to plan for these, particularly as we are asked to design for new user groups. Section Summary: We would have come up with a different --- I think less successful end product had we not made the transformation to an agile design process. I’ve described process story, now chris will discuss designed that were a result of thes process.
MANY features included – this is a high level tour with examplesHigh level IADesign before / after
Major architecture challenge: 3 platforms – MANY products (need to integrate platforms)User needs – make sense of db selection, understand what they are searchingTarget user = Undergrad
Added a new level of hierarchy – subject areasAdaptable - configurable and customizable by each institution. Early feedback from users and reviewers suggested we needed to reflect the subject areas throughout
Narrowing by subject areas for selecting collectionsManaging the length
The search page- challengesTarget the primary persona – undergraduates.Be sure to serve other audiences too!Make it modern - simplify!Feature subject area / product hierarchy.Need visual appeal… but not images for their own sake.Subject areas – not present at all in PQ, used as limits in CSA
Many tensions to resolveNovice vs advanced – but needs to work for both. Both often start broad.Subjects areas – how to they relate to the search boxVisual balanceKeep it clean, more like web searchBack story – tested versions with graphics too prominent, checkboxes on subject areasReduced number of limiters/options - only the MOST important options for target audienceSubject areas – used for selecting, navigating, browsing – not as limits
Could be site entry pointReveal options that apply especially for this type of content – example: exclude reviewsEducates users about databases – novice users don’t necessarily know what they are searching, encourages narrowing
Advanced Search ChallengesWho is it for? Those who need assistance with advanced queries or power users?Combine approaches from legacy platforms.Making sense of a large amount of features for one page.Make it adapt to the all the combinations of databases that can be searched.
Kept the power features from each legacy platform – browsable indexes, 3 line search form, limitsCompromise approach between CSA and PQ platformsUser goal – teaching tool for librarians, but needs to be self teaching (minimal instruction)Additional search modes
Challenges-ModernizeWeb examples – kayak – even MORE facetsTrend to narrow using facets on results, rather than on search form-Where to fit all the options we hope to provide without taking attention away from resultsPQ legacy interfaceTabs as limits – popular but problem with screen real estate.Suggested topics (smart search) – legacy platforms had a start on facetted search
Right panel - In testing, users preferred limiters on the right so they could focus first on results.Icons instead of tabs for doc types.Preview – to help users select docs without leaving the results page.Powerful facetted options for narrowing – changes depending on products being searchedExamples - Date slider, source types, subject terms
Marked list vs. My Research.Saving between sessionsSocial features missing
Saving between sessions.Combine personal and social features into a single area.Introducing new features, including social: tags, lists, and more.Initially we thought it was only for advanced users. During user testing even more novice users were interested in using it. Having personal accounts is common on the web now.Providing incentives for users to discover and use accounts.Transition to Joanna’s lessons learned
First customer release is in 3 weeksFrom user reactions, we know that we have been successful in creating an interface that meets the needs of our varied users
Transforming to agile and adopting new process together helped create a unified UXD team
![Our talk ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)