Chapter 6 - Ideation and Design Principles
We already had conducted our brainstorm session before we had to read chapter 6, 7 and 8 for the reading seminar. At this point it has to be remarked that it would have been more beneficial for us to read the literature first (Theory first!). However, retrospectively we adhered to the brainstorming rules mentioned in chapter 6. We also used techniques mentioned such as brain-writing (yes, and...), swiping, as well as we used pain points as a mean to kick-start each brainstorming round.Chapter 7 - Refinement
In our discussion related to chapter 7 we identified money and technology as the only two constraints that do not apply to our problem, whereas all the other constraint stated in this section apply.Related to chapter 7 we also talked about the laws and principles of interaction design, were we came to the conclusion that our design follows the principles of direct manipulation.
Moreover, we believe that keeping affordance in mind when designing the prototype is an important thing, as this concepts drives us towards and design that is as intuitive, simple and obvious as possible (i.e.; using the right shape, color, etc.). In terms of feedback and feedforward we classified our design / solution as that has to provide immediate feedback, particularly as response time is one of the pain points that we try to tackle.
When we came across the mental model and the different laws such as Fitt's or Hick's law we all believe that most of those laws can not easily be applied to our design. The only laws that we might use is Tesla's law (i.e.; shifting complexity from the user to the system), as well as Poka-Yoka (designing the task flow such as that errors become impossible).
Furthermore, we all agreed that we can't use standards or frameworks, simply because there is none, as we do not create a software in the classical sense.
In terms of documentation we depicted sketches and storyboards as our primary means to document the design. Another technique we want to make use of is task flow diagrams, which inherently also contains use cases (but in an non descriptive manner). Additionally, we also thought about creating a wireframe in order to convey the concept of our interaction principles in more detail.
Chapter 8 - Testing
In chapter 8 we found an important technique for us, which is called A/B testing. During the first round of sketching and designing we were occasionally faced with different design options. Hence, for such situations we can use A/B testing in order to let the user decide which way works best for him or her. When we spoke about the testing chapter we all agreed that we will follow the guidelines and create a test plan, as well as we will set up a test lab.When talking about prototyping we decided that a low-fidelity paper prototype would be the most suitable for our project. In order to be able to modify our prototype and by that add some kind of interaction we also want to make use of wizzard-of-oz-manipulation.
Regarding the development style we think that we are going to develop in an agile way, as we meet on a regular basis in order to meet short term milestones.
Questions
Q1: brainstorming - sketches?No, not necessarily, depends on the project
Q2: wireframe, is it necessary with every project?
We came to the conclusion that a wireframe is not a mandatory for every project.
Q3: are tasks and use cases related?
Yes, in the sense that task flows kind of contain use cases.
But use cases are a more detailed or "descriptive" explanation than tasks or task flows, whereas task flows are a more pictorial approach to describe a design.
Q4: When to use which mean to document a design?
Hard to answer/generalize, depends on the size and nature of a project
But for smaller projects it might be enough to only use sketches and storyboards, whereas for bigger more complex projects/products it might be beneficial to also use task flows and wireframes.
No comments:
Post a Comment