Vijay Mathews

W&CO Cofounder

Vijay Mathews

W&CO Cofounder Episode 37

Episode Notes

Episode Transcript

Gary:
Hello, Welcome to Episode Thirty-seven of Design Edu Today, the podcast series discussing what is necessary to be a successful designer in a contemporary, screen-based interactive world. I am your host, Gary Rozanc, Assistant Professor of Graphic Design at the University of Maryland, Baltimore County.

In this episode we will be discussing the interactive design process for the Newark Walks app. The conversation goes into specific details on curating the user’s journey through Newark, how designers and developers work together, who creates the content and the production timeline from initial client meeting to product launch. We also discuss why the Newark Walks was an Android/iOS app instead of a web based app.

Today’s guest is Vijay Mathews who cofounded W&CO. in 2011. Noticing a trend towards mobile applications, Vijay jumped on board and learned quickly the value of a digital presence. For over five years, Vijay Mathews has designed and developed dozens of applications, and has consulted with a wide variety of clients regarding digital strategy, design, and implementation including AIGA, the City of Newark, Harvard University, the Four Seasons, Samsung, and Wolff Olins.

His work has been published in Design on Screen (expected Oct 2016) published by Sandu, the fourth edition of Designing Brand Identity by Alina Wheeler, Numbers in Graphic Design by Roger Fawcett-Tang, the fifth edition of Graphic Design Solutions by Robin Landa. and the second edition of Signage and Wayfinding Design by Chris Calori and David Vanden-Eynden. Additionally Vijay has spoken at the national conference at SEGD, the Fashion Institute of Technology, the International Sign Association conference the Digital Signage Expo, and for the Print Magazine Design Series.

Prior to founding W&CO., Vijay worked as a Senior Designer at Two Twelve, an environmental graphic design firm in New York. Before that, he was an associate designer at WGBH, PBS’s largest producer of web and television content, where he created a variety of print materials for television programs. He also worked as a print designer for Hatch Show Print, a respected letterpress print shop of music and event posters in Nashville, Tennessee.

Welcome Vijay.

Vijay:
Hey, pleasure to be here, Gary; thanks for having me.
Gary:
Oh, I’m grateful that you’re giving me your time once again, continuing the discussion.
Vijay:
Always a pleasure.
Gary:
So, the last time you were on, we discussed the process from beginning to end for creating a website for the AIGA National Design Conference. This time, I want to talk to you about the design and development of Apps, because that’s something you also do and in this case, I want to specifically talk about the Newark Walks App that you recently created. So, just to start off, what’s discussed during the initial client meeting when you are starting App design and development?
Vijay:
Sure, sure and you know, maybe just to give the audience a little context and give them a background on the project, because it kind of informs a lot of the decisions in the process of this particular project. So, this year actually is the City of Newark’s, in New Jersey, their three hundred and fiftieth anniversary so in preparation for this milestone about a year ago the City received a grant from Prudential, which is one of their largest tenants in the City, to create a walking tour to showcase the City’s rich history. Initially it was going to be basically just an interpretive based on the street signage program, so you know, a physical way-finding, placards, interpretive panels in that regard. But during those initial conversations with Merje Design(?) who was the wayfinding design team tasked to create the on street signage program, the idea of an interactive component popped up. I think almost universally everyone was like yeah, that’s a great idea because of what it could potentially represent for the City as well as what it could provide their potential audience in terms of additional content. So, when that idea came into fruition, that’s when we popped up because we did that kind of work for various entities. So, when we first had that conversation with that first client meeting actually, there wasn’t so much a defined scope.

Those initial meetings were designed as kind of key stakeholder engagement sessions. During those meetings we had representatives from al across the City: the Mayor’s office, the Historical Society, Rutgers University, the Tourism Bureau; Prudential of course, the Library, various business improvement districts and basically any other major commercial entity. The reason why was because a lot of these organizations would somehow be potentially impacted by this program and it was good to have conversation that was basically just a general over-arching conversation about expectations. And so actually those early meetings were really more about addressing a general approach, you know, what should be included on the tour in terms of various destinations but also became a brain-storming session about what the digital application should be able to do. In these sessions we were more like, almost like facilitators; we were writing up ideas, expanding on those ideas, asking questions, really trying to engage our audience in those meetings to really flesh out some concepts, with the hopes that there would be some predominant themes starting to emerge from these conversations, so at that point there were like no bad ideas: we were trying to gauge the general temperament of the stakeholders and also just build a general excitement.

Gary:
So, how much does this differ from the process, like, those initial conversations with the clients when you’re doing a website?
Vijay:
Yeah, I mean depends. Well, so in this case, because Newark didn’t really have an idea of …well they had an idea they wanted an App, of course; they wanted a walking tour of course, but that’s all they really had, you know, that was the underlying foundation in which we were brought in, so in that regard it was a little bit more open-ended; this App discussion, it was more about working collaboratively with this team to kind of craft a vision for this application. Typically with websites, and this is more about what our experience is, it’s a little bit more defined. Oftentimes there is a real purpose for a website in terms of getting to launch; there’s either an event happening or there is a promotion or a product release and up until that point, many teams have been working to kind of craft a vision for that website, be it the content strategy or be it the rationale for it or just the general purpose for it. In that regard, it’s a little bit more defined in terms of, OK, we need X, Y and Z; how do we deliver that and how do we build that? So it’s almost like the website’s a little bit further down the road in those conversations; typically then…in this case the App.
Gary:
OK, so…why did Newark Walks want a native iOS and Android App instead of a web-based App? Are there differences and benefits to each?
Vijay:
Actually that’s a really great question because it was something that was also discussed during the stakeholder session because people also asked that very same question, and there’s really no doubt that the experiences developed on native Apps and web Apps can be sometimes blurred; you’re seeing very sophisticated versions of those and almost getting a little bit blurred in terms of, oh, which one’s actually native and which one’s not? However, when we really started to find the purpose and the fundamental requirements of the application, the native approach started winning out; we wanted to tap into the GPS; we wanted to track walking times and distances travelled; we wanted to determine how far things were from your current position; we also wanted it to be stored off-line, we wanted it to be fast. Web Apps can certain achieve some of those requirements but not all and not currently to the accuracy of a native application and you know, native Apps can also tap into the hardware of the device, be it the GPU and the CPU. And there was actually another reason which, this may sound a little bit strange, but a native app is almost a little bit more tangible than a web app; it sounds kinda weird because there’s no physicality to it, but there was a feeling that having a dedicated App that lived within a market place that could be easily searched and downloaded would provide a greater connection to the audience. With a web App, you typically have to go to the website on your phone and then click a prompt that says, download to the phone which then appears on your home screen; it does have a similar effect but that experience and almost that permanence doesn’t quite resonate.
Gary:
No and I’ve never thought about this before until I just heard you talk, but it’s also the fact that, if I do travel myself, I may actually type the city name in the App store; it almost becomes another marketing point.
Vijay:
Exactly, exactly, it’s almost a built in…it’s truly a built-in marketplace.
Gary:
Yeah, that I never thought of it that way. Just one quick question about the…can…I can’t even remember now; can the web Apps take advantage of the camera yet?
Vijay:
You know, I think they can now. We haven’t taken advantage of that personally in our work, only because we focus more now on native applications just because of that performance. And also, you know…
Gary:
Oh yeah…OK.
Vijay:
You really…the acceleration of the hardware, you take advantage of all the sensors as well, you can really, really create a more curated experience that’s a little bit more meaningful by using native applications.
Gary:
No, that makes sense, because I didn’t…because both of them can access GPS but a native App would be able to access the GPS faster because it’s going right to the hardware and there’s no software interpretation of it.
Vijay:
Exactly, yeah. If you ever use Google Maps on your…because Google Maps has a web App version; if you ever use it, it’s always a little bit more generalized, approximation as opposed to you’re using the native application which is almost like pretty much spot-on.
Gary:
OK, well, thanks. So, what kind of research goes into making a native application before design and development actually begins? And is the designer involved in this part?
Vijay:
Yeah! So yeah, I think actually this is something that’s really sometimes overlooked in design schools and that is the need to basically research and understand your audience; as I mentioned before, we had already engaged with the stakeholders and gotten some great insight into some of the challenges and some wish-list items and some general ideas. We had passed all that feedback and basically created a preliminary list of attributes for the App. So, after that, we were heavily involved with this process, potentially because it gave us a better understanding of how to design something for this community, so after building that preliminary list we started to find the types of user we wanted this App to cater to. This was, again, partly from the engagement sessions, we started to understand some of the potential constituents, but some of the other types included were employees, parents, students, prospective students. In some situations, after that engagement session and after defining some of those user types, we actually conducted brief interviews to gain a better understanding of what would they want and what they be looking for, because if we’re trying to create an application for a particular audience, we really want to understand who they were as potential consumers. So those user type interviews helped us starting to map out these user journeys and user journeys are used to kind of establish various scenarios of what a user could be doing, where they could be coming from, where they’d be looking for or what they need along the way. This exercise led to us to find in great detail what the application needs to be and be able to do. It starts creating almost a roadmap of what your application should be able to handle down the road; not just today but also potentially tomorrow.
Gary:
All right, so you’ve already started to answer this with your previous answer but I want to follow up with a question. When visiting a website, there’s actually research and this is general observation, the user doesn’t have as deep or a defined or guided experience as they do in an App, so, once you get past that initial client meeting and you’ve got a good idea of the final deliverable, you’ve done this initial user research, how do you map out the deliverable or the milestones, and who…who’s involved in that during that process?
Vijay:
Yeah, that’s a great question. So, every project is different. The more product-based Apps use an iterative, agile approach; constant learning-design-test cycle. In the case of Newark, because there was a more or less defined goal established during the consensus building phase, it was easier to map out what needed to get done to achieve that goal. And so there were basically three primary parties involved; there was Merje Design who was establishing the overall wayfinding strategy and establishing the visual esthetic for the whole program; there was our team who was responsible for building out the App and the back-end system and then there was the client team who was responsible for basically finalizing all the content, finalizing the actual route and finalizing locations and getting all the assets together, and that was driven by a content strategy developed by Merje Design and ourselves for the appropriate applications and I just want to say, like the Great Newark Convention Visitor Bureau did an amazing job of wrangling all their stakeholders and building that consensus.

So we knew, as I mentioned before, it was the three and hundred and fifty anniversary of the City and there was a very particular launch date for this application. So, we kind of built the milestones backward from that launch date, and thankfully their process started a long enough time…or started long enough ago where there was enough time to budget in all these efforts and so communication and transparency was obviously very needed for this process to make sure that everyone was in line in delivering what they needed to deliver on time.

So, in terms of the design and the development for the App process, it followed a fairly typical process as a website. After we had basically built that consensus around who our audience was, what those scenarios were, what that preliminary list of functionality was, we kind of created a sitemap based on all those features and functions; after that we created a wireframe that mapped out how everything would live and then we added an interface to how would it physically fit within the overall program and then we built it out. After each stage, after the planning the session, after the preliminary design session and final design session, we would circle back with the client and merge to basically ensure what was being designed was on-point and complemented the overall program. So it was a fairly kind of regimented process, thankfully, because the goal was so defined.

Gary:
You know, this is one thing I’m kind of having trouble wrapping my head around that process and maybe it was very specific for this one but you can cite another App design is, you’re creating, it’s like a choose your own adventure kind of, where you have to give, the App has to give people the freedom to explore and do things but you have to control and curate that.
Vijay:
That’s exactly right, yeah.
Gary:
So, how do you do that?
Vijay:
You know, so I think that kind of lends itself back to, what is the purpose of this application? I think there are a lot of those Apps out there are a little more so back in the day where it would be almost everything for everyone; it would do so many different functionalities, it wouldn’t do any of them really well and then you’d probably toss it aside because it was either too overwhelming or just didn’t do them to the degree that you wanted them to do and so I think one of the real keys is to understanding when developing an App and designing an App is that, what is the purpose of this? What is the core functionality that you want the user to be able to do? And how well…and making sure how well they do it can be kind of quantified in terms of just the general functionality. I think it’s important that you use that as a basis but then you kind of layer it with additional things like, oh, it would be nice if it can complement that core functionality. In the case of Newark, the core function was this walking tour but this added functionality that we included was this event listing. As elementary as that sounds, it really complemented the overall wayfinding plan because one, it provided a greater context to what else you could do in Newark on this tour, you could find out, oh, you know, there is this concert that’s going on at NJPAC, or there’s a Devils’ game going on down the street and you’d be like, oh, it’s actually located only maybe a hundred meters from where I am now and be like, oh, maybe I’ll venture off and go explore that and maybe check out a show. So, in many ways, you provided those kind of choose your own adventures, but through a very curated, constructive lens of what that experience should be. You never want them to deviate too far off and almost enter a rabbit’s hole because then they start losing the whole benefit of the application, so everything is kind of done like, you use almost like this user empathy; if I were a person experiencing this application in Newark, what would I want to be able to do and what would make most sense? You really want to think, is it a natural extension for me to be able to do this within the context of this App, and that’s how you kind of want to frame it.
Gary:
OK, so…and I’m going to frame this with print design. So, when print design, my next question, I mean. When in print design, you print something: it’s done.
Vijay:
Yeah.
Gary:
When with web, there’s…because it’s such an easy thing to update, you can almost launch iteratively and add feature as you go and test them out, so is there a general strategy for launching an App? So, for example, is there a plan for an initial launch with limited features and then have features added over time, or…
Vijay:
Yeah, yeah. And just to clarify, the App process in many ways…or at least let’s say like the very defined App process defines…is parallel to a lot of the typical design processes, you know, you have discovery, design, develop and deploy. What’s different and definitely you kind of alluded to a second ago is that there is that iterative step where you evolve the App in terms of design and features. This iterative step is pretty common and fuelled basically from user expectations and their increased savviness with applications but also because there are evolutions in hardware and software which provide new opportunities to build more sophisticated experiences. So, during those initial meetings, we try to make that very clear that with any project involved in digital technology, there needs to be a plan in place to allow for iterative improvements and depending on the client, it’s good to have established those appropriate expectations for such improvements. In the case of Newark we’re like hey, we understand that you are a Government kind of entity; what’s a realistic kind of plan and maybe it’s like once a year we kind of look back, aggregate all that user feedback, see what people are saying and see what we can do to kind of either fix things, improve things or just add to this application. But to the long strategy, yeah. To a degree the functionality can be pared down.

In the case of Newark, tons of ideas were presented, but we knew there was a fixed launch date and there were a lot of moving pieces so when we were defining the functional scope, we viewed it in the length that, what are the bare essential elements we need to include for this App to launch and launch successfully? So there’s a term for that, it’s called MVP: Minimum Viable Product. Basically what you need to build out to launch and make it kind of resonate with your audience and make it usable. So yeah, I mean, I think to summarize, it’s really important to recognize the fact that this is a living, breathing organism, if you will and it lends itself as an opportunity to allow for those iterative improvements and you’ll take advantage of that because I think your audience expects that, your audience kind of expects this thing to kind of evolve as they mature in terms of understanding the contents: they want new functionality because they’ve kind of completely adopted what there is already.

So in the context of this App, it is a walking tour, right, so there’s only so many times you can take this tour, right, before you become very familiar with it, so if you still want to connect with your audience, what else can you provide them that gives them a better understanding of the City and that’s something that we’re constantly challenged with, like, OK, what else can we do to improve this application.

Gary:
OK. And one follow-up to that. In web, you can simply just upload the files to the web server and it’s simple like that and you can actually do A-B testing on the web because you have control over that. You can’t quickly launch something in an App store because you have to get approval and so that…so, how much does that hinder this iterative process and also like the A-B testing like saying, OK, does this button work better or does that button work better? Is that even possible when you’re using something, a native App?
Vijay:
Yeah, yeah, I mean even before…there’s of course like the whole testing process and we actually do a lot of low-fi testing at first where we actually just create these visual mocks of what we think the general esthetics should be, what the general interface should be and we just do a side-by-side comparison, at least at first. Think, hey, what would be more appropriate, what looks better, what kind of resonates with you more or what…and try to understand from a user perspective like the whys, you know, why does that one work better than the other one. Even before we start getting to program, because once you start getting to programming, it gets a little bit more complex because you’re kind of wiring into this application. Doing quick mocks is light years faster than programming. But once we get the degree it’s more about, OK, now does it function the way it’s supposed to function and in that regard, then we start creating these more like interactive prototypes and there’s a bunch of software out there that allows for these quick prototypes, these interactive prototypes that you can build out very quickly, based on that kind of…that visual study that you conducted.

And so that kind of generalizes kind of a visual vernacular for how to move forward. Once you start establishing those rules, because you don’t necessarily want to constantly re-invent it with every new feature and function because you’ve established a baseline of OK, what people kind of expect from the application, at least for a little while because eventually they’ll probably want to re-design it as new paradigms in design come out but in that iterative sense, once you establish some of those core functions in terms of animations and in terms of general esthetics, then you can start thinking about the functions and how to improve upon it. But in the case of Newark initially before we launched, we had a fairly large Beta test, about four weeks prior to launch we kind of opened up to a small section of about fifty people who were various students, Prudential employees, Government employees and we basically said hey, here’s the application, we did a private Beta but in the case of Newark and most prototyping, or sorry, Beta testing, we don’t necessarily make it free-form. We actually kind of created this very specified testing document that we provided them and in that document we listed out a series of questions around each feature of the test. By providing that document, we provided a frame of reference to base their testing around and it made the Beta testing a little bit more digestible, when you know what you’re looking for and what you need to be able to do.

Gary:
I appreciate that because I actually did a Beta test on an App and I was given no instructions and I didn’t…I played around with it but I didn’t feel like I was helpful because I had to randomly stumble across something and who knows if you’re going to?
Vijay:
Yeah, exactly, and they’re kind of looking at this in almost a black box; they’ve never seen this before and so if you can kind of set expectations, your end results or your feedback that you get become far more reliable because you’ve kind of given that context. But it was also again like the assessment wasn’t just about making sure how things worked too, it was also about how they experienced the app and so there were a lot of qualitative questions about the design and flow: was it intuitive? Did it feel appropriate? Did you just enjoy it overall? And even though we had a good idea about the overall App, just in general from our own internal testing and experience in design, it was good to get outside feedback as well, just to get that extra layer of input.
Gary:
You know what, I want to follow…you mentioned something about animations so I want to follow that up with…so, how do sound and animations play a role in the design of Apps?
Vijay:
Yeah, yeah. I think more so than ever before, they play a pivotal role because they’re almost bridging the gap between the physical and the digital in a digital sense: strange, again. So you’ve got to look at the nature of the device, ??? in particular, you almost forge a very intimate relationship between you and the application you’re interacting with because you’re using the hand to navigate the device; you’re touching things on the screen which causes reactions and sound and animation’s deep in that relationship to create almost a greater sensory experience. And it’s almost used to compensate for that typical tactile response you would get from actually touching something, so you’re kind of compensating for that physicality through sound and animation. I think the trick though is to balance how much of it is used and when it’s used. I’m sure you’ve experienced a bunch of Apps where animation and sounds were rather excessive and it actually started detracting from the actual function of the App so you don’t want to do that; you want it to simply complement a reaction because you want to make sure that something does happen when you do touch something, to make sure it creates that connection that, OK, I have actually done this action, now what is my response to that action? And sound and animations help with that.
Gary:
So, can you actually rely on sound though, because personally I have the sound turned off on my phone all the way.
Vijay:
Yeah, exactly. So that’s the thing, so that’s why I say sound and animation to kind of compensate for that potential. You’re always dealing with all the use scenarios where someone has some other settings turned off or other settings turned on so you kind of always…double back-up, you always have like two layers of potential reactions to kind of compensate for that. So I say, sound and animation kind of go hand in hand because you can’t rely on one or the other.
Gary:
I’m just curious; with the motion, for example, I’ve got an iPad2 that is completely useless now because of updating the iOS and I’ve tried to turn things off, like animations and such. Can you turn them off, can you turn them off from within the App or is that just the operating system?
Vijay:
Yeah, the operating system allows you to turn off their core animations, but within the application, no, you can’t just turn it off. I mean, I guess you could probably try to program it to do that but I think that’d be a very laborious task!
Gary:
Yeah, no, I just didn’t…I was curious how far Apple lets you lock down the animations, but it’s limited to just operating systems.
Vijay:
Yeah.
Gary:
Makes sense. One thing that I’m completely fascinated about is this idea of developer and designer working together and the reason I’m fascinated by it is, I don’t get to do that in the classroom because I just don’t have the developers, even if we have developers on campus, trying to get a teacher to collaborate, which isn’t that hard, but trying to get them to have the same schedule, the right class that does synch up with your class, is really hard. So, can you talk just a little bit about how designers and developers work together on say like a feature, because the developers, they know the hardware: designers don’t. Designers don’t know how to take advantage of those things.
Vijay:
Yeah, well I think to that point, and I’ll get to the other question in a second. I think it’s important for designers to really immerse themselves with the platform in which they’re working in; if you’re designing an App, you have to become very familiar with the device itself, in understanding what it’s capable of doing because it’ll provide you just a greater awareness of the potential of what you can create and more importantly, I think it’s important just to just download a bunch of interesting Apps to see what people are doing because it provides you with greater familiarity with the general landscape of what’s possible so that idea of just constantly just looking and experiencing and downloading and reacting is very, very important to any process. Now to your previous question about designers and developers working together, I think part of determining a feature, even from the get-go is determining the functions of that feature, so in the case of Newark let’s say yeah, there is a map, but what can that map do? So, even before the design phase starts occurring, it’s about working with the developer to define that functional scope, so in the example of the map it’s saying something like, OK the user needs to be able to zoom in and out. The map needs to be able to support programmable bounding areas.

The user needs to be able to determine current location within map bounds. The user needs to be able to click on markers: it’s a large laundry list of things to do. But one thing about it is it makes it very clear about what the App will be able to do and what it won’t be able to do and that’s really good one, for the client to know and to kind of help keep track, keep the project on track, so you avoid that scope creep. But secondly, it informs the developer of what it needs to be able to support so from a programming perspective, the developer can start prototyping some basic interactions, but of course, what it really starts informing is the designer of what they need to account for when developing the user flows, and the wireframes and the actual designs; that laundry list actually provides a basic outline of what elements need to be mapped out and then designed for that feature, so in that regard, that collaboration is really more about making it very transparent about those expectations: what can this thing do and what do you have to provide to be able to allow for that.

Gary:
I heard this phrase just this past week at a design education conference and somebody made the comment that, well, me personally, I always thought of HTML and CSS as a medium. So, and then I started thinking about it a bit more, I was like well, if the designer has HTML and CSS as a medium, they can really manipulate it, but when it comes to Apps, knowing Swift and knowing whatever the language is for Android, I can’t think of it…I think it’s called….
Vijay:
It’s like C+ or something like that? I forgot!
Gary:
But knowing that medium, isn’t really as helpful for a designer, so then I heard this term, hardware as a medium and you just kind of said that: you need to know the devices.
Vijay:
Yep.
Gary:
So, do you have some…simple things that design educators could tell students to do to get to better know a medium or hardware?
Vijay:
Yeah…so, for me personally, one thing that I constantly do is just go on the App Store and just download some interesting new Apps. And there’s a bunch of blogs out there that also curate really cool looking Apps out there or interesting functionally Apps so I think part of it’s just research. Really just exposing yourself to what other people are doing and just getting a familiarity of how those design boundaries are being pushed, through this format. I think it’s also important just to understand just the hardware, the tech…I hate to say it, but just read up on what the phone can do! Because there’s a lot of this hidden functionality that you just don’t expect to have this device support, so it’s almost just, almost creating that book of, OK, it can do X, Y and Z and like, OK, what are applications that take advantage of X, Y and Z and how do they do it? Just spark this idea, this conversation. There’s no real great answer because it’s just about developing a familiarity and how people parse that is very different and some people just look at blogs and see what people are doing and read articles; some others just look, download Apps and play around with them.

For me, downloading and playing around with them’s a lot better because you’re interacting with it; you’re actually personally looking and seeing how things function, it’s almost creating this interesting kind of backlog of OK, I’ve seen that before, that’s interesting, I’ll keep a little record of that, a little note to myself saying hey, that’s a really good reference for something that potentially could affect some of the design decisions down the road. Or, more like oh yeah, Apps can do that now, that’s pretty cool, and it’s just making sure you’re informed of what’s happening in the latest trends of design and development.

Gary:
Yeah, I think that’s just something important going forward now that I listen to you talk about it is just studying whenever, before there’s even a design phase or just study the features of what you’re going to be designing for. Meaning like, can a browser take advantage of the camera? I mean, I didn’t know, so you should be able to find those kind of things out because that lets you create better experiences.
Vijay:
Yeah and to be fair, sometimes I don’t even know those answer as well so I’ll just go on Google and just Google that very same question, like, can it be done and you’ll get some interesting responses then you’ll see some examples, OK, now does it achieve the same level of performance I want it to do? And that’s when the conversation that’s happening, OK, it does or doesn’t and maybe I should…it starts informing some of your larger decisions about, oh, am I going with a web App, am I going with a native App, am I going with something else entirely? So it’s nice to have that basis because then every decision you’re making going forward is grounded in a reason; it’s grounded in a very rational reason as to why.
Gary:
OK. So, I have one final question and I could probably ask it in one of two ways and it has to do with, what could educators be doing in the classroom to better prepare students for creating Apps? Or I could ask it, say, what would you like to see in a student’s portfolio that’s going to give you, and this is a visual designer that I’m speaking to, what is going to be a better indicator for you that they’re prepared to work in this kind of environment?
Vijay:
You know what’s interesting actually, because this is something now that we’re really looking for. I kind of, personally, I think it’s more about doing almost non-design assignments. I think designing is easy when you’re your own client; school projects are about just you, and you’re the only person you going to please but as soon as you start making projects for others and there’s a general public that will potentially use this project that’s being developed, it gets a little more complicated and involved and I think in those cases, it’s good to establish exercises that allow you to understand who that potential audience is and to craft an experience that’ll benefit and resonate. So I think that includes just doing general interviews, surveys, doing general research about the marketplace and testing those theories. Not only those exercises provide a greater context and meaning to the design process; it’ll undoubtedly result in a better solution. Now, for me, it’s like now seeing that research in a portfolio, seeing that decisions that were made in the design process was grounded in this research and I think that’s something that’s really overlooked is just spend the time to understand who this is going to be benefiting and the why: what informed those decisions, and I think that would create a greater basis, a greater foundation to the projects that are being shown.
Gary:
All right, so then I’m going to ask, you hit the nail right on the head and it’s how to display this in your portfolio, so I did actually teach an App development class and I didn’t assign them to create an App. What I did was I assigned them research and one of them was to go ride the bus…I kind of made them…they had to be the user so they had to take the bus to different locations to get groceries, to do shopping and so then I had another group of students that went and actually, like, OK, now go do some shopping on your limited income, then I had another group, OK, do your clothes shopping like you had to go for an interview, then I had a third group, OK, this is your budget, what kind of groceries can you get, living in this area and you can only use public transportation and so they did all that first.
Vijay:
That’s awesome!
Gary:
So then they came back and I said, oh, let’s look at this stuff; what did you…do the affinity mapping. Where are your pain points and I said OK, once we’ve identified the pain points, then solve for X with App. And the students…and so they created their Apps and there was like a user journey through them so they…I felt like they had …they made actual sense but damn if I could figure out a way to show that whole process in their portfolio. All they did was just show their App screenshots and like there’s so much more that you did, it’s valuable but how would you show that to an employer?
Vijay:
Yeah, I mean, sometimes it’s about taking all that raw data and kind of synthesizing it into these tangible bites of information, just for either presentation purposes and this is part of the process with any kind of client presentation it’s like OK, yeah, you have all this raw data but how are you going to show it to your general audience who has to kind of understand this data? And that’s I think the role of designer also is to be able to interpret it and provide it in a very digestible medium and in the case of some of those examples that you just alluded to, sometimes it’s about creating almost a storyboard, an animated narrative of the experience along the way, like a visual journey map because once you start understanding OK, what were those decision points, you can start carrying out little mind bubbles like, oh, I have to do X, Y and Z; you make it a little bit more kind of animated and a little bit more fun because you’re almost telling this very complex story in a very simple manner through almost this comic storyboard medium. But it’s also about using those mind maps if you will and kind of just synthesizing it into these very kind of tangible flow-charts if you will of, OK, of where I’m going, what I’m doing and just making it very kind of systematic, if you will, and it kind of just shows the logic to all that raw data and showing, OK, there is a reason for why that App looks that way because of this reference in this flow-chart or a reference in this user journey that we kind of experienced together and you kind of just want to show that because it makes it a little bit more meaningful.
Gary:
No, that’s great and in my low-hanging fruit one that I felt that I tried and I didn’t like it was, I had to make an ebook, eprocess book of all of the data; I said they could either approach it as a personal journal of the experience that they had, or they could approach it as, this ebook is the pitch to the client that this is why they need this App, or this is a pitch to a venture capitalist on why they need the App but, I know, it just didn’t turn out the way I envisioned it!
Vijay:
Yeah, I always look at it like, how would I explain this project to my mom and it’s like, if she understands the frustrations or the reason then it’s a win because she’s potentially the perfect audience for any App that goes into the general market-place so if the research makes sense to her, then it’ll make sense to everyone.
Gary:
All right, well so…Vijay, before I let you go, I’ve already asked this question when you were on not too long ago, but is there anything else that you’re working on that you personally want to share or is there anything else you want to talk about or promote or any final advice?
Vijay:
Um…in terms of approach, one thing that we’re interesting working on right now, we do a lot of these wayfinding applications and we’re in the process right now of taking that idea and making a little more of a turnkey platform, so one thing with this whole design process is yes, you’re always trying to understand where are the most appropriate functions and features for that particular client or that particular project but through our several years of operation, we realized there is this baseline foundation of things that almost everyone wants so what if we made that a turnkey platform for anyone to be able to use and download and create their own very hyper-local wayfinding application, so that’s something we’re working on right now and ideally be available in early 2017 for people in small cities, parks, universities or just local neighborhoods to download and start creating their own native applications.
Gary:
And so are…wow, I can’t wait to hear about that because I can’t wrap my head around how I’m going to…I mean, I see the potential like, oh I could use it for this, for this, for this; local conferences would be great to do, like these are the things you go do, but I wouldn’t know how I would work in the App.
Vijay:
Ah yes, so that’s going to be…well part of it’s like the App is really more about the end product, the user facing product. I think for the first it’s kind of curating this, it’s going to be more about the admin interface, the CMS, that allows you to manage all this content and power it and that’s the next big challenge for us is we’ve kind of built the foundation for it and now it’s about how to make it very user friendly.
Gary:
That’s fantastic, a CMS for Apps…
Vijay:
Yeah, exactly it.
Gary:
Wow, awesome. That’s all we have time for today on episode Thirty-seven of Design Edu Today. I want to thank today’s guest, Vijay Mathews for being so generous with his time. I want to thank the audience for listening and I want to thank the Design Edu Today hosting sponsor DigitalOcean and CDN sponsor Fastly for making the hosting and distribution of these podcasts possible. I also want to thank the AIGA and the AIGA Design Educators’ Community for their generous support of my research that lead to this podcast series.

If you like this podcast consider leaving a review for it in the iTunes store and share it with your colleagues and friends. To discover more about the Design Edu Today podcast and read the session notes and transcripts visit the show website at designedu.today. To keep up with new show releases, you can follow us on twitter at @designeudtoday, like the Facebook page, or subscribe to this podcast through the iTunes or Google Play store.

Finally, if you would like to suggest topics for future episodes or give feedback to help improve the show contact me through twitter or the show’s email address at hello@designedu.today.

Thank you for listening to Design Edu Today.