Restructuring PKP's Approach to UX
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Wright, Nate
Software that provides a good user experience (UX) is often easier to promise than deliver. For years, PKP's flagship journal publishing software, Open Journal Systems (OJS), received poor reviews for its dense user interface (UI) and low design quality. To turn things around, PKP had to say "no" more often, manage an overwhelming stream of feature requests, devise simple heuristics to set priorities, and seek out more effective ways to get user feedback. Learn about particular challenges faced by PKP as the providers of a distributed platform and how they're working to balance the needs of a diverse set of users. Includes advice for those who want to prioritize UX work on a budget but don't know where to start, or who want to advocate for better UX development processes in an organisation that doesn't yet prioritize it.
 So, I'm going to start with a little bit of a personal story about what was going on with our joint PKK in terms of design and usability stuff, particularly what kind of problems we had and a little bit of history about how we got into those problems and then I'm going to talk a little bit about how we went about changing that system and putting it in place of things that helped us make some usability changes. So, I joined PKK in April of 2015 and I was hired as a software developer, so I wasn't hired as a designer, but I had a background in the WordPress product space where design and aesthetics are really a key part of selling the product, so I came to a perspective where that was really a critical part of the whole process. So, in April 2015, and OJS3 had just been re-talented and this was a complete ground-up rebuild of OJS and it was really meant to be a big leap forward in terms of bringing the application up to a kind of modern standard and it had just reached Apple, which means this was kind of the first fully functioning version of it and this is what it looked like. So, it's obvious that no designer was involved in this and they would wait, no designer was within 100 miles of this. It's really like a past days design here. So, in this screen, I can actually see four different button styles, so these are buttons, these are buttons, these are buttons, and those are buttons. So, none of them actually looked like each other and none of them actually looked like buttons. So, this is very much how I felt. I think it's how many of you felt at different times with different kinds of OJS software, but what I'm going to talk about is why or pretty well why did we get here? So, how did we get to a situation where OJS3 had got to do a complete ground-up rebuild but no designer had been involved in this project at any point in the process. So, there's a few things that I think were playing here. One is PKP and its software really emerged after doing itself a culture of the early 2000s when people really didn't talk about usability, they didn't talk about software being intuitive. And users didn't really expect that either. You got on and you figured it out one way or the other. It's very different today where users don't understand it immediately, they get upset. But back then, it wasn't really that important. Another big problem is that within the team, which was much smaller than it is now, there's really a lack of understanding of what UX was, what led to UX problems, particularly what kind of strategies led to resolving UX problems. And then finally, design itself, as you can see, is kind of unapportable. It'd be nice if we could make this look nice and everything, but we just can't believe we're that important. The most important thing, though, that contributed to this was feature-free. Feature-free is what happens when you say yes to everything. And that's a problem because... I think I just turned it off. There we go. With feature-free, the more you do, the worse it's going to be. That's just a basic fact of all software. All software has to anticipate and manage feature-free. And PKK just really struggled to do this. And there's a few reasons why that happened. First of all... Good morning. Software for PKK is really a means to an end, and that is to make knowledge public. So from the very beginning, if OJS did not have a feature, and this feature was necessary to migrate from a closed publishing system into an open publishing system, then OJS, in PKK, in particular, felt a real responsibility to make that happen, to make it happen as soon as possible. So it's not the kind of VC-funded startup where you can build the smallest possible app and then just plow money into a customer acquisition. It really mattered to them that the software did what people needed it to do. So that led to pressure for new features. The other big thing that happened was early on, PKK became... OJS became really a critical part of the publishing infrastructure of the global south. And so, when we think about PKK as not just software, but as a mission-driven organization, it was really important to serve that need. And what that meant is that very early on, we had a massive base of users, and that means we had a whole lot of diverse needs and feature requests emerging. And then finally, and this is really important, is that frankly, PKK didn't have the resources to invest that much in all of these features. So it was able to sustain the product and keep it moving forward, but it didn't have the resources to refine it. PKK knew that they had problems with UX. There was a recurring problem, and so, in terms of time, I'll just go past this, but basically they did a UX review, and the UX review basically says start over. The problem with that is, if you're a small team, and you just invested a massive amount of time in the rebuild, a UX evaluation that tells you to start over is not helpful. In fact, it actually puts greater barriers on making improvement because all of a sudden, it just seems insurmountable. Not only do we not have resources to make innovative improvements, but we definitely don't have resources to just start over again. So how do we turn things around? Culture process, resources, I won't create a wrong, I'll just go straight to them. So when I joined the team, I don't have any professional training in design, I don't have any academic training in user experience or anything like that, but because of my background, I knew the things were just going off the rails. And so I came to the team and I just said, look, I don't know exactly how we get there, but I do know that what we're doing is wrong, and I can do better than this. And so shortly before we hit beta, I got the team to let me just do a really quick visual redo of the editorial back end. And this really didn't address all of my usability issues, it was really just kind of saying, let's bring at least a basic design overhaul to this to really show what can be done. And this was really important for two reasons. One is that I think it overcame a certain inertia within the team, and it set in especially as a result of that UX review where it just felt like doing UX was just impossible, it was this huge hurdle. But making this change really demonstrated that actually without an enormous amount of work you can put in place something, you can actually make a pretty significant improvement. And the other important thing it did was it really established my bona fide to get into the team. And that allowed me to start advocating for more and more resources to spend time on this kind of stuff. It didn't, however, solve the problem with feature creep. We still had a lot of things coming in. And it set up a situation where there's a lot of tension within the team because the team would come and say, oh, we need to do this, we need to do that. And I would say, no, please, please let's not add another feature. We have enough problems, we're barely holding our heads up to water, can we please not keep adding more problems to something? Unfortunately, it turned me into a bit of a kind of droney gatekeeper. This wasn't really sustainable mostly because I was new to scholarly publishing. So I wasn't really the person to be making those decisions about what features are important and what features aren't and how do we balance that need to find what we have and as well as serve the population we have. So we had to do a process where I thought like I was training the team on what usability in the racks was and the team was training me on what scholarly publishing was. So I tend to think of usability in a fairly straightforward way. The simpler your application is, the easier it is to make it intuitive. The more complex it is, the more confusing it's going to be. And usability, UX work, that kind of stuff. You could maybe shift the needle a bit on this, but the raw material of what you're working with is going to involve a certain amount of complexity or simplicity. So when we look at commercial actors, which is the market I came from, not Twitter or Instagram, but just generally consumer-facing products, they're furiously pushing the simplicity of their application. There's a very limited set of things that you can do on Twitter or Facebook or Instagram or whatever. They do that deliberately because they know the simpler that they can make their application, the more intuitive it will be and the easier it will be for them to onboard new users. But when we talk about scholarly publishing, we're in a very different realm. Scholarly publishing is inherently very, very complex. And that means that in scholarly publishing, the application is built for it, but by their nature, it's going to be a lot more confusing. And scholarly publishing is getting even more complex than it is now. So as well as all the stuff we've been dealing with for years, like DOIs, URNs, depository places, that new scheme is coming up like credit, we have new problems we're trying to solve like how do we manage research software, how do we credit research software, how do we manage all these different kinds of review processes that people want to explore, all this kind of stuff. So, scholarly publishing is getting much more complex. And from a product or service design perspective, this is very much moving in the direction of action. So for me, my perspective is, let's move up into the left. But much of the scholarly publishing community is basically kind of moving things down into the right. So this is very much how I felt for the last four years. And again, it created this tension and it wasn't very productive. I mean, we were in this process of shifting the culture from a yes culture to a no first culture, and that's been really important, but at the end of the day, it's not enough just to say no to everything, we actually got help to manage this stuff. So for that, we needed to institute a process. And we didn't go about, we didn't move forward to the clear plan about this is exactly the steps we're going to take. We started out with one thing here, one thing there, and we ended up with what seems like a pretty good process for us. And it started with user testing. And I won't play the video, but I will share the slides after. If you want to see it, it's a video about similar live user testing that's on your best. The user testing is really important in kind of shifting, instead of just hearing from other people, we want this, we want that, or whatever, we're actually going out and testing things that we already did, things that the platform, features that the platform already had. And we were looking at what was already confusing and not very user friendly, and not allow us to kind of start thinking about priorities. So we would take all of the notes that we gathered from the user testing, and we would dump it into a big spreadsheet, and we would assign priorities. The top one, which thankfully we don't have any now, was critical. And what that meant was, this is either broken, or it's so confusing that people aren't even able to use it. So this is actually quite common. We had lots of features in the system that we spent a lot of time in money building, but no one could actually use them because they were so confusing. So we just had everything kind of ranked from sort of most critical to the lowest priority stuff. This kind of started negotiating in terms of how resources were, how like new development work was being parceled out, where resources were going. There were kind of three questions that we would ask. I mean, I say that like we have a really formal process in the deposit, it was mostly me asking these questions at first. And it was really so, if someone comes to us with a new feature, I want to ask the question, is this new feature actually more critical than some kind of UX priority we have? And when I talk about critical, what I mean is, are there people who actually cannot publish with our platform because this feature is mission-admissive? Because we did have UX priorities that were actually preventing people from using the platform. I mean, there's probably people in this room who have sat down with OJS and unsuccessfully tried to publish something. I know when I joined the team, I spent about a week trying to figure out how to publish a submission, and I couldn't actually get ahead to ask somebody. So the second question is, who's actually going to benefit from this new feature? Oftentimes we hear a lot about new feature requests because that 3 to 5% who really need that feature, they're the vulnerable ones. They're up on the forums, they're letting us know, but what we don't hear from people is, I do this thing every day like a sign of a reviewer, and it's really annoying that I have to do this sort of thing. So the user testing and the priorities we set there really gave us a way to kind of evaluate how many people are going to use this new feature, versus if we invested time in saving people time during the regular workflow, people would get a benefit from that. Another last question, which is the hardest one to ask, to answer, but really involves kind of this culture change within the organization, is thinking of features as having an inherently negative impact on the software. So again, when we think about that simplicity, complexity, and access, every new thing that we provide is going to be a tax or like a burden on everyone who doesn't use that feature. So when we're thinking about what features go into chords, we actually need to evaluate not just who's going to use it, but who's not going to use it and how is this going to impact them. So, yeah, it's a completely different environment today, thankfully. Once we had this process, we were able to kind of see iterative gains in the usability stuff, and that's helped make the argument for devoting more resources with the team. So today we've got Israel, who you'll hear from next, who is going to be coordinating UX research and evaluation stuff. The community is heavily involved in the user testing, both running the testing as well as participating in it, as well as this prioritization thing, which is really important. Community partners have really helped us identify, not just like one of the 20 things you want from RJS, but you can only have one or two. What are those one or two things you want us to work on first? And that's been really important. And as I said, the community's been really good about that. It's hard to be told we're not going to do something that you want us to do. But the community's been really understanding about us, figuring out our priorities, and then making sure that we're focusing on that. What we don't do very well is actually communicating those priorities back to the team, but we can work on that. And today we've got about a half a dozen people involved in research, design, implementation, and iteration of UX. And that's a huge improvement, because when we started it was really just me doing stuff. But thinking back to Tara's talk yesterday, it's really important that we have more voices involved in this process, and it isn't just me kind of desperately trying to hack things together. And most of those half a dozen are in this room today, actually. And then the biggest thing is that nowadays when we're thinking about new features and things, the design and UX perspective is actually involved fairly on in that process. So it used to be that features sort of arrive, and then we desperately try to make them usable in some way. But nowadays we're actually there where the features being, what happens if we can say, maybe that's not even featured this way, let's think about it in another way and be more iterative. And that's been really important part of the process. I'll go ahead and skip this slide for time, but I just want to say if you're in an institution that maybe doesn't value UX, or because the field has the resources to do UX, I think one of the things you can learn from us is to start small and create some kind of proven impact, and that will give you leverage to start actually negotiating the resources to do this sort of stuff. So that's me.
 So, I'm going to start with a little bit of a personal story about what was going on with  our joint PKK in terms of design and usability stuff, particularly what kind of problems  we had and a little bit of history about how we got into those problems and then I'm going  to talk a little bit about how we went about changing that system and putting it in place  of things that helped us make some usability changes.  So, I joined PKK in April of 2015 and I was hired as a software developer, so I wasn't  hired as a designer, but I had a background in the WordPress product space where design  and aesthetics are really a key part of selling the product, so I came to a perspective where  that was really a critical part of the whole process.  So, in April 2015, and OJS3 had just been re-talented and this was a complete ground-up  rebuild of OJS and it was really meant to be a big leap forward in terms of bringing the  application up to a kind of modern standard and it had just reached Apple, which means  this was kind of the first fully functioning version of it and this is what it looked like.  So, it's obvious that no designer was involved in this and they would wait, no designer was  within 100 miles of this.  It's really like a past days design here.  So, in this screen, I can actually see four different button styles, so these are buttons,  these are buttons, these are buttons, and those are buttons.  So, none of them actually looked like each other and none of them actually looked like buttons.  So, this is very much how I felt.  I think it's how many of you felt at different times with different kinds of OJS software,  but what I'm going to talk about is why or pretty well why did we get here?  So, how did we get to a situation where OJS3 had got to do a complete ground-up rebuild  but no designer had been involved in this project at any point in the process.  So, there's a few things that I think were playing here.  One is PKP and its software really emerged after doing itself a culture of the early 2000s  when people really didn't talk about usability,  they didn't talk about software being intuitive.  And users didn't really expect that either.  You got on and you figured it out one way or the other.  It's very different today where users don't understand it immediately, they get upset.  But back then, it wasn't really that important.  Another big problem is that within the team, which was much smaller than it is now,  there's really a lack of understanding of what UX was, what led to UX problems,  particularly what kind of strategies led to resolving UX problems.  And then finally, design itself, as you can see, is kind of unapportable.  It'd be nice if we could make this look nice and everything,  but we just can't believe we're that important.  The most important thing, though, that contributed to this was feature-free.  Feature-free is what happens when you say yes to everything.  And that's a problem because...  I think I just turned it off.  There we go.  With feature-free, the more you do, the worse it's going to be.  That's just a basic fact of all software.  All software has to anticipate and manage feature-free.  And PKK just really struggled to do this.  And there's a few reasons why that happened.  First of all...  Good morning.  Software for PKK is really a means to an end, and that is to make knowledge public.  So from the very beginning, if OJS did not have a feature,  and this feature was necessary to migrate from a closed publishing system  into an open publishing system,  then OJS, in PKK, in particular, felt a real responsibility to make that happen,  to make it happen as soon as possible.  So it's not the kind of VC-funded startup where you can build the smallest possible app  and then just plow money into a customer acquisition.  It really mattered to them that the software did what people needed it to do.  So that led to pressure for new features.  The other big thing that happened was early on, PKK became...  OJS became really a critical part of the publishing infrastructure of the global south.  And so, when we think about PKK as not just software,  but as a mission-driven organization,  it was really important to serve that need.  And what that meant is that very early on, we had a massive base of users,  and that means we had a whole lot of diverse needs and feature requests emerging.  And then finally, and this is really important,  is that frankly, PKK didn't have the resources to invest that much in all of these features.  So it was able to sustain the product and keep it moving forward,  but it didn't have the resources to refine it.  PKK knew that they had problems with UX.  There was a recurring problem, and so, in terms of time, I'll just go past this,  but basically they did a UX review, and the UX review basically says start over.  The problem with that is, if you're a small team,  and you just invested a massive amount of time in the rebuild,  a UX evaluation that tells you to start over is not helpful.  In fact, it actually puts greater barriers on making improvement  because all of a sudden, it just seems insurmountable.  Not only do we not have resources to make innovative improvements,  but we definitely don't have resources to just start over again.  So how do we turn things around?  Culture process, resources, I won't create a wrong, I'll just go straight to them.  So when I joined the team, I don't have any professional training in design,  I don't have any academic training in user experience or anything like that,  but because of my background, I knew the things were just going off the rails.  And so I came to the team and I just said,  look, I don't know exactly how we get there,  but I do know that what we're doing is wrong, and I can do better than this.  And so shortly before we hit beta,  I got the team to let me just do a really quick visual redo of the editorial back end.  And this really didn't address all of my usability issues,  it was really just kind of saying, let's bring at least a basic design overhaul to this  to really show what can be done.  And this was really important for two reasons.  One is that I think it overcame a certain inertia within the team,  and it set in especially as a result of that UX review  where it just felt like doing UX was just impossible, it was this huge hurdle.  But making this change really demonstrated that actually without an enormous amount of work  you can put in place something, you can actually make a pretty significant improvement.  And the other important thing it did was it really established my bona fide to get into the team.  And that allowed me to start advocating for more and more resources to spend time on this kind of stuff.  It didn't, however, solve the problem with feature creep.  We still had a lot of things coming in.  And it set up a situation where there's a lot of tension within the team  because the team would come and say, oh, we need to do this, we need to do that.  And I would say, no, please, please let's not add another feature.  We have enough problems, we're barely holding our heads up to water,  can we please not keep adding more problems to something?  Unfortunately, it turned me into a bit of a kind of droney gatekeeper.  This wasn't really sustainable mostly because I was new to scholarly publishing.  So I wasn't really the person to be making those decisions about what features are important and what features aren't  and how do we balance that need to find what we have and as well as serve the population we have.  So we had to do a process where I thought like I was training the team on what usability in the racks was  and the team was training me on what scholarly publishing was.  So I tend to think of usability in a fairly straightforward way.  The simpler your application is, the easier it is to make it intuitive.  The more complex it is, the more confusing it's going to be.  And usability, UX work, that kind of stuff.  You could maybe shift the needle a bit on this, but the raw material of what you're working with  is going to involve a certain amount of complexity or simplicity.  So when we look at commercial actors, which is the market I came from, not Twitter or Instagram,  but just generally consumer-facing products, they're furiously pushing the simplicity of their application.  There's a very limited set of things that you can do on Twitter or Facebook or Instagram or whatever.  They do that deliberately because they know the simpler that they can make their application,  the more intuitive it will be and the easier it will be for them to onboard new users.  But when we talk about scholarly publishing, we're in a very different realm.  Scholarly publishing is inherently very, very complex.  And that means that in scholarly publishing, the application is built for it,  but by their nature, it's going to be a lot more confusing.  And scholarly publishing is getting even more complex than it is now.  So as well as all the stuff we've been dealing with for years, like DOIs, URNs,  depository places, that new scheme is coming up like credit,  we have new problems we're trying to solve like how do we manage research software,  how do we credit research software, how do we manage all these different kinds of review processes  that people want to explore, all this kind of stuff.  So, scholarly publishing is getting much more complex.  And from a product or service design perspective, this is very much moving in the direction of action.  So for me, my perspective is, let's move up into the left.  But much of the scholarly publishing community is basically kind of moving things down into the right.  So this is very much how I felt for the last four years.  And again, it created this tension and it wasn't very productive.  I mean, we were in this process of shifting the culture from a yes culture to a no first culture,  and that's been really important, but at the end of the day, it's not enough just to say no to everything,  we actually got help to manage this stuff.  So for that, we needed to institute a process.  And we didn't go about, we didn't move forward to the clear plan about  this is exactly the steps we're going to take.  We started out with one thing here, one thing there,  and we ended up with what seems like a pretty good process for us.  And it started with user testing.  And I won't play the video, but I will share the slides after.  If you want to see it, it's a video about similar live user testing that's on your best.  The user testing is really important in kind of shifting,  instead of just hearing from other people, we want this, we want that, or whatever,  we're actually going out and testing things that we already did,  things that the platform, features that the platform already had.  And we were looking at what was already confusing and not very user friendly,  and not allow us to kind of start thinking about priorities.  So we would take all of the notes that we gathered from the user testing,  and we would dump it into a big spreadsheet, and we would assign priorities.  The top one, which thankfully we don't have any now, was critical.  And what that meant was, this is either broken, or it's so confusing  that people aren't even able to use it.  So this is actually quite common.  We had lots of features in the system that we spent a lot of time in money building,  but no one could actually use them because they were so confusing.  So we just had everything kind of ranked from sort of most critical to the lowest priority stuff.  This kind of started negotiating in terms of how resources were,  how like new development work was being parceled out, where resources were going.  There were kind of three questions that we would ask.  I mean, I say that like we have a really formal process in the deposit,  it was mostly me asking these questions at first.  And it was really so, if someone comes to us with a new feature,  I want to ask the question, is this new feature actually more critical  than some kind of UX priority we have?  And when I talk about critical, what I mean is,  are there people who actually cannot publish with our platform  because this feature is mission-admissive?  Because we did have UX priorities that were actually preventing people from using the platform.  I mean, there's probably people in this room who have sat down with OJS  and unsuccessfully tried to publish something.  I know when I joined the team, I spent about a week trying to figure out  how to publish a submission, and I couldn't actually get ahead to ask somebody.  So the second question is, who's actually going to benefit from this new feature?  Oftentimes we hear a lot about new feature requests because  that 3 to 5% who really need that feature, they're the vulnerable ones.  They're up on the forums, they're letting us know,  but what we don't hear from people is, I do this thing every day like a sign of a reviewer,  and it's really annoying that I have to do this sort of thing.  So the user testing and the priorities we set there really gave us a way to kind of evaluate  how many people are going to use this new feature,  versus if we invested time in saving people time during the regular workflow,  people would get a benefit from that.  Another last question, which is the hardest one to ask, to answer,  but really involves kind of this culture change within the organization,  is thinking of features as having an inherently negative impact on the software.  So again, when we think about that simplicity, complexity, and access,  every new thing that we provide is going to be a tax or like a burden  on everyone who doesn't use that feature.  So when we're thinking about what features go into chords,  we actually need to evaluate not just who's going to use it,  but who's not going to use it and how is this going to impact them.  So, yeah, it's a completely different environment today, thankfully.  Once we had this process, we were able to kind of see iterative gains in the usability stuff,  and that's helped make the argument for devoting more resources with the team.  So today we've got Israel, who you'll hear from next,  who is going to be coordinating UX research and evaluation stuff.  The community is heavily involved in the user testing,  both running the testing as well as participating in it,  as well as this prioritization thing, which is really important.  Community partners have really helped us identify,  not just like one of the 20 things you want from RJS,  but you can only have one or two.  What are those one or two things you want us to work on first?  And that's been really important.  And as I said, the community's been really good about that.  It's hard to be told we're not going to do something that you want us to do.  But the community's been really understanding about us,  figuring out our priorities, and then making sure that we're focusing on that.  What we don't do very well is actually communicating those priorities back to the team,  but we can work on that.  And today we've got about a half a dozen people involved in research,  design, implementation, and iteration of UX.  And that's a huge improvement, because when we started it was really just me doing stuff.  But thinking back to Tara's talk yesterday,  it's really important that we have more voices involved in this process,  and it isn't just me kind of desperately trying to hack things together.  And most of those half a dozen are in this room today, actually.  And then the biggest thing is that nowadays when we're thinking about new features and things,  the design and UX perspective is actually involved fairly on in that process.  So it used to be that features sort of arrive,  and then we desperately try to make them usable in some way.  But nowadays we're actually there where the features being,  what happens if we can say, maybe that's not even featured this way,  let's think about it in another way and be more iterative.  And that's been really important part of the process.  I'll go ahead and skip this slide for time,  but I just want to say if you're in an institution that maybe doesn't value UX,  or because the field has the resources to do UX,  I think one of the things you can learn from us is to start small  and create some kind of proven impact,  and that will give you leverage to start actually negotiating the resources to do this sort of stuff.  So that's me.
TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_0_131.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_132_251.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_252_935.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_936_1139.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_1140_1187.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_1188_1715.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_1716_2135.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_2136_2471.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_2472_2819.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_2820_3179.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_3180_3515.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_3516_3587.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_3588_3635.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_3636_3839.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_3840_10187.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_10188_10751.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_10752_11987.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_11988_12035.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_12036_16271.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_16272_16415.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_16416_16547.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_16548_16703.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_16704_16835.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_16836_26783.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_26784_26903.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_26904_27143.png TECH_3_1_-_Restructuring_PKP_s_Approach_to_UX_t9rHvu6C2Go_27144_27151.png