I’m redoing my portfolio, and I figure if I’m going to iterate on a project, I’m going to do it right. Inspired by Material Design’s case studies, I wanted to experiment, in the very beginning, with Product Architecture as I redesign Blueprint, a mobile app concept I worked on in grad school.
This post will cover:
- What exactly is “Product Architecture Design”?
- About my original project
- Diagramming Information Architecture
- Building a New Main Workflow
- Wiring an Interaction Model
- What I Could Research at This Point
- Next Steps
What Exactly is Product Architecture Design?
“Product Architecture” is not a term I have seen frequently in the interwebs of design communication online. An aspect of Material Design’s case studies that I admire is that it is clear that the products were intentionally designed from the product foundational level upward.
Therefore, I define Product Architecture Design as the information architecture, key workflows, and interaction models that underline a product’s core. Thinking about Product Architecture at the start of designing a product paves the pathway both for specific screens and larger design systems.
About My Original Project
Maker Ed, an education nonprofit, worked with one of my grad school classes to investigate design solutions for project based learning. On a team of four students, we listened to students, teachers, and administrators who came to our classroom, and we collaborated with a Pennsylvania public school to understand: what did project-based learning look like, and what did students and teachers do with these projects?
A key insight we took away was that while teachers are increasingly integrating projects into their classrooms and colleges take into consideration students’ passion projects, it’s difficult for students to get continued feedback on projects to keep improving beyond a single unit. Teachers have too many students to support and are not experts in project disciplines, and it’s difficult for schools to connect with domain experts to give guidance to students.
However, learning science research shows that sufficient quantities of thoughtful peer-to-peer feedback can help students improve just as much as an expert’s feedback. Therefore, Blueprint’s intention is to help students give each other useful feedback in a way that is easy and fun.
In 2016, we jumped straight from our user research insights to that high-fidelity prototype for Blueprint 1.0. In my redesign, I want to more thoughtfully think about design execution itself. Therefore, I am starting at the product architecture level in the very beginning to see how this informs the app’s later design.
Diagramming Information Architecture
First, I focused on the problem that we were trying to solve: helping students improve their projects through peer-to-peer feedback. For this to be possible, my design would need to incentivize students to leave feedback for each other. Considering the students in our interviews who wanted to take their projects to the next level were motivated, I thought it made sense to block access to a student’s view of their own projects’ feedback until they viewed a project and gave feedback.
From this, I mapped out Blueprint 2.0’s revised organizational system. When a student first opens Blueprint 2.0, the app’s organizational system is sequential. This means that the design will strongly incentivize the viewing of a project and sharing feedback on that project. Once a student submits feedback, the app’s organizational system becomes a matrix. In other words, the design would lead students to feel more free to choose which section of the app to navigate to at what time.
Second, I combed through our original project and wrote down each nugget of information I could find. By nugget of information, I mean that I was looking for the nouns that made up Blueprint. For example, “feedback prompt” was a term I wrote down on my brainstorming paper. “Project Name” is another. I then opened up a spreadsheet into which I began to place these bite-sized information bits into groups that made sense. I named the groups and continued to group “upwards”, i.e. into larger and larger buckets of groups until my groups reached the screen-level.
This led to the information architecture of Blueprint 2.0 looking something like this:
Building a New Main Workflow
For the scope of this redesign, I focused my efforts on understanding workflows associated with a student giving feedback to another student since that is the crux of the problem statement. Once I had my information architecture in front of me, I realized that students could give feedback in two places on the app: 1) while unlocking access to the student’s own feedback and 2) while browsing projects once the student already gave feedback on a project to unlock the rest of the app.
Wiring an Interaction Model
Once I articulated Blueprint 2.0’s information architecture and primary workflow, I switched focus to the app’s interaction model. An interaction model is the interaction design that holds a digital product together. It consist of underlying interactive patterns experienced throughout the product. These patterns should match users’ cognitive model around how they would move through the specific product. Therefore, interaction models must be considered in connection with the specific content of a product. This is why I started with information architecture and workflow before I got to the interaction model stage. In Blueprint 2.0’s interaction model, I am focusing on how interaction connects with the navigation and primary workflow of the app. Micro-interactions such as how a user views different feedback prompts on a specific screen will come later.
I created interactive, extremely high-level wireframes as I explored different interaction schemes. Below is the model with which I am going to move forward:
Because Blueprint 2.0 has two parts of its organizational system, Blueprint 2.0’s interaction model will consist of 1) an interactive navigation that make it easy for students to continue down a sequential flow and 2) a navigation bar to allow students to move to different areas of the app freely once they unlock the full app after giving feedback. In the sequential flow interaction, screens push from the right to give the impression that the student is moving through different stages. Students can tap backwards screen by screen so that exiting the flow is not too easy but still possible. At the matrix level, fade-in and fade-out transitions result from tapping on the navigation bar to signal that these screens can be navigated between easily.
What I Could Research at This Point
Information Architecture Evaluation and Discovery
I would use a mixed card sort to investigate:
- Does the app use lingo that makes sense to students globally across different classroom contexts?
- Does this information architecture match students’ mental model?
Interaction Model Evaluation
I would conduct a moderated interview and thinkaloud with students to gage:
- Can students navigate through the app with this interaction model? Are the motions what they expect? Are gestures intuitive?
Taxonomy and Content Discovery
I conduct a cognitive task analysis to see:
- What sorts of taxonomies make sense for filter or search mechanisms on the different projects and/or feedback prompts?
I would have moderated interviews, surveys, or conduct secondary research with teachers to learn:
- Which feedback prompts will be most helpful to help students continue learning and iterating on their projects?
Coming up next, I am going to build out wireframes of screens, insert content, and apply visual design. I will also continue to note research questions and ideas around user research tests as I continue my revision process.
Thanks for reading, and I hope you stay tuned for Part 2!
P.S.: If anyone knows how to export high resolution images from Sketch, please let me know by commenting below or sending me a message! 🙂